VPN verbonden maar het IP-adres is niet veranderd: waarom

Je maakt verbinding, de client zegt verbonden, en de adrestest toont nog steeds hetzelfde nummer als daarvoor. Er is niets mis met de indicator; iets tussen het profiel en de app hield dat verzoek buiten de tunnel. Bepaal op welk van drie dingen je kijkt voordat je aan welke configuratie dan ook komt: een test die nooit het openbare adres heeft gemeten, een tunnel die maar een deel van het verkeer dekt, of een tweede pad dat de routeringsbeslissing wint. Elk heeft één controle die minder dan een minuut duurt.

Bevestig wat de test werkelijk heeft gemeten

Het adres in het Wi-Fi- of Ethernet-venster is het interfaceadres op je eigen segment, niet het adres dat een website ziet, dus het kan gelijk blijven terwijl de tunnel perfect werkt. Locatie is weer een apart signaal: een opgeslagen accountregio of een toegestane geolocatiefuitlezing beweegt niet mee als je van exit wisselt, en een login die je al herkent ook niet.

Gebruik een echo van het openbare adres en vraag elke familie apart, want een testresultaat met dubbele stack verbergt het interessante geval:

curl -4 -s https://ifconfig.me
curl -6 -s https://ifconfig.me

Voer beide uit voor en na het verbinden. Als het IPv4-antwoord naar het exitadres verandert en het IPv6-antwoord niet, heb je geen kapotte tunnel; één familie reist erbuiten. Als beide antwoorden gelijk blijven, heeft het verzoek de tunnel nooit bereikt en geldt de rest hiervan.

Het profiel dekt misschien maar een deel van het verkeer

Een profiel met split-tunneling is het gebruikelijke antwoord, en het is geen fout. OpenVPN stuurt alles alleen door de tunnel als redirect-gateway in de gepushte opties staat; zonder dat krijgt de client een handvol specifieke routes en blijft je standaardroute op de fysieke verbinding. Op Windows verschijnt dezelfde schakelaar als „Standaardgateway op extern netwerk gebruiken” in de IPv4-eigenschappen van de adapter, en hem uitzetten is een bewuste keuze die elke herverbinding overleeft.

App-bereik is de tweede laag. De VPN-instelling per app in Android bepaalt welke apps zijn inbegrepen, dus de VPN-sleutel in de statusbalk bewijst niet dat de browser erin zit. Een browserextensie die zijn eigen verkeer proxyt, maakt het spiegelbeeld: de browser toont het exitadres terwijl een mailclient of game op dezelfde machine nog het jouwe toont. Vergelijk hetzelfde verzoek in twee apps. Als de ene verandert en de andere niet, kijk je naar bereik, niet naar een falende tunnel.

Eén adresfamilie kan nog steeds direct gaan

De meeste VPN-profielen zijn voor IPv4 geschreven, en veel nog steeds. Op een netwerk met dubbele stack neemt de tunnel 10.8.0.x voor IPv4 terwijl de fysieke verbinding een wereldwijd IPv6-adres en een standaardroute houdt, dus een site met IPv6-ondersteuning wordt direct bereikt en het adres dat hij meldt is dat van je provider. Dat is een lek met een werkende IPv4-tunnel, en het is onzichtbaar voor een test die alleen IPv4 spreekt.

ip -4 route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Lees de interface in elk antwoord. Als de IPv6-opzoeking je Ethernet- of Wi-Fi-apparaat noemt terwijl de IPv4-opzoeking de tunnel noemt, ontbreekt het beleid voor die familie in plaats van kapot te zijn. IPv6 op het hele apparaat uitzetten laat het symptoom verdwijnen en verbergt de beslissing; repareer liever de dekking van het profiel of schakel de familie alleen op die verbinding uit, en noteer welke van de twee je hebt gekozen.

Een tweede pad kan de opzoeking winnen

Een concurrerende proxy, een tweede VPN-client, een virtuele adapter van een container of extern-bureaubladtool, of een extra route voor precies het prefix dat je test kunnen allemaal voorrang krijgen. Een specifieke route verslaat altijd een standaardroute, dus een overgebleven /24 voor de site die je meet, wijzend naar je LAN-gateway, blijft dat verkeer buiten de tunnel sturen hoe gezond de tunnel ook is.

Maak een inventaris voordat je iets verandert, met alleen-lezen-opdrachten:

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
nmcli connection show --active

Zoek naar meer dan één standaardroute met een plausibele metriek, en naar een specifieke route die de bestemming dekt. Controleer in een browser ook of een proxy-extensie of de systeemproxyinstelling de verbinding bezit; een extensie kan zijn eigen upstream noemen en de uitgang van het besturingssysteem ongemoeid laten, wat in de browser een ander adres oplevert dan in een terminal op dezelfde machine.

Meet opnieuw met een vers verzoek

Verbind opnieuw en herhaal daarna de meting vanuit dezelfde app waarmee je de eerste keer testte, want een gecachte pagina of een hergebruikte verbinding meldt de oude toestand. Let tijdens het verbinden op het log of de gebeurtenisweergave van de client: een fout bij het toepassen van routes na authenticatie is sterker bewijs dan welke indicator ook, en noemt meestal de route of adapter die faalde.

Houd twee uitkomsten apart. Als het adres verandert maar één site je nog weigert, werkt de tunnel en weigert de site een datacenteradres; dat is een ander probleem met een ander antwoord. Als het adres nooit verandert, werk de vier vragen in volgorde af: welk adres de test afdrukte, welke familie het was, welke app het verzoek deed en welke route dat verzoek volgde. De Microsoft-documentatie over VPN-routeringsbeslissingen legt uit hoe een Windows-client kiest tussen de tunnel en de fysieke adapter wanneer beide een route hebben.