VPN kontra proxy: hvad hver af dem dækker, og hvad den ikke gør

Både en VPN og en forward-proxy ændrer den adresse, et websted ser, og det er her de fleste sammenligninger stopper. Forskellen, der afgør din opsætning, er dækningen: en forward-proxy er et mellemled, som din applikation selv vælger at bruge, i modsætning til den reverse proxy, der står foran et websted, mens en VPN flytter alt, hvad styresystemet ruter ind i en tunnel. Kryptering, håndtering af DNS og fejlopførsel følger alle af den opdeling. Kør disse fem kontroller i rækkefølge, og den første, der fejler, fortæller dig, hvilket værktøj du reelt har brug for.

Hvilke applikationer dækker mellemleddet?

En browser-proxyudvidelse gælder kun for den browserprofil. Mailklienter, pakkehåndterere og en anden browser fortsætter med deres egne indstillinger, og nogle applikationer ignorerer systemets proxyvariabler helt. En VPN dækker det, routingtabellen sender ind i tunnelen, og det kan være alle applikationer eller en delmængde ved split-tunnel afhængigt af ruter og klientpolitik.

Test de applikationer, der betyder noget, i stedet for at generalisere ud fra én sideindlæsning. curl https://ifconfig.me følger miljøets proxyvariabler; en desktopapp gør måske ikke. På Windows udskriver netsh winhttp show proxy den WinHTTP-proxy, som tjenester bruger, og det er en anden indstilling end browserens.

Er hoppet krypteret, og hvor slutter TLS?

En proxyprotokol er et mødested, ikke en garanti. SOCKS5 videresender TCP uden at kryptere det, og en almindelig HTTP-proxy transporterer anmodningslinjen og headere i klartekst. HTTPS gennem en proxy bruger CONNECT, så din TLS-session slutter stadig ved destinationen og ikke ved proxyen. MDNs guide til proxyservere og tunellering beskriver den forskel fra protokolsiden.

En VPN krypterer strækningen mellem din enhed og dens endepunkt. Ud over endepunktet gælder de samme regler som på ethvert andet netværk, og derfor beskytter en tunnel alene ikke en applikation, der sender legitimationsoplysninger over almindelig HTTP. Ingen af de to design skjuler en logget ind-konto, en cookie eller et browser-fingeraftryk.

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

Det detaljerede output viser, om curl har sendt CONNECT til port 443 eller et almindeligt GET med en fuld URL. Med socks5h:// får proxyen værtsnavnet inde i SOCKS5-anmodningen og videresender derefter TLS, som den ikke kan læse, så den ser navnet og byteantallet. Gennem en http://-proxy er en https://-URL et CONNECT, så den proxy ser også destinationens navn og volumen, men ikke anmodningen eller svarlegemet.

Hvilken resolver ser navnet?

Navneopløsning kan ske lokalt, før anmodningen forlader maskinen, eller eksternt hos proxyen. Med curl sender socks5h:// værtsnavnet til proxyen, mens socks5:// først opløser det lokalt. Browserens proxyindstillinger giver en tilsvarende DNS-mulighed, og PAC-filer kan rute forskellige værter på forskellige måder.

To protokoller kan omgå en proxy uden nogen fejlkonfiguration. WebRTC indsamler kandidater via STUN, og QUIC kører HTTP/3 over UDP, som en TCP-proxy ikke kan transportere. Browseren falder tilbage til TCP, hvis UDP 443 er blokeret, så at blokere UDP 443 i værtens firewall (eller på routeren for et helt netværk), og ikke et browserflag, er den pålidelige måde at holde HTTP/3 på proxyvejen.

Kontroller resolveren fra destinationens perspektiv, ikke fra din laptops. En anmodning, der ankommer med proxyens udgangsadresse, men med et lokalt opløst navn, fortæller stadig den lokale resolver, hvilke sider du besøger.

Hvad sker der, når mellemleddet svigter?

En eksplicit proxy fejler lukket: stop proxyprocessen, og browseren eller appen returnerer en forbindelsesfejl i stedet for at gå direkte. PAC- og WPAD-opsætninger er dem, der fejler åbent - hvis scriptet ikke kan hentes, falder klienten tilbage til DIRECT, og webstedet ser igen din rigtige adresse. En VPN kan fejle åbent eller lukket afhængigt af klienten, og om en kill switch eller firewallregel er aktiv.

Test fejltilfældet med vilje: stop proxytjenesten, og genindlæs; får du en fejlside i stedet for en direkte indlæsning, så peg PAC-URL'en på en utilgængelig vært for at se fallbacken. Hvis siden stadig indlæses ad din sædvanlige rute, giver proxyen ingen beskyttelse mod sit eget nedbrud, og det er en egenskab, du bør kende, før du stoler på den.

Rækkefølgen afgør, hvad webstedet ser. En proxy, hvis udgående trafik går gennem VPN'en, efterlader webstedet med VPN-endepunktets adresse; sæt proxyen uden for tunnelen (VPN til en proxy på en fjern vært), og webstedet ser i stedet proxyens udgangsadresse. Under alle omstændigheder kan de to hop logge forskellige ting.

Fem kontroller, i rækkefølge

Tjeklisten nedenfor er hele beslutningen på ét sted. Dækning kommer først, fordi den fjerner de fleste uoverensstemmelser: hvis den applikation, der skal dækkes, ikke respekterer indstillingen, redder intet senere på listen den.

Bekræft derefter resultatet med den applikation, der udløste ændringen. Indlæs en side i den konfigurerede browser, hent den samme side med curl, og sammenlign den adresse, hver af dem rapporterer. Hvis de er uenige, er en udvidelse, en PAC-regel eller en tilsidesættelse på appniveau stadig i spil, og ingen mængde af tuneljustering vil rette det.

Notér, hvad du konfigurerede: hvilke applikationer der bruger proxyen, om DNS er lokalt eller eksternt, om UDP er blokeret, og hvad fejlopførslen er. Det lille inventar er det, der gør den næste sammenligning mulig, fordi “IP'en ændrede sig” aldrig fortalte dig, hvilken af disse fem kontroller der bestod.