A VPN csatlakozott, de az IP-cím nem változott: miért

Csatlakozik, a kliens azt mondja, csatlakozva, és a címtér tesztje még mindig ugyanazt a számot mutatja, ami korábban volt. A jelzővel nincs baj; valami a profil és az alkalmazás között a kérést az alagúton kívül tartotta. Döntse el, a három dolog közül melyiket látja, mielőtt bármelyik beállításhoz nyúlna: egy teszt, amely soha nem mérte a nyilvános címet, egy alagút, amely csak a forgalom egy részét fedi le, vagy egy második útvonal, amely megnyeri az útválasztási döntést. Mindegyikhez tartozik egy ellenőrzés, amely kevesebb mint egy percet vesz igénybe.

Erősítse meg, mit is mért valójában a teszt

A Wi-Fi vagy Ethernet párbeszédablakban látható cím a saját szegmensén lévő interfész címe, nem az a cím, amelyet egy webhely lát, ezért változatlan maradhat, miközben az alagút tökéletesen működik. A helyzet ismét külön jel: a mentett fiókrégió vagy az engedélyezett helymeghatározás-olvasás nem mozdul, amikor az exitet váltja, és egy olyan bejelentkezés sem, amely már felismeri Önt.

Használjon nyilvános cím visszhangot, és kérdezze minden családot külön, mert a kettős stack teszteredménye elrejti az érdekes esetet:

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

Futtassa mindkettőt csatlakozás előtt és után. Ha az IPv4 válasz átvált az exit címére, az IPv6 válasz pedig nem, nincs törött alagútja; egy család azon kívül utazik. Ha mindkét válasz ugyanaz marad, a kérés soha nem érte el az alagutat, és az itt leírtak többi része érvényes.

A profil csak a forgalom egy részét fedheti le

A megosztott alagút profil a szokásos válasz, és nem hiba. Az OpenVPN csak akkor küld mindent az alagúton, ha redirect-gateway szerepel a továbbított opciók között; nélküle a kliens néhány konkrét útvonalat kap, és az alapértelmezett útvonala a fizikai kapcsolaton marad. Windows alatt ugyanez a kapcsoló „Alapértelmezett átjáró használata távoli hálózaton” néven jelenik meg az adapter IPv4-tulajdonságaiban, és a kikapcsolása tudatos döntés, amely minden újracsatlakozást túlél.

Az alkalmazásonkénti hatókör a második réteg. Az Android alkalmazásonkénti VPN-beállítása dönti el, mely alkalmazások vannak benne, így az állapotsor VPN-kulcsa nem bizonyítja, hogy a böngésző benne van. A saját forgalmát proxyzó böngésző-kiterjesztés hozza létre a tükörképet: a böngésző az exit címet mutatja, miközben egy levélkliens vagy játék ugyanazon a gépen még az Önét mutatja. Hasonlítsa össze ugyanazt a kérést két alkalmazásban. Ha az egyik változik, a másik nem, hatókört lát, nem egy meghibásodó alagutat.

Egy címcsalád továbbra is mehet közvetlenül

A legtöbb VPN-profil IPv4-re íródott, és sok még mindig az. Kettős stack hálózaton az alagút 10.8.0.x-et vesz fel IPv4-hez, miközben a fizikai kapcsolat globális IPv6-címet és alapértelmezett útvonalat tart, így az IPv6-ot támogató webhely közvetlenül elérhető, és az általa jelentett cím a szolgáltatója címe. Ez szivárgás működő IPv4-alagúttal, és láthatatlan egy olyan teszt számára, amely csak IPv4-et beszél.

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

Olvassa el az interfészt minden válaszban. Ha az IPv6-keresés az Ethernet- vagy Wi-Fi-eszközét nevezi meg, míg az IPv4-keresés az alagutat, akkor annak a családnak a szabályzata hiányzik, nem pedig törött. Az IPv6 eszközszintű kikapcsolása eltünteti a tünetet és elrejti a döntést; inkább javítsa a profil lefedettségét, vagy tiltsa le a családot csak azon az egy kapcsolaton, és jegyezze fel, melyiket választotta.

Egy második útvonal megnyerheti a keresést

Egy versengő proxy, egy második VPN-kliens, egy konténer vagy távoli asztali eszköz virtuális adaptere, vagy egy extra útvonal a pontosan tesztelt előtaghoz — mindannyian elsőbbséget kaphatnak. Egy konkrét útvonal mindig legyőzi az alapértelmezett útvonalat, ezért a mért webhelyhez tartozó maradék /24, amely a LAN-átjárójára mutat, továbbra is az alagúton kívül küldi ezt a forgalmat, bármilyen egészséges is az alagút.

Készítsen leltárt, mielőtt bármit megváltoztat, csak olvasható parancsokkal:

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

Keressen több alapértelmezett útvonalat hihető metrikával, és egy konkrét útvonalat, amely lefedi a célt. A böngészőben azt is ellenőrizze, hogy egy proxy-kiterjesztés vagy a rendszer proxybeállítása birtokolja-e a kapcsolatot; egy kiterjesztés megnevezheti a saját upstreamjét, és érintetlenül hagyhatja az operációs rendszer exitjét, ami más címet eredményez a böngészőben, mint egy terminálban ugyanazon a gépen.

Mérjen újra friss kéréssel

Csatlakozzon újra, majd ismételje meg a mérést ugyanabból az alkalmazásból, amellyel először tesztelt, mert a gyorsítótárazott oldal vagy az újrahasznált kapcsolat a régi állapotot jelenti. Figyelje a kliens naplóját vagy eseménynézetét a csatlakozás alatt: a hitelesítés utáni útvonal-alkalmazási hiba erősebb bizonyíték bármely jelzőnél, és általában megnevezi a meghibásodott útvonalat vagy adaptert.

Tartsa külön a két eredményt. Ha a cím változik, de egy webhely továbbra is elutasítja, az alagút működik, és a webhely egy adatközponti címet utasít el; ez más probléma, más válasszal. Ha a cím soha nem változik, járja végig a négy kérdést sorrendben: melyik címet nyomtatta a teszt, melyik család volt, melyik alkalmazás indította a kérést, és melyik útvonalat követte a kérés. A Microsoft dokumentációja a VPN-útválasztási döntésekről elmagyarázza, hogyan választ a Windows-kliens az alagút és a fizikai adapter között, ha mindkettőnek van útvonala.