OpenVPN માટે SOCKS5 પ્રોક્સી: TCP ટનલ કે એપ્લિકેશનોને પ્રોક્સી કરવી?

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

એક મર્યાદા ડિઝાઇન નક્કી કરે છે

SOCKS5 ખરેખર UDP એસોસિએશન મોડ નિર્દિષ્ટ કરે છે. OpenVPN ક્લાઇન્ટ પ્રોક્સી સપોર્ટ તો પણ સ્ટ્રીમની આસપાસ બનેલો છે: socks-proxy TCP પ્રોફાઇલ માટે દસ્તાવેજીકૃત છે, અને HTTP CONNECT પ્રોક્સી પાસે ડેટાગ્રામ માટે કોઈ માર્ગ જ નથી. દસ્તાવેજની એક લાઇન કન્ફિગરેશન ફાઇલને સ્પર્શે તે પહેલાં આર્કિટેક્ચર નક્કી કરે છે.

તેથી પ્રશ્ન કઈ પ્રોક્સી પસંદ કરવી તે નથી. પ્રશ્ન એ છે કે ટનલ સ્ટ્રીમ બને છે, કે ડેટાગ્રામ રહે છે અને બીજું કંઈ પ્રોક્સીંગ શોષી લેવા દે છે.

વિકલ્પ A: ટનલને સ્ટ્રીમ બનાવો

આ માટે TCP શ્રોતા ધરાવતું સર્વર અને પ્રોક્સીનું નામ આપતી ક્લાઇન્ટ પ્રોફાઇલ જરૂરી છે. બંને ભાગ જરૂરી છે, અને સર્વરની બાજુ એ છે જે લોકો ભૂલી જાય છે:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

છેલ્લી લાઇનને http-proxy proxy.internal 8080 થી બદલો જ્યારે પ્રોક્સી HTTP બોલે છે, અને જો માંગે તો ક્રેડેન્શિયલ ફાઇલ ઉમેરો. પ્રોક્સીએ તમારા VPN પોર્ટ પર CONNECT કરવા તૈયાર હોવું જોઈએ, અને સર્વરે TCP પર જવાબ આપવો જોઈએ; ફક્ત UDP શ્રોતા તે પ્રયાસને અવગણે છે. 443 પસંદ કરવું વ્યવહારુ પગલું છે, કારણ કે ઘણા નિયંત્રિત નેટવર્ક તેને અને થોડું બીજું મંજૂર કરે છે.

ખર્ચ TCP પર TCP થવાનો છે. એક ખોવાયેલ બાહ્ય સેગમેન્ટ તે કનેક્શન વહેંચતા દરેક આંતરિક સ્ટ્રીમને અટકાવે છે, તેથી સામાન્ય રીતે સ્વતંત્ર હોય તેવી પુનઃપ્રાપ્તિ વહેંચાયેલી બને છે. સેટઅપ પણ વધુ સમય લે છે, અને અસ્થિર બાહ્ય માર્ગ ધીમી ટનલને બદલે અસ્થિર ટનલ બને છે.

વિકલ્પ B: ટનલને એકલી રહેવા દો

જ્યારે ટનલ UDP પર જ રહેવી જોઈએ, ત્યારે ટનલ એ જગ્યા નથી જ્યાં તમે કંઈ કન્ફિગર કરો. તેના બદલે એપ્લિકેશનોમાંથી બહાર જતો TCP સ્થાનિક SOCKS શ્રોતા તરફ રીડાયરેક્ટ થાય છે, અને એપ્લિકેશનોને ક્યારેય ખબર પડતી નથી કે પ્રોક્સી અસ્તિત્વમાં છે. Linux પર તે સામાન્ય રીતે redsocks અને nat ટેબલમાં NAT REDIRECT નિયમ હોય છે.

ફરીથી ફક્ત TCP. privoxy જેવી ફક્ત-HTTP પ્રોક્સી મનસ્વી પ્રોટોકોલ રિલે કરી શકતી નથી, અને આ ડિઝાઇન એપ્લિકેશનો માટે કોઈ ડેટાગ્રામ સપોર્ટ પણ ઉમેરતી નથી.

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

દરેક વિકલ્પ ક્યાં નિષ્ફળ જાય છે

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

વિકલ્પ B ડેટાગ્રામ જરૂરી હોય તેવી કોઈપણ વસ્તુ માટે, પ્રોક્સી જે પ્રોટોકોલ સમજતી નથી તેના માટે, અને ચૂપચાપ એવા હોસ્ટ પર નિષ્ફળ જાય છે જ્યાં રીડાયરેક્ટ નિયમ અસ્તિત્વમાં છે પણ રાઉટિંગ ટ્રાફિકને તેની બાજુથી મોકલે છે.

કોઈ પણ વિકલ્પ ઉપકરણની જરૂરિયાત બદલતો નથી. કર્નલ રૂટ કરે તે પહેલાં પેકેટને હજી પણ TUN અથવા TAP નોડની જરૂર છે, તેથી પ્રક્રિયાને હજી પણ /dev/net/tun પર પરવાનગીની જરૂર છે. રેપર તે નોડ ખુલ્યા પછી શું થાય છે તે બદલે છે, તમને તેની જરૂર છે કે નહીં તે નહીં.

તમે કયો માર્ગ બનાવ્યો તે સાબિત કરો

ટ્રે આઇકોનને બદલે સોકેટ્સ જુઓ. VPN પ્રક્રિયાએ પ્રોક્સી સરનામા સાથે સ્થપાયેલું કનેક્શન રાખવું જોઈએ, અને પ્રોક્સીએ જે લક્ષ્ય સુધી પહોંચવાનું કહેવાયું હતું તે લોગ કર્યું હોવું જોઈએ:

ss -tnp | grep openvpn

પછી એવા ગંતવ્ય તરફ જાઓ જે ફક્ત ટનલ જ પૂરી પાડી શકે, અને એવા નામ તરફ જેનો જવાબ ફક્ત ટનલ રિઝોલ્વર જ આપી શકે. મૃત ટનલ સાથે પૂર્ણ થયેલું પ્રોક્સી કનેક્શન સામાન્ય રીતે એમ કહે છે કે દૂરનો છેડો તમારી પ્રોફાઇલમાં નામ આપેલું ટ્રાન્સપોર્ટ ક્યારેય ઓફર કર્યું નહોતું.

ટ્રાન્સપોર્ટ અને સ્વીકારતી પ્રોક્સી ટકાઉ જગ્યાએ નોંધો. જ્યારે એ જ પ્રોફાઇલ બીજા નેટવર્ક પર નિષ્ફળ જાય, ત્યારે તે નોંધ સેકન્ડોમાં પ્રોક્સીને બાદ કરે છે અથવા પુષ્ટિ કરે છે.