VPN är ansluten men IP-adressen har inte ändrats: varför

Du ansluter, klienten säger ansluten, och adresstestet visar fortfarande samma nummer som du hade tidigare. Det är inget fel på indikatorn; något mellan profilen och appen höll den förfrågan utanför tunneln. Bestäm vilket av tre saker du tittar på innan du rör någon konfiguration: ett test som aldrig mätte den offentliga adressen, en tunnel som bara täcker en del av trafiken, eller en andra väg som vinner routingbeslutet. Varje har en kontroll som tar mindre än en minut.

Bekräfta vad testet faktiskt mätte

Adressen i Wi-Fi- eller Ethernet-dialogen är gränssnittsadressen på ditt eget segment, inte adressen som en webbplats ser, så den kan förbli identisk medan tunneln fungerar perfekt. Platsen är återigen en separat signal: en sparad kontoregion eller en tillåten geolokationsläsning flyttar sig inte när du byter utgång, och det gör inte heller en inloggning som redan känner igen dig.

Använd ett eko av den offentliga adressen och fråga varje familj separat, eftersom ett testresultat med dubbel stack döljer det intressanta fallet:

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

Kör båda före och efter anslutning. Om IPv4-svaret ändras till utgångsadressen och IPv6-svaret inte, har du ingen trasig tunnel; en familj reser utanför den. Om båda svaren förblir desamma, nådde förfrågan aldrig tunneln och resten här gäller.

Profilen kan bara täcka en del av trafiken

En profil med delad tunnel är det vanliga svaret, och det är inget fel. OpenVPN skickar allt genom tunneln bara när redirect-gateway finns bland de pushade alternativen; utan den får klienten en handfull specifika rutter och din standardrutt stannar på den fysiska länken. I Windows visas samma brytare som ”Använd standardgateway på fjärrnätverket” i adapterns IPv4-egenskaper, och att rensa den är ett medvetet val som överlever varje återanslutning.

Omfattning per app är det andra lagret. Androids VPN-inställning per app avgör vilka appar som ingår, så VPN-nyckeln i statusfältet bevisar inte att webbläsaren finns inuti. En webbläsartillägg som proxar sin egen trafik skapar spegelbilden: webbläsaren visar utgångsadressen medan en e-postklient eller ett spel på samma maskin fortfarande visar din. Jämför samma förfrågan i två appar. Om den ena ändras och den andra inte, tittar du på omfattning, inte på en misslyckad tunnel.

En adressfamilj kan fortfarande gå direkt

De flesta VPN-profiler är skrivna för IPv4, och många är det fortfarande. På ett nätverk med dubbel stack tar tunneln 10.8.0.x för IPv4 medan den fysiska länken behåller en global IPv6-adress och en standardrutt, så en webbplats med IPv6-stöd nås direkt och adressen den rapporterar är din leverantörs. Det är en läcka med en fungerande IPv4-tunnel, och den är osynlig för ett test som bara talar IPv4.

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

Läs gränssnittet i varje svar. Om IPv6-sökningen namnger din Ethernet- eller Wi-Fi-enhet medan IPv4-sökningen namnger tunneln, saknas policyn för den familjen i stället för att vara trasig. Att stänga av IPv6 på hela enheten får symtomet att försvinna och döljer beslutet; reparera hellre profilens täckning eller inaktivera familjen bara på den anslutningen, och notera vilken av de två du valde.

En andra väg kan vinna sökningen

En konkurrerande proxy, en andra VPN-klient, en virtuell adapter från en container eller ett fjärrskrivbordsverktyg, eller en extra rutt för det exakta prefixet du testar kan alla få företräde. En specifik rutt slår alltid en standardrutt, så en kvarvarande /24 för webbplatsen du mäter, som pekar på din LAN-gateway, fortsätter att skicka trafiken utanför tunneln hur sund tunneln än är.

Gör en inventering innan du ändrar något, med skrivskyddade kommandon:

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

Leta efter mer än en standardrutt med ett rimligt mått, och efter en specifik rutt som täcker destinationen. I en webbläsare, kontrollera också om ett proxytillägg eller systemets proxyinställning äger anslutningen; ett tillägg kan namnge sin egen uppströms och lämna operativsystemets utgång orörd, vilket ger en annan adress i webbläsaren än i en terminal på samma maskin.

Mät igen med en ny förfrågan

Anslut igen och upprepa sedan mätningen från samma app som du testade första gången, eftersom en cachad sida eller en återanvänd anslutning rapporterar det gamla tillståndet. Följ klientens logg eller händelsevy under anslutningen: ett fel när rutter tillämpas efter autentisering är starkare bevis än någon indikator, och det namnger vanligtvis rutten eller adaptern som misslyckades.

Håll två utfall isär. Om adressen ändras men en webbplats fortfarande vägrar dig, fungerar tunneln och webbplatsen avvisar en datacenteradress; det är ett annat problem med ett annat svar. Om adressen aldrig ändras, gå igenom de fyra frågorna i ordning: vilken adress testet skrev ut, vilken familj det var, vilken app som gjorde förfrågan och vilken rutt den förfrågan följde. Microsofts dokumentation om VPN-routingbeslut förklarar hur en Windows-klient väljer mellan tunneln och den fysiska adaptern när båda har en rutt.