VPN eller proxy: hva hver av dem dekker, og hva den ikke dekker

Både en VPN og en forward-proxy endrer adressen et nettsted ser, og der stopper de fleste sammenligninger. Forskjellen som avgjør oppsettet ditt, er dekningen: en forward-proxy er et mellomledd som applikasjonen din selv velger å bruke, i motsetning til reverse-proxyen som står foran et nettsted, mens en VPN flytter alt operativsystemet ruter inn i en tunnel. Kryptering, DNS-håndtering og oppførsel ved feil følger alle av denne delingen. Kjør disse fem sjekkene i rekkefølge, og den første som feiler forteller deg hvilket verktøy du faktisk trenger.

Hvilke apper dekker mellomleddet?

En nettleser-proxyutvidelse gjelder bare for den nettleserprofilen. E-postklienter, pakkebehandlere og en annen nettleser fortsetter med sine egne innstillinger, og noen applikasjoner ignorerer systemets proxyvariabler helt. En VPN dekker det rutingtabellen sender inn i tunnelen, og det kan være alle applikasjoner eller et delsett ved split-tunnel avhengig av ruter og klientpolicy.

Test applikasjonene som betyr noe i stedet for å generalisere fra én sideinnlasting. curl https://ifconfig.me følger miljøets proxyvariabler; en skrivebordsapp gjør det kanskje ikke. På Windows skriver netsh winhttp show proxy ut WinHTTP-proxyen som tjenester bruker, og det er en annen innstilling enn nettleserens.

Er hoppet kryptert, og hvor slutter TLS?

En proxyprotokoll er et møtested, ikke en garanti. SOCKS5 videresender TCP uten å kryptere det, og en vanlig HTTP-proxy transporterer forespørselslinjen og hodene i klartekst. HTTPS gjennom en proxy bruker CONNECT, så TLS-økten din avsluttes fortsatt ved målet og ikke ved proxyen. MDNs veiledning om proxyservere og tunnellering beskriver denne forskjellen fra protokollsiden.

En VPN krypterer strekningen mellom enheten din og endepunktet. Utenfor endepunktet gjelder de samme reglene som på ethvert annet nettverk, og derfor beskytter en tunnel alene ikke en applikasjon som sender påloggingsinformasjon over vanlig HTTP. Ingen av de to designene skjuler en innlogget konto, en cookie eller et nettleseravtrykk.

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

Den detaljerte utdataen viser om curl sendte CONNECT til port 443 eller en vanlig GET med full URL. Med socks5h:// får proxyen vertsnavnet inne i SOCKS5-forespørselen og videresender deretter TLS som den ikke kan lese, så den ser navnet og antall byte. Gjennom en http://-proxy er en https://-URL en CONNECT, så den proxyen ser også målets navn og volum, men ikke forespørselen eller svarinnholdet.

Hvilken resolver ser navnet?

Navneoppslag kan skje lokalt før forespørselen forlater maskinen, eller eksternt hos proxyen. Med curl sender socks5h:// vertsnavnet til proxyen, mens socks5:// først løser det lokalt. Nettleserens proxyinnstillinger tilbyr et sammenlignbart DNS-alternativ, og PAC-filer kan rute ulike verter på ulike måter.

To protokoller kan omgå en proxy uten noen feilkonfigurering. WebRTC samler kandidater via STUN, og QUIC kjører HTTP/3 over UDP, som en TCP-proxy ikke kan transportere. Nettleseren faller tilbake til TCP hvis UDP 443 er blokkert, så å blokkere UDP 443 i vertens brannmur (eller på ruteren for et helt nettverk), og ikke et nettleserflagg, er den pålitelige måten å holde HTTP/3 på proxyveien.

Sjekk resolveren fra målets perspektiv, ikke fra laptopens. En forespørsel som ankommer med proxyens utgangsadresse, men med et lokalt løst navn, forteller fortsatt den lokale resolveren hvilke nettsteder du besøker.

Hva skjer når mellomleddet svikter?

En eksplisitt proxy svikter lukket: stopp proxyprosessen, og nettleseren eller appen returnerer en tilkoblingsfeil i stedet for å gå direkte. PAC- og WPAD-oppsett er de som svikter åpent - hvis skriptet ikke kan hentes, faller klienten tilbake til DIRECT, og nettstedet ser den ekte adressen din igjen. En VPN kan svikte åpent eller lukket avhengig av klienten og om en kill switch eller brannmurregel er aktiv.

Test feiltilfellet med vilje: stopp proxytjenesten og last inn på nytt; får du en feilside i stedet for en direkte innlasting, pek PAC-URL-en mot en utilgjengelig vert for å se fallbacken. Hvis siden fortsatt lastes inn via din vanlige rute, tilbyr proxyen ingen beskyttelse mot sin egen driftsstans, og det er en egenskap du bør kjenne før du stoler på den.

Rekkefølgen avgjør hva nettstedet ser. En proxy der den utgående trafikken går gjennom VPN-en, lar nettstedet se adressen til VPN-endepunktet; setter du proxyen utenfor tunnelen (VPN til en proxy på en ekstern vert), ser nettstedet i stedet utgangsadressen til den proxyen. Uansett kan de to hoppene logge forskjellige ting.

Fem sjekker, i rekkefølge

Sjekklisten nedenfor er hele beslutningen på ett sted. Dekningen kommer først fordi den fjerner de fleste avvikene: hvis appen som skal dekkes ikke respekterer innstillingen, redder ingenting lenger ned på listen den.

Bekreft deretter resultatet med appen som utløste endringen. Last en side i den konfigurerte nettleseren, hent den samme siden med curl, og sammenlign adressen hver av dem rapporterer. Hvis de er uenige, er en utvidelse, en PAC-regel eller en overstyring på appnivå fortsatt i spill, og ingen mengde tunneltilpasning vil rette det.

Noter hva du konfigurerte: hvilke apper som bruker proxyen, om DNS er lokalt eller eksternt, om UDP er blokkert, og hva oppførselen ved feil er. Nettopp denne lille oversikten gjør den neste sammenligningen mulig, fordi «IP-en endret seg» aldri fortalte deg hvilken av disse fem sjekkene som ble bestått.