VPN of proxy: wat elk dekt en wat niet

Zowel een VPN als een forward-proxy verandert het adres dat een website ziet, en daar stoppen de meeste vergelijkingen. Het verschil dat je opstelling bepaalt, is dekking: een forward-proxy is een tussenpersoon die je applicatie zelf kiest te gebruiken, anders dan de reverse-proxy vóór een website, terwijl een VPN alles verplaatst wat het besturingssysteem naar een tunnel routeert. Versleuteling, DNS-afhandeling en faalgedrag volgen allemaal uit die splitsing. Voer deze vijf controles op volgorde uit, en de eerste die faalt vertelt je welk hulpmiddel je echt nodig hebt.

Welke apps dekt de tussenpersoon?

Een proxy-extensie in de browser geldt alleen voor dat browserprofiel. Mailclients, pakketbeheerders en een tweede browser blijven hun eigen instellingen gebruiken, en sommige applicaties negeren de proxyvariabelen van het systeem volledig. Een VPN dekt wat de routetabel de tunnel in stuurt, en dat kunnen alle applicaties zijn of een subset bij een split-tunnel, afhankelijk van routes en clientbeleid.

Test de applicaties die ertoe doen in plaats van te generaliseren op basis van één paginalading. curl https://ifconfig.me volgt de proxyvariabelen van de omgeving; een desktopapp misschien niet. Op Windows drukt netsh winhttp show proxy de WinHTTP-proxy af die diensten gebruiken, en dat is een andere instelling dan die van de browser.

Is de hop versleuteld, en waar eindigt TLS?

Een proxyprotocol is een ontmoetingspunt, geen garantie. SOCKS5 stuurt TCP door zonder het te versleutelen, en een gewone HTTP-proxy draagt de verzoekregel en headers in platte tekst. HTTPS via een proxy gebruikt CONNECT, dus je TLS-sessie eindigt nog steeds bij de bestemming en niet bij de proxy. De MDN-gids over proxyservers en tunneling beschrijft dat onderscheid vanaf de protocolkant.

Een VPN versleutelt het traject tussen je apparaat en zijn eindpunt. Voorbij het eindpunt gelden dezelfde regels als op elk ander netwerk, en daarom beschermt een tunnel alleen geen applicatie die inloggegevens over gewone HTTP verstuurt. Geen van beide ontwerpen verbergt een ingelogd account, een cookie of een browserfingerafdruk.

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

De uitgebreide uitvoer laat zien of curl CONNECT naar poort 443 heeft gestuurd of een gewone GET met een volledige URL. Met socks5h:// krijgt de proxy de hostnaam binnen het SOCKS5-verzoek en stuurt die daarna TLS door dat hij niet kan lezen, dus hij ziet de naam en het byteaantal. Via een http://-proxy is een https://-URL een CONNECT, dus die proxy ziet ook de naam en het volume van de bestemming, maar niet het verzoek of de antwoordbody.

Welke resolver ziet de naam?

Naamresolutie kan lokaal gebeuren voordat het verzoek vertrekt, of op afstand bij de proxy. Met curl stuurt socks5h:// de hostnaam naar de proxy, terwijl socks5:// hem eerst lokaal oplost. Proxyinstellingen van de browser bieden een vergelijkbare DNS-optie, en PAC-bestanden kunnen verschillende hosts op verschillende manieren routeren.

Twee protocollen kunnen een proxy omzeilen zonder enige verkeerde configuratie. WebRTC verzamelt kandidaten via STUN, en QUIC draait HTTP/3 over UDP, wat een TCP-proxy niet kan dragen. De browser valt terug op TCP als UDP 443 geblokkeerd is, dus UDP 443 blokkeren in de firewall van de host (of op de router voor een heel netwerk), en niet een browservlag, is de betrouwbare manier om HTTP/3 in het proxypad te houden.

Controleer de resolver vanuit het perspectief van de bestemming, niet van je laptop. Een verzoek dat aankomt met het uitgaande adres van de proxy maar met een lokaal opgeloste naam, vertelt de lokale resolver nog steeds welke sites je bezoekt.

Wat gebeurt er als de tussenpersoon uitvalt?

Een expliciete proxy faalt gesloten: stop het proxyproces en de browser of app geeft een verbindingsfout in plaats van direct te gaan. PAC- en WPAD-opstellingen zijn degenen die open falen - als het script niet kan worden opgehaald, valt de client terug op DIRECT en ziet de site weer je echte adres. Een VPN kan open of gesloten falen, afhankelijk van de client en of een kill switch of firewallregel actief is.

Test het faalgeval met opzet: stop de proxydienst en herlaad; krijg je een foutpagina in plaats van een directe lading, richt de PAC-URL dan op een onbereikbare host om de terugval te zien. Als de pagina nog steeds via je gewone route laadt, biedt de proxy geen bescherming tegen zijn eigen uitval, en dat is een eigenschap die je moet kennen voordat je erop vertrouwt.

De volgorde bepaalt wat de site ziet. Een proxy waarvan het uitgaande verkeer via de VPN loopt, laat de site het adres van het VPN-eindpunt zien; zet de proxy buiten de tunnel (VPN naar een proxy op een externe host) en de site ziet in plaats daarvan het uitgaande adres van die proxy. Hoe dan ook kunnen de twee hops verschillende dingen loggen.

Vijf controles, op volgorde

De checklist hieronder is de hele beslissing op één plek. Dekking komt eerst omdat het de meeste mismatches wegneemt: als de app die gedekt moet worden de instelling niet respecteert, redt niets verderop in de lijst het.

Bevestig daarna het resultaat met de app die de wijziging veroorzaakte. Laad een pagina in de geconfigureerde browser, haal dezelfde pagina met curl op, en vergelijk het adres dat elk rapporteert. Als ze verschillen, is een extensie, een PAC-regel of een overschrijving op appniveau nog in het spel, en geen enkele tunnelafstelling lost dat op.

Noteer wat je hebt geconfigureerd: welke apps de proxy gebruiken, of DNS lokaal of op afstand is, of UDP geblokkeerd is, en wat het faalgedrag is. Juist die kleine inventaris maakt de volgende vergelijking mogelijk, want „het IP is veranderd” heeft je nooit verteld welke van deze vijf controles slaagde.