ફક્ત IPv6 કનેક્શન, IPv4 સેવા: SOCKS પ્રોક્સીને પુલ બનાવવા દો

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

બે સોકેટ, બે સરનામા કુટુંબો

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

આ સરનામા પ્રકારોને એક સંદેશની અંદર ત્રણ સ્વતંત્ર પસંદગી તરીકે વાંચો. IPv6 દ્વારા પહોંચી શકાય તેવી પ્રોક્સી IPv4 ગંતવ્યનું સોકેટ ખોલી શકે છે, જ્યારે તેની પાસે કાર્યરત IPv4 આઉટગોઇંગ હોય અને તેની નીતિ વિનંતીને મંજૂરી આપે. SOCKS5 સ્પેસિફિકેશન ક્લાયન્ટના પરિવહનનો કોઈ ઉલ્લેખ વિના તેમને વ્યાખ્યાયિત કરે છે.

નિયંત્રિત SSH ઉદાહરણ

તમને વાપરવાની અનુમતિ હોય એવો SSH હોસ્ટ લો, જે IPv6 પર જવાબ આપે અને પોતે ફક્ત v4 પર રહેલી HTTPS સેવા સુધી પહોંચી શકે. OpenSSH નું ગતિશીલ ફોરવર્ડિંગ તમારા મશીન પર સ્થાનિક SOCKS શ્રોતા મૂકે છે, જ્યારે લોગિન સત્ર v6 પર ચાલે છે.

ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]

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

સત્ર ચાલુ હોય ત્યારે વિનંતી આવી દેખાય છે:

curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/

લૂપબેક કનેક્શન IPv4 ઇન્ટરનેટ માર્ગ નથી. તમારા મશીનમાંથી બહાર નીકળતું v6 પરનું લોગિન સત્ર છે, અને ગંતવ્યનું સોકેટ દૂરની બાજુ ખોલે છે. socks5h સ્વરૂપ નામ-ઉકેલ પણ તે બાજુને સોંપે છે, જે ત્યારે મહત્ત્વનું છે જ્યારે ક્લાયન્ટ પાસે પોતાનો IPv4 રિઝોલ્વર માર્ગ ન હોય.

ગંતવ્ય ખરેખર શું જુએ છે

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

રિલે એ જગ્યા પણ છે જ્યાં વાતચીતના બે અર્ધા દેખાય છે, જે નિદાન દરમિયાન ઉપયોગી ગુણધર્મ છે અને નીતિ વિના રિલે વહેંચાય તો જવાબદારી છે.

આ DNS64 કે NAT64 નથી

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

બંને મિકેનિઝમ એક જ નેટવર્કમાં હોઈ શકે છે, તેથી જે સાંભળવામાં નજીક લાગે તે નહીં, પણ તમે ખરેખર ચકાસ્યું છે તેનું વર્ણન કરો.

વચન આપતાં પહેલાં વ્યાપ જાણો

OpenSSH નું ગતિશીલ ફોરવર્ડિંગ TCP કનેક્શનો વહન કરે છે, મનસ્વી IP ટ્રાફિક નહીં, તેથી UDP, ICMP અને પ્રોક્સીને અવગણતા કોઈ પણ પ્રોટોકોલને અલગ સમર્થિત રચના જોઈએ. SSH હોસ્ટ-કી ચકાસણી, સર્વરના ફોરવર્ડિંગ નિયંત્રણો અને HTTPS પ્રમાણપત્ર માન્યતા જાળવી રાખો, કારણ કે પ્રોક્સી વધારાનો વિશ્વસનીય સહભાગી છે, ઓળખ ચકાસણી નબળી પાડવાનું કારણ નહીં. જો ધ્યેય VPN નું બહારનું પરિવહન પ્રોક્સી દ્વારા લઈ જવાનો હોય, તો ધારી લેવાને બદલે ચકાસો કે બંને છેડા તે પરિવહનને સમર્થન આપે છે; કોઈ પણ SOCKS શ્રોતા તેને રિલે કરી શકે એમ ધારશો નહીં.

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