પારદર્શક TCP-થી-SOCKS ફોરવર્ડિંગમાં મૂળ ગંતવ્યો

ફાયરવોલ બદલી શકે છે કે TCP જોડાણ ક્યાં ઉતરે છે. પરંતુ ફક્ત એ બદલાવથી તે મૂળ એપ્લિકેશનને SOCKS બોલવાનું શીખવી શકતું નથી.

સામાન્ય SOCKS સર્વર માંગેલા ગંતવ્યનું વર્ણન કરતી વાટાઘાટની અપેક્ષા રાખે છે. પ્રોક્સીથી અજાણ એપ્લિકેશન તેના બદલે તરત જ પોતાના પ્રોટોકોલ બાઇટ્સ મોકલે છે. તે બાઇટ્સને સીધા SOCKS શ્રોતા પર રીડાયરેક્ટ કરો અને બંને પક્ષ પ્રથમ સંદેશ અંગે અસહમત થશે.

ગુમ થયેલો ઘટક અનુવાદક છે

પારદર્શક TCP-થી-પ્રોક્સી ઘટક તે ઇન્ટરફેસો વચ્ચે બેસે છે. તે એપ્લિકેશને શરૂઆતમાં માંગેલું ગંતવ્ય શોધે છે, યોગ્ય SOCKS અથવા HTTP CONNECT સત્ર સ્થાપે છે, અને પછી પરિણામી પ્રવાહ પર એપ્લિકેશન ડેટા રિલે કરે છે.

તેના Linux iptables માર્ગ પર, redsocks સ્રોત સાચવેલું ગંતવ્ય SO_ORIGINAL_DST વડે મેળવે છે. અન્ય ઓપરેટિંગ સિસ્ટમો અને રીડાયરેક્શન પદ્ધતિઓ જુદી જુદી પદ્ધતિઓ વાપરે છે. આ રીડાયરેક્ટર અને નેટવર્ક સેટઅપનો ગુણધર્મ છે, સામાન્ય SOCKS ક્લાયન્ટનું લક્ષણ નથી.

મૂળ-ગંતવ્યની માહિતી એ પણ સમજાવે છે કે રીડાયરેક્શન નિયમને પ્રોક્સી હોસ્ટથી અસંબંધિત ગેટવે પર ખસેડવો હંમેશા સમકક્ષ કેમ નથી હોતો. સ્વીકારતી પ્રક્રિયાને તેની ઇન્ટરસેપ્શન રીત જે મેટાડેટા માંગે છે તે જોઈએ છે. અન્યત્ર ફરીથી લખાયેલું સરનામું કદાચ તે માહિતી અપેક્ષિત સ્વરૂપમાં આપશે નહીં.

અનુવાદકનો વ્યાપ સ્પષ્ટ રાખો. કાર્યરત રીડાયરેક્ટ કરેલું TCP જોડાણ મનસ્વી UDP, ICMP કે દરેક રિઝોલ્વર માર્ગ માટે આધાર સાબિત કરતું નથી. અપસ્ટ્રીમ પ્રોક્સી પ્રોટોકોલ અને અનુવાદકનું અમલીકરણ હજી પણ સમર્થિત ક્રિયાઓ નક્કી કરે છે.

જ્યારે સેટઅપ જોડાણની તરત જ પછી નિષ્ફળ જાય, ત્યારે એક્સેસ નિયમો પહોળા કરતાં પહેલાં પ્રોટોકોલ સીમા તપાસો. સંપૂર્ણ પહોંચી શકાય તેવો SOCKS શ્રોતા એવા બાઇટ્સ નકારી શકે છે જે ક્યારેય SOCKS વિનંતી ન હતા.