VPN er tilkopla, men IP-adressa er ikkje endra: kvifor

Du koplar til, klienten seier tilkopla, og adressetesten viser framleis det same talet du hadde før. Det er ingenting gale med indikatoren; noko mellom profilen og appen heldt den førespurnaden utanfor tunnelen. Avgjer kva av tre ting du ser på før du rører nokon konfigurasjon: ein test som aldri målte den offentlege adressa, ein tunnel som berre dekkjer ein del av trafikken, eller ein annan veg som vinn rutingsavgjerda. Kvar har éin sjekk som tek under eitt minutt.

Stadfest kva testen faktisk målte

Adressa i Wi-Fi- eller Ethernet-dialogen er grensesnittadressa på ditt eige segment, ikkje adressa eit nettstad ser, så ho kan halde seg lik medan tunnelen fungerer perfekt. Stad er igjen eit eige signal: ein lagra kontoregion eller ei tillaten geolokasjonslesing flyttar seg ikkje når du byter exit, og det gjer heller ikkje ei innlogging som allereie kjenner deg att.

Bruk eit ekko av den offentlege adressa og spør kvar familie separat, fordi eit testresultat med dobbel stack skjuler det interessante tilfellet:

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

Køyr begge før og etter tilkopling. Viss IPv4-svaret endrar seg til exit-adressa og IPv6-svaret ikkje, har du ikkje ein øydelagd tunnel; éin familie reiser utanfor han. Viss begge svara blir dei same, nådde førespurnaden aldri tunnelen og resten her gjeld.

Profilen dekkjer kanskje berre ein del av trafikken

Ein profil med splitt-tunnel er det vanlege svaret, og det er ikkje ein feil. OpenVPN sender alt gjennom tunnelen berre når redirect-gateway er blant dei pusha vala; utan han får klienten ein handfull spesifikke ruter, og standardruta di blir verande på den fysiske koplinga. På Windows viser den same brytaren seg som «Bruk standardgateway på eksternt nettverk» i IPv4-eigenskapane til adapteren, og å fjerne han er eit medvite val som overlever kvar tilkopling på nytt.

Omfang per app er det andre laget. Android si VPN-innstilling per app avgjer kva apper som er med, så VPN-nøkkelen i statuslinja beviser ikkje at nettlesaren er inni henne. Ei nettlesarutviding som proxar sin eigen trafikk skaper spegelbiletet: nettlesaren viser exit-adressa medan ein e-postklient eller eit spel på same maskin framleis viser di. Samanlikn den same førespurnaden i to apper. Viss den eine endrar seg og den andre ikkje, ser du på omfang, ikkje på ein sviktande tunnel.

Éin adressefamilie kan framleis gå direkte

Dei fleste VPN-profilane er skrivne for IPv4, og mange er det framleis. På eit nettverk med dobbel stack tek tunnelen 10.8.0.x for IPv4 medan den fysiske koplinga held på ei global IPv6-adresse og ei standardrute, så ein nettstad med IPv6-støtte blir nådd direkte og adressa han rapporterer er leverandøren si. Det er ein lekkasje med ein fungerande IPv4-tunnel, og han er usynleg for ein test som berre snakkar IPv4.

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

Les grensesnittet i kvart svar. Viss IPv6-oppslaget nemner Ethernet- eller Wi-Fi-eininga di medan IPv4-oppslaget nemner tunnelen, manglar policyen for den familien i staden for å vere øydelagd. Å slå av IPv6 på heile eininga får symptomet til å forsvinne og skjuler avgjerda; reparer heller dekninga til profilen eller deaktiver familien berre på den tilkoplinga, og noter kva av dei to du valde.

Ein annan veg kan vinne oppslaget

Ein konkurrerande proxy, ein annan VPN-klient, ein virtuell adapter frå ein container eller eit fjernskrivebordsverktøy, eller ei ekstra rute for det nøyaktige prefikset du testar, kan alle få forrang. Ei spesifikk rute slår alltid ei standardrute, så ein attverande /24 for nettstaden du måler, som peikar på LAN-gatewayen din, held fram med å sende trafikken utanfor tunnelen uansett kor sunn tunnelen er.

Lag ei oversikt før du endrar noko, med skriveverna kommandoar:

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

Sjå etter meir enn éi standardrute med ein truverdig metrikk, og etter ei spesifikk rute som dekkjer destinasjonen. I ein nettlesar, sjekk også om ei proxyutviding eller systemproxyinnstillinga eig tilkoplinga; ei utviding kan namngi sin eigen upstream og la utgangen til operativsystemet vere urørt, noko som gir ei anna adresse i nettlesaren enn i ein terminal på same maskin.

Mål på nytt med ein fersk førespurnad

Kopla til på nytt, og gjer deretter målinga om att frå same app som du testa første gong, fordi ei bufra side eller ei gjenbrukt tilkopling rapporterer den gamle tilstanden. Følg med på loggen eller hendingsvisinga til klienten under tilkoplinga: ein feil ved bruk av ruter etter autentisering er sterkare bevis enn nokon indikator, og han nemner vanlegvis ruta eller adapteren som feila.

Hald to utfall frå kvarandre. Viss adressa endrar seg men ein nettstad framleis avviser deg, fungerer tunnelen og nettstaden avviser ei datasenteradresse; det er eit anna problem med eit anna svar. Viss adressa aldri endrar seg, gå gjennom dei fire spørsmåla i rekkjefølgje: kva adresse testen skreiv ut, kva familie det var, kva app som laga førespurnaden, og kva rute den førespurnaden følgde. Microsoft-dokumentasjonen om VPN-rutingsavgjerder forklarer korleis ein Windows-klient vel mellom tunnelen og den fysiske adapteren når begge har ei rute.