VPN er tilkoblet, men IP-adressen er ikke endret: hvorfor

Du kobler til, klienten sier tilkoblet, og adresstesten viser fortsatt det samme tallet du hadde før. Det er ingenting galt med indikatoren; noe mellom profilen og appen holdt den forespørselen utenfor tunnelen. Avgjør hvilken av tre ting du ser på før du rører noen konfigurasjon: en test som aldri målte den offentlige adressen, en tunnel som bare dekker en del av trafikken, eller en annen vei som vinner rutingsbeslutningen. Hver har én sjekk som tar under ett minutt.

Bekreft hva testen faktisk målte

Adressen i Wi-Fi- eller Ethernet-dialogen er grensesnittadressen på ditt eget segment, ikke adressen et nettsted ser, så den kan forbli lik mens tunnelen fungerer perfekt. Posisjon er igjen et eget signal: en lagret kontoregion eller en tillatt geolokasjonslesing flytter seg ikke når du bytter exit, og det gjør heller ikke en innlogging som allerede kjenner deg igjen.

Bruk et ekko av den offentlige adressen og spør hver familie separat, fordi et testresultat med dobbel stack skjuler det interessante tilfellet:

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

Kjør begge før og etter tilkobling. Hvis IPv4-svaret endres til exit-adressen og IPv6-svaret ikke, har du ikke en ødelagt tunnel; én familie reiser utenfor den. Hvis begge svarene blir de samme, nådde forespørselen aldri tunnelen og resten her gjelder.

Profilen dekker kanskje bare en del av trafikken

En profil med splitt-tunnel er det vanlige svaret, og det er ikke en feil. OpenVPN sender alt gjennom tunnelen bare når redirect-gateway er blant de pushede alternativene; uten den får klienten en håndfull spesifikke ruter, og standardruten din blir værende på den fysiske koblingen. På Windows vises den samme bryteren som «Bruk standardgateway på eksternt nettverk» i adapterens IPv4-egenskaper, og å fjerne den er et bevisst valg som overlever hver tilkobling på nytt.

Omfang per app er det andre laget. Androids VPN-innstilling per app avgjør hvilke apper som er inkludert, så VPN-nøkkelen i statuslinjen beviser ikke at nettleseren er inni den. En nettleserutvidelse som proxier sin egen trafikk skaper speilbildet: nettleseren viser exit-adressen mens en e-postklient eller et spill på samme maskin fortsatt viser din. Sammenlign den samme forespørselen i to apper. Hvis den ene endres og den andre ikke, ser du på omfang, ikke på en sviktende tunnel.

Én adressefamilie kan fortsatt gå direkte

De fleste VPN-profiler er skrevet for IPv4, og mange er det fortsatt. På et nettverk med dobbel stack tar tunnelen 10.8.0.x for IPv4 mens den fysiske koblingen beholder en global IPv6-adresse og en standardrute, så et nettsted med IPv6-støtte nås direkte og adressen det rapporterer er leverandørens. Det er en lekkasje med en fungerende IPv4-tunnel, og den er usynlig for en test som bare snakker IPv4.

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

Les grensesnittet i hvert svar. Hvis IPv6-oppslaget navngir Ethernet- eller Wi-Fi-enheten din mens IPv4-oppslaget navngir tunnelen, mangler policyen for den familien i stedet for å være ødelagt. Å slå av IPv6 på hele enheten får symptomet til å forsvinne og skjuler beslutningen; reparer heller profilens dekning eller deaktiver familien bare på den tilkoblingen, og noter hvilken av de to du valgte.

En annen vei kan vinne oppslaget

En konkurrerende proxy, en annen VPN-klient, en virtuell adapter fra en container eller et fjernskrivebordsverktøy, eller en ekstra rute for det nøyaktige prefikset du tester, kan alle få forrang. En spesifikk rute slår alltid en standardrute, så en gjenværende /24 for nettstedet du måler, som peker på LAN-gatewayen din, fortsetter å sende trafikken utenfor tunnelen uansett hvor sunn tunnelen er.

Lag en oversikt før du endrer noe, med skrivebeskyttede kommandoer:

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

Se etter mer enn én standardrute med en plausibel metrikk, og etter en spesifikk rute som dekker destinasjonen. I en nettleser, sjekk også om en proxyutvidelse eller systemets proxyinnstilling eier tilkoblingen; en utvidelse kan navngi sin egen upstream og la operativsystemets exit være urørt, noe som gir en annen adresse i nettleseren enn i en terminal på samme maskin.

Mål på nytt med en fersk forespørsel

Koble til på nytt, og gjenta deretter målingen fra samme app som du testet første gang, fordi en bufret side eller en gjenbrukt tilkobling rapporterer den gamle tilstanden. Følg med på klientens logg eller hendelsesvisning under tilkoblingen: en feil ved bruk av ruter etter autentisering er sterkere bevis enn noen indikator, og den navngir vanligvis ruten eller adapteren som feilet.

Hold to utfall fra hverandre. Hvis adressen endres men ett nettsted fortsatt avviser deg, fungerer tunnelen og nettstedet avviser en datasenteradresse; det er et annet problem med et annet svar. Hvis adressen aldri endres, gå gjennom de fire spørsmålene i rekkefølge: hvilken adresse testen skrev ut, hvilken familie det var, hvilken app som laget forespørselen, og hvilken rute den forespørselen fulgte. Microsofts dokumentasjon om VPN-rutingsbeslutninger forklarer hvordan en Windows-klient velger mellom tunnelen og den fysiske adapteren når begge har en rute.