VPN eller proxy: vad var och en täcker och vad den inte täcker

Både en VPN och en forward-proxy ändrar den adress som en webbplats ser, och det är där de flesta jämförelser slutar. Skillnaden som avgör din uppsättning är täckningen: en forward-proxy är en mellanhand som din applikation själv väljer att använda, till skillnad från den omvända proxyn framför en webbplats, medan en VPN flyttar allt som operativsystemet routar in i en tunnel. Kryptering, DNS-hantering och beteende vid fel följer alla av den uppdelningen. Kör dessa fem kontroller i ordning, och den första som misslyckas berättar vilket verktyg du faktiskt behöver.

Vilka appar täcker mellanhanden?

Ett webbläsartillägg för proxy gäller bara för den webbläsarprofilen. E-postklienter, pakethanterare och en andra webbläsare fortsätter med sina egna inställningar, och vissa applikationer ignorerar systemets proxyvariabler helt. En VPN täcker det som routingtabellen skickar in i tunneln, och det kan vara alla applikationer eller en delmängd vid delad tunnel beroende på rutter och klientpolicy.

Testa applikationerna som spelar roll i stället för att generalisera från en enda sidladdning. curl https://ifconfig.me följer miljöns proxyvariabler; en skrivbordsapp kanske inte gör det. På Windows skriver netsh winhttp show proxy ut den WinHTTP-proxy som tjänster använder, och det är en annan inställning än webbläsarens.

Är hoppet krypterat, och var slutar TLS?

Ett proxyprotokoll är en mötesplats, inte en garanti. SOCKS5 vidarebefordrar TCP utan att kryptera det, och en vanlig HTTP-proxy transporterar begäranderaden och rubrikerna i klartext. HTTPS via en proxy använder CONNECT, så din TLS-session slutar fortfarande vid målet och inte vid proxyn. MDN:s guide om proxyservrar och tunnling beskriver den skillnaden från protokollsidan.

En VPN krypterar sträckan mellan din enhet och dess slutpunkt. Bortom slutpunkten gäller samma regler som i alla andra nätverk, och därför skyddar en tunnel ensam inte en applikation som skickar inloggningsuppgifter över vanlig HTTP. Ingen av de två konstruktionerna döljer ett inloggat konto, en cookie eller ett webbläsarfingeravtryck.

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 utförliga utdata visar om curl skickade CONNECT till port 443 eller en vanlig GET med fullständig URL. Med socks5h:// får proxyn värdnamnet inne i SOCKS5-begäran och vidarebefordrar sedan TLS som den inte kan läsa, så den ser namnet och antalet byte. Genom en http://-proxy är en https://-URL en CONNECT, så den proxyn ser också målets namn och volym, men inte begäran eller svarskroppen.

Vilken resolver ser namnet?

Namnuppslagning kan ske lokalt innan begäran lämnar maskinen, eller på distans hos proxyn. Med curl skickar socks5h:// värdnamnet till proxyn, medan socks5:// först löser det lokalt. Webbläsarens proxyinställningar erbjuder ett jämförbart DNS-alternativ, och PAC-filer kan routa olika värdar på olika sätt.

Två protokoll kan kringgå en proxy utan någon felkonfigurering. WebRTC samlar kandidater via STUN, och QUIC kör HTTP/3 över UDP, vilket en TCP-proxy inte kan transportera. Webbläsaren faller tillbaka till TCP om UDP 443 är blockerat, så att blockera UDP 443 i värdens brandvägg (eller i routern för ett helt nätverk), och inte en webbläsarflagga, är det pålitliga sättet att hålla HTTP/3 på proxyvägen.

Kontrollera resolvern ur målets perspektiv, inte ur din laptops. En begäran som kommer med proxyns utgarssadress men med ett lokalt löst namn berättar fortfarande för den lokala resolvern vilka webbplatser du besöker.

Vad händer när mellanhanden fallerar?

En explicit proxy fallerar stängt: stoppa proxyprocessen och webbläsaren eller appen returnerar ett anslutningsfel i stället för att gå direkt. PAC- och WPAD-uppsättningar är de som fallerar öppet - om skriptet inte kan hämtas faller klienten tillbaka till DIRECT och webbplatsen ser din riktiga adress igen. En VPN kan fallera öppet eller stängt beroende på klienten och på om en kill switch eller brandväggsregel är aktiv.

Testa felet med avsikt: stoppa proxytjänsten och ladda om; får du en felsida i stället för en direkt laddning, peka PAC-URL:en mot en onåbar värd för att se reservbeteendet. Om sidan fortfarande laddas via din vanliga rutt erbjuder proxyn inget skydd mot sitt eget avbrott, och det är en egenskap du bör känna till innan du förlitar dig på den.

Ordningen avgör vad webbplatsen ser. En proxy vars utgående trafik går genom VPN:en låter webbplatsen se VPN-slutpunktens adress; sätt proxyn utanför tunneln (VPN till en proxy på en fjärrvärd) och webbplatsen ser i stället den proxyns utgarssadress. Hur som helst kan de två hoppen logga olika saker.

Fem kontroller, i ordning

Checklistan nedan är hela beslutet på ett ställe. Täckningen kommer först eftersom den eliminerar de flesta avvikelser: om appen som ska täckas inte respekterar inställningen räddar inget längre ner på listan den.

Bekräfta sedan resultatet med appen som utlöste ändringen. Ladda en sida i den konfigurerade webbläsaren, hämta samma sida med curl och jämför adressen som var och en rapporterar. Om de inte stämmer överens är ett tillägg, en PAC-regel eller en åsidosättning på appnivå fortfarande i spel, och ingen tunneljustering kommer att åtgärda det.

Anteckna vad du konfigurerade: vilka appar som använder proxyn, om DNS är lokalt eller på distans, om UDP är blockerat och vad beteendet vid fel är. Just den lilla inventeringen gör nästa jämförelse möjlig, eftersom ”IP-adressen ändrades” aldrig berättade vilken av dessa fem kontroller som klarades.