VPN વિરુદ્ધ પ્રોક્સી: દરેક શું આવરે છે અને શું નહીં
VPN રૂટ કરેલી એપ્લિકેશન ટ્રાફિક આવરે છે; પ્રોક્સી ફક્ત તમે ગોઠવેલી એપ્લિકેશન આવરે છે. પસંદ કરતા પહેલાં કવરેજ, એન્ક્રિપ્શન, DNS અને નિષ્ફળતાનું વર્તન તપાસો.
VPN અને ફોરવર્ડ પ્રોક્સી બંને વેબસાઇટ જે સરનામું જુએ છે તે બદલે છે, અને મોટાભાગની તુલના ત્યાં જ અટકે છે. તમારું સેટઅપ નક્કી કરતો તફાવત કવરેજ છે: ફોરવર્ડ પ્રોક્સી એ વચેટિયો છે જેનો ઉપયોગ તમારી એપ્લિકેશન પોતે પસંદ કરે છે, વેબસાઇટની સામે બેસતા રિવર્સ પ્રોક્સીથી વિપરીત, જ્યારે VPN ઓપરેટિંગ સિસ્ટમ જે ટનલમાં રૂટ કરે છે તે બધું ખસેડે છે. એન્ક્રિપ્શન, DNS સંચાલન અને નિષ્ફળતાનું વર્તન એ બધું આ વિભાજનમાંથી આવે છે. આ પાંચ તપાસ ક્રમમાં ચલાવો, અને નિષ્ફળ જતી પહેલી તપાસ તમને કહેશે કે તમને ખરેખર કયું સાધન જોઈએ છે.
વચેટિયો કઈ એપ્લિકેશનો આવરે છે?
બ્રાઉઝર પ્રોક્સી એક્સ્ટેન્શન ફક્ત તે બ્રાઉઝર પ્રોફાઇલ પર લાગુ થાય છે. મેઇલ ક્લાયન્ટ, પેકેજ મેનેજર અને બીજું બ્રાઉઝર પોતાની ગોઠવણો વાપરતા રહે છે, અને કેટલીક એપ્લિકેશનો સિસ્ટમ પ્રોક્સી ચલોને સંપૂર્ણપણે અવગણે છે. VPN એ આવરે છે જે રૂટિંગ ટેબલ ટનલમાં મોકલે છે, જે રૂટ અને ક્લાયન્ટ નીતિના આધારે બધી એપ્લિકેશનો અથવા સ્પ્લિટ ટનલમાં ઉપસમૂહ હોઈ શકે છે.
એક પૃષ્ઠ લોડ પરથી અનુમાન કરવાને બદલે મહત્વની એપ્લિકેશનોની કસોટી કરો. curl https://ifconfig.me એન્વાયર્નમેન્ટ પ્રોક્સી ચલોને અનુસરે છે; ડેસ્કટોપ એપ્લિકેશન ન પણ કરે. Windows પર netsh winhttp show proxy સેવાઓ જે WinHTTP પ્રોક્સી વાપરે છે તે છાપે છે, અને તે બ્રાઉઝરની ગોઠવણથી અલગ ગોઠવણ છે.
શું હોપ એન્ક્રિપ્ટેડ છે, અને TLS ક્યાં પૂરું થાય છે?
પ્રોક્સી પ્રોટોકોલ એ મિલનસ્થળ છે, ખાતરી નહીં. SOCKS5 TCP ને એન્ક્રિપ્ટ કર્યા વિના મોકલે છે, અને સાદો HTTP પ્રોક્સી વિનંતી લાઇન અને હેડર સ્પષ્ટ ટેક્સ્ટમાં વહન કરે છે. પ્રોક્સી દ્વારા HTTPS CONNECT વાપરે છે, તેથી તમારું TLS સત્ર પ્રોક્સી પર નહીં, ગંતવ્ય પર જ પૂરું થાય છે. પ્રોક્સી સર્વર અને ટનલિંગ વિશેની MDN માર્ગદર્શિકા પ્રોટોકોલની બાજુથી એ તફાવત વર્ણવે છે.
VPN તમારા ઉપકરણ અને તેના એન્ડપોઇન્ટ વચ્ચેનો ભાગ એન્ક્રિપ્ટ કરે છે. એન્ડપોઇન્ટની બહાર બીજા કોઈપણ નેટવર્ક જેવા જ નિયમો લાગુ પડે છે, તેથી ફક્ત ટનલ સાદા HTTP પર ઓળખપત્ર મોકલતી એપ્લિકેશનને સુરક્ષિત કરતી નથી. બંનેમાંથી કોઈ ડિઝાઇન લોગિન થયેલું ખાતું, કૂકી કે બ્રાઉઝર ફિંગરપ્રિન્ટ છુપાવતી નથી.
curl -v -x http://127.0.0.1:3128 https://example.com/ -o /dev/null
curl -v -x socks5h://127.0.0.1:1080 https://example.com/ -o /dev/nullવિગતવાર આઉટપુટ દર્શાવે છે કે curl એ પોર્ટ 443 પર CONNECT મોકલ્યું છે કે પૂર્ણ URL સાથે સાદું GET. socks5h:// સાથે હોસ્ટનામ SOCKS5 વિનંતીની અંદર પ્રોક્સીને આપવામાં આવે છે અને પછી તે TLS રિલે કરે છે જે તે વાંચી શકતું નથી, તેથી તે નામ અને બાઇટની ગણતરી જુએ છે. http:// પ્રોક્સી દ્વારા https:// URL એ CONNECT છે, તેથી તે પ્રોક્સી પણ ગંતવ્યનું નામ અને કદ જુએ છે, વિનંતી કે પ્રતિસાદનું શરીર નહીં.
કયો રિઝોલ્વર નામ જુએ છે?
નામ-ઉકેલ વિનંતી નીકળે તે પહેલાં સ્થાનિક રીતે થઈ શકે છે, અથવા પ્રોક્સી પર દૂરથી. curl સાથે socks5h:// હોસ્ટનામ પ્રોક્સીને મોકલે છે જ્યારે socks5:// પહેલાં તેને સ્થાનિક રીતે ઉકેલે છે. બ્રાઉઝર પ્રોક્સી ગોઠવણો સરખાવી શકાય એવો DNS વિકલ્પ આપે છે, અને PAC ફાઇલો જુદા જુદા હોસ્ટને જુદી જુદી રીતે રૂટ કરી શકે છે.
બે પ્રોટોકોલ કોઈપણ ખોટી ગોઠવણ વિના પ્રોક્સીને ટાળી શકે છે. WebRTC STUN દ્વારા ઉમેદવારો એકત્ર કરે છે, અને QUIC UDP પર HTTP/3 ચલાવે છે, જે TCP પ્રોક્સી વહન કરી શકતું નથી. UDP 443 અવરોધિત હોય તો બ્રાઉઝર TCP પર પાછું આવશે, તેથી હોસ્ટ ફાયરવોલ પર (અથવા આખા નેટવર્ક માટે રાઉટર પર) UDP 443 અવરોધવું, બ્રાઉઝર ફ્લેગ નહીં, HTTP/3 ને પ્રોક્સી માર્ગમાં રાખવાનો વિશ્વસનીય રસ્તો છે.
રિઝોલ્વરને તમારા લેપટોપની દૃષ્ટિએ નહીં, ગંતવ્યની દૃષ્ટિએ તપાસો. જે વિનંતી પ્રોક્સીના એગ્ઝિટ સરનામા સાથે પણ સ્થાનિક રીતે ઉકેલાયેલા નામ સાથે આવે છે તે સ્થાનિક રિઝોલ્વરને તમે કઈ સાઇટ્સ મુલાકાત લો છો તે જણાવે જ છે.
વચેટિયો નિષ્ફળ જાય ત્યારે શું થાય છે?
સ્પષ્ટ પ્રોક્સી બંધ રીતે નિષ્ફળ જાય છે: પ્રોક્સી પ્રોસેસ બંધ કરો અને બ્રાઉઝર કે એપ્લિકેશન સીધું જવાને બદલે કનેક્શન ભૂલ આપે છે. PAC અને WPAD ગોઠવણો એ છે જે ખુલ્લી રીતે નિષ્ફળ જાય છે - જો સ્ક્રિપ્ટ મળી ન શકે, તો ક્લાયન્ટ DIRECT પર પાછો આવે છે અને સાઇટ ફરી તમારું સાચું સરનામું જુએ છે. VPN ક્લાયન્ટ પર અને કિલ સ્વિચ કે ફાયરવોલ નિયમ સક્રિય છે કે નહીં તેના પર આધાર રાખીને ખુલ્લી કે બંધ રીતે નિષ્ફળ જઈ શકે છે.
નિષ્ફળતાના કિસ્સાને જાણી જોઈને કસોટી કરો: પ્રોક્સી સેવા બંધ કરીને ફરી લોડ કરો; સીધા લોડને બદલે ભૂલ પૃષ્ઠ મળે તો ફોલબેક જોવા માટે PAC URL ને અપહંચનીય હોસ્ટ પર મોકલો. જો પૃષ્ઠ હજી પણ તમારા સામાન્ય માર્ગે લોડ થાય, તો પ્રોક્સી પોતાની અડચણ સામે કોઈ રક્ષણ આપતું નથી, અને તે એવી લાક્ષણિકતા છે જે તેના પર ભરોસો કરતા પહેલાં જાણવી જોઈએ.
ક્રમ નક્કી કરે છે કે સાઇટ શું જુએ છે. જે પ્રોક્સીનું આઉટબાઉન્ડ VPN દ્વારા જાય છે તે સાઇટને VPN એન્ડપોઇન્ટનું સરનામું દેખાડે છે; પ્રોક્સીને ટનલની બહાર મૂકો (દૂરના હોસ્ટ પરની પ્રોક્સી સુધી VPN) અને સાઇટ તેના બદલે તે પ્રોક્સીનું એગ્ઝિટ સરનામું જુએ છે. બંને રીતે બે હોપ જુદી જુદી વસ્તુઓ લોગ કરી શકે છે.
પાંચ તપાસ, ક્રમમાં
નીચેની ચેકલિસ્ટ એ આખો નિર્ણય એક જ જગ્યાએ છે. કવરેજ પહેલું આવે છે કારણ કે તે મોટાભાગની અસંગતિ દૂર કરે છે: જે એપ્લિકેશન આવરવી છે તે ગોઠવણનું પાલન ન કરે, તો યાદીમાં પછીનું કંઈ પણ તેને બચાવતું નથી.
| Check | Forward proxy | VPN |
|---|---|---|
| What is covered | The app or browser you configure | Traffic the OS routes into the tunnel, all or split |
| Encryption scope | Protocol-dependent; SOCKS5 alone encrypts nothing | Device to VPN endpoint |
| DNS path | Local or remote, depending on the setting | Normally inside the tunnel |
| Failure mode | Explicit config: connection error; PAC/WPAD: DIRECT fallback | Client policy: fail-open or kill switch |
| What the site sees | The proxy's exit address | The VPN endpoint's exit address |
પછી પરિણામને તે એપ્લિકેશન સાથે પુષ્ટિ કરો જેના કારણે ફેરફાર થયો. ગોઠવેલા બ્રાઉઝરમાં પૃષ્ઠ લોડ કરો, curl સાથે એ જ પૃષ્ઠ મેળવો, અને દરેક જે સરનામું જણાવે છે તેની તુલના કરો. જો તેઓ અસહમત હોય, તો એક્સ્ટેન્શન, PAC નિયમ કે એપ્લિકેશન સ્તરનું ઓવરરાઇડ હજી કાર્યરત છે, અને ટનલ ટ્યુનિંગની કોઈ માત્રા તેને ઠીક કરશે નહીં.
તમે શું ગોઠવ્યું તે નોંધો: કઈ એપ્લિકેશનો પ્રોક્સી વાપરે છે, DNS સ્થાનિક છે કે દૂરનું, UDP અવરોધિત છે કે નહીં, અને નિષ્ફળતાનું વર્તન શું છે. એ નાની યાદી જ આગળની તુલના શક્ય બનાવે છે, કારણ કે “IP બદલાયું” એ તમને ક્યારેય ન કહ્યું કે આ પાંચ તપાસમાંથી કઈ પસાર થઈ.