નીતિ રાઉટિંગ વિરુદ્ધ SOCKS: કયો સ્તર ખરેખર ટ્રાફિકને પ્રોક્સી કરે છે

તમે એક નીતિ રૂટ ઉમેર્યો છે જે VPN ક્લાયન્ટનો ટ્રાફિક પોર્ટ 1080 પર SOCKS લિસનર ચલાવતા હોસ્ટ પર મોકલે છે. પેકેટ આવે છે, લિસનર કંઈ લોગ કરતું નથી, અને કનેક્શન લટકી જાય છે. રૂટમાં કંઈ ખોટું નથી: આગલું હોપ નક્કી કરે છે કે પેકેટ ક્યાં જાય, અને SOCKS એ એવી વાતચીત છે જે ક્લાયન્ટે શરૂ કરવી પડે. લોકો સામાન્ય રીતે પ્રોક્સી દ્વારા ટ્રાફિક મોકલવાથી જે ત્રણ આર્કિટેક્ચરનો અર્થ કરે છે તેની સરખામણી કરો, અને સ્પષ્ટ થશે કે તમારા સેટઅપમાં કયો ભાગ ખૂટે છે.

રાઉટિંગ, DNAT અને SOCKS જુદી જુદી વસ્તુઓ બદલે છે

નીતિ રૂટ સ્તર 3 ના નિર્ણયને ફરી લખે છે. એક ક્લાયન્ટનો ટ્રાફિક પસંદ કરેલા આગલા હોપ પર મોકલવા માટે બે લીટી પૂરતી છે:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

ત્યાર બાદ કર્નલ પેકેટને 10.50.0.2 ને સોંપે છે, જ્યારે મૂળ ગંતવ્ય હજી IP હેડરમાં જ રહે છે. જો 10.50.0.2 રાઉટર હોય, તો તે પેકેટને ફોરવર્ડ કરે છે. જો તે 1080 પર SOCKS ડિમન ધરાવતું હોસ્ટ હોય, તો પેકેટ એવી કોઈ વસ્તુને સંબોધિત નથી જે તેને સ્વીકારી શકે, અને પોર્ટ 1080 પર DNAT પણ મદદ કરતું નથી, કારણ કે અનુવાદિત પેકેટ હજી પણ SOCKS અભિવાદનને બદલે મૂળ એપ્લિકેશન પેલોડ વહન કરે છે.

SOCKS5 એક વર્ઝન બાઇટ, પદ્ધતિઓની યાદી, પ્રમાણીકરણની આપલે અને ગંતવ્યનું નામ આપતી વિનંતીથી શરૂ થાય છે. તે એપ્લિકેશન ડેટા છે. કોઈ રાઉટિંગ એન્ટ્રી કે netfilter લક્ષ્ય તેને ઉત્પન્ન કરતું નથી, અને એક લીટીમાં સરખામણી આ છે: રાઉટિંગ પાથ પસંદ કરે છે, SOCKS સર્વરને બીજું કનેક્શન બનાવવા કહે છે.

પ્રથમ કેસ: એપ્લિકેશન પોતે SOCKS બોલી શકે છે

જ્યારે પ્રોગ્રામમાં પ્રોક્સી સેટિંગ હોય, ત્યારે આ સૌથી ટૂંકો રસ્તો છે અને તેને કર્નલમાં કોઈ ફેરફારની જરૂર નથી. તેને લિસનર તરફ નિર્દેશિત કરો, સર્વર માંગે તો ઓળખપત્રો આપો, અને નક્કી કરો કે નામ સ્થાનિક રીતે ઉકેલાય છે કે પ્રોક્સીને સોંપાય છે. curl માં આ જુદા જુદા ફ્લેગ છે, અને જ્યારે ગંતવ્ય ફક્ત પ્રોક્સીની બાજુથી ઉકેલાય ત્યારે આ ફરક મહત્વનો છે:

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

જે એપ્લિકેશનો પ્રોક્સી એન્વાયર્નમેન્ટ વેરિયેબલ્સને અવગણે છે, અથવા કાચા સોકેટ ખોલે છે, તેમને આ રીતે મદદ કરી શકાતી નથી. બ્રાઉઝર્સ અને મોટાભાગનાં HTTP સાધનો ઠીક છે; ગેમ ક્લાયન્ટ, મેલ ડિમન કે કોઈપણ વેન્ડર બાઈનરી સામાન્ય રીતે નથી. સીમા દરેક એપ્લિકેશન અને દરેક પ્રોટોકોલ માટે છે, તેથી આ વિકલ્પ પરીક્ષણ માટે ઉત્તમ અને આખા VPN માટે જવાબ તરીકે નબળો છે.

બીજો કેસ: IP ફ્લોને પ્રોક્સી સેશનમાં કન્વર્ટ કરતું એડેપ્ટર

જે પ્રોગ્રામ્સ SOCKS બોલી શકતા નથી, તેમના માટે કન્વર્ઝન એવી કોઈ વસ્તુમાં થવું જોઈએ જે IP ટ્રાફિક સમાપ્ત કરે અને તેમના વતી પ્રોક્સી સેશન ખોલે. તે ઘટક પાસે ટનલ ઇન્ટરફેસ છે, નીતિ રાઉટિંગે પસંદ કરેલા ફ્લો સ્વીકારે છે, દરેક માટે SOCKS હેન્ડશેક કરે છે અને જવાબો ફરી બનાવે છે. રૂટ ટ્રાફિકને તેની તરફ નિર્દેશિત કરે છે; એડેપ્ટર જ સેશન બનાવે છે.

સંપૂર્ણ સબનેટ તેને સોંપતા પહેલાં તેનું દસ્તાવેજીકરણ વાંચો. ઘણા એડેપ્ટર TCP સારી રીતે વહન કરે છે અને UDP ને ફક્ત SOCKS5 UDP એસોસિએશન દ્વારા સંભાળે છે, અને તેમાંથી કોઈ ICMP ને પ્રોક્સી ટ્રાફિકમાં ફેરવતું નથી, તેથી સફળ ping પ્રોક્સી પાથ વિશે કંઈ કહેતું નથી. DNS બીજી જાળ છે: જો એડેપ્ટર નામ સ્થાનિક રીતે ઉકેલે, તો ફક્ત-આંતરિક રેકોર્ડ ખોટા જવાબમાં, અથવા બિલકુલ કંઈમાં ઉકેલાય છે.

લૂપ અટકાવ એ જ ઓપરેશનલ વિગત છે જે ડંખે છે. એડેપ્ટરના SOCKS સર્વર સાથેના પોતાના કનેક્શન ફરી એડેપ્ટરમાં રાઉટ થવા જોઈએ નહીં, તેથી તેના ટ્રાફિકને નિયમમાં અપવાદ કે સમર્પિત સ્રોત સરનામું જોઈએ. આ ખોટું કરો તો પ્રોક્સી સેશન પોતાને પ્રોક્સી કરવાનો પ્રયાસ કરશે.

ત્રીજો કેસ: હોસ્ટ ખરેખર રાઉટેડ ગેટવે છે

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

ત્રણ કેસ ઝડપથી અલગ પડે છે. ખરેખર શું સાંભળી રહ્યું છે તે તપાસો, પછી હોસ્ટ સુધી પહોંચતા પ્રથમ બાઇટ્સ જુઓ:

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

સાચા SOCKS ક્લાયન્ટનો પ્રથમ પેલોડ બાઇટ 0x05 છે, જે અભિવાદનમાંનું વર્ઝન છે. જો કેપ્ચર તેના બદલે મૂળ એપ્લિકેશન ડેટા દર્શાવે, તો કોઈ SOCKS ડિમન જવાબ આપશે નહીં, કારણ કે વાટાઘાટ ક્યારેય શરૂ થઈ જ નહોતી. જો 1080 પર કંઈ સાંભળતું ન હોય, તો હોસ્ટ ગેટવે છે, અને પ્રશ્ન એ થાય છે કે તે ફોરવર્ડ કરે છે કે નહીં અને પરત માર્ગ છે કે નહીં.

ચાર પ્રશ્નો સાથે સ્તર પસંદ કરો

શું પ્રોગ્રામમાં પ્રોક્સી સેટિંગ છે? તેનો ઉપયોગ કરો અને ત્યાં જ અટકો. શું ટ્રાફિકમાં એવું UDP કે ICMP છે જે ટકી રહેવું જોઈએ? ફક્ત રાઉટેડ કે NAT ગેટવે ICMP વહન કરે છે, અને UDP ને એવું SOCKS5 એસોસિએશન જોઈએ જે બંને છેડા ટેકો આપે. શું મશીનના દરેક પ્રોસેસને આવરી લેવા પડે, જેમને તમે ગોઠવી શકતા નથી તેમને પણ? તો તમારે એવું એડેપ્ટર જોઈએ જે ઇન્ટરફેસ ધરાવે અને ફ્લો સમાપ્ત કરે. શું તમે તેના રાઉટિંગ, DNS અને લૂપ-અટકાવ અપવાદો પણ સંભાળી શકો? જો નહીં, તો સાદું ગેટવે ચલાવવું ઓછું ખર્ચાળ રહેશે.

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