VPN je připojená, ale IP adresa se nezměnila: proč

Připojíte se, klient hlásí připojeno a test adresy pořád ukazuje stejné číslo jako předtím. S indikátorem není nic špatně; něco mezi profilem a aplikací nechalo ten požadavek mimo tunel. Rozhodněte, na kterou ze tří věcí se díváte, než sáhnete na jakékoli nastavení: test, který nikdy neměřil veřejnou adresu, tunel, který pokrývá jen část provozu, nebo druhá cesta, která vyhraje rozhodnutí o směrování. Každá má jednu kontrolu, která zabere méně než minutu.

Ověřte, co test skutečně změřil

Adresa v dialogu Wi-Fi nebo Ethernet je adresa rozhraní na vašem vlastním segmentu, ne adresa, kterou vidí web, takže může zůstat stejná, i když tunel funguje dokonale. Poloha je zas samostatný signál: uložený region účtu nebo povolené načtení geolokace se při změně výstupu neposune, a ani přihlášení, které vás už zná.

Použijte ozvěnu veřejné adresy a ptejte se každé rodiny zvlášť, protože výsledek testu s duálním stackem skrývá ten zajímavý případ:

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

Spusťte oba před připojením i po něm. Pokud se odpověď IPv4 změní na výstupní adresu a odpověď IPv6 ne, nemáte rozbitý tunel; máte jednu rodinu, která jede mimo něj. Pokud obě odpovědi zůstanou stejné, požadavek se do tunelu vůbec nedostal a zbytek tady platí.

Profil může pokrývat jen část provozu

Profil s rozděleným tunelem je obvyklá odpověď a není to závada. OpenVPN posílá všechno tunelem jen tehdy, když je redirect-gateway mezi předanými volbami; bez něj klient dostane hrst konkrétních tras a vaše výchozí trasa zůstane na fyzickém spoji. Ve Windows se stejný přepínač objevuje jako „Použít výchozí bránu ve vzdálené síti“ ve vlastnostech IPv4 adaptéru a jeho zrušení je vědomá volba, která přežije každé opětovné připojení.

Rozsah podle aplikací je druhá vrstva. Nastavení VPN pro jednotlivé aplikace v Androidu určuje, které aplikace jsou zahrnuté, takže klíč VPN ve stavovém řádku nedokazuje, že prohlížeč je uvnitř. Rozšíření prohlížeče, které proxuje vlastní provoz, vytváří zrcadlový obraz: prohlížeč ukazuje výstupní adresu, zatímco poštovní klient nebo hra na stejném stroji pořád ukazuje vaši. Porovnejte stejný požadavek ve dvou aplikacích. Pokud se jedna změní a druhá ne, díváte se na rozsah, ne na selhávající tunel.

Jedna rodina adres může pořád jít přímo

Většina VPN profilů je psaná pro IPv4 a mnohé takové pořád jsou. V síti s duálním stackem tunel bere 10.8.0.x pro IPv4, zatímco fyzický spoj si drží globální adresu IPv6 a výchozí trasu, takže web s podporou IPv6 je dosažen přímo a adresa, kterou hlásí, je adresa vašeho poskytovatele. To je únik při funkčním IPv4 tunelu a je neviditelný pro test, který mluví jen IPv4.

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

Přečtěte rozhraní v každé odpovědi. Pokud dotaz IPv6 jmenuje vaše zařízení Ethernet nebo Wi-Fi, zatímco dotaz IPv4 jmenuje tunel, politika pro tu rodinu chybí, ne že by byla rozbitá. Vypnutí IPv6 pro celé zařízení odstraní příznak a skryje rozhodnutí; raději opravte pokrytí profilu nebo zakažte rodinu jen na tom jednom připojení a poznamenejte si, kterou ze dvou možností jste zvolili.

Druhá cesta může vyhrát vyhledání

Konkurenční proxy, druhý VPN klient, virtuální adaptér z kontejneru nebo nástroje pro vzdálenou plochu, nebo extra trasa pro přesný prefix, který testujete, všechny mohou dostat přednost. Konkrétní trasa vždy porazí výchozí trasu, takže zbylá /24 pro web, který měříte, ukazující na vaši bránu LAN, posílá ten provoz mimo tunel, ať je tunel jakkoli zdravý.

Než něco změníte, udělejte soupis pomocí příkazů jen pro čtení:

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

Hledejte víc než jednu výchozí trasu s věrohodnou metrikou a konkrétní trasu pokrývající cíl. V prohlížeči také zkontrolujte, zda spojení vlastní rozšíření proxy nebo systémové nastavení proxy; rozšíření může jmenovat svůj vlastní upstream a nechat výstup operačního systému nedotčený, což dává jinou adresu v prohlížeči než v terminálu na stejném stroji.

Změřte znovu s novým požadavkem

Připojte se znovu a pak zopakujte měření ze stejné aplikace, kterou jste testovali poprvé, protože uložená stránka nebo znovupoužitá spojení hlásí starý stav. Sledujte log klienta nebo zobrazení událostí během připojování: chyba při aplikaci tras po autentizaci je silnější důkaz než jakýkoli indikátor a obvykle jmenuje trasu nebo adaptér, který selhal.

Držte dva výsledky oddělené. Pokud se adresa změní, ale jeden web vás pořád odmítá, tunel funguje a web odmítá adresu datového centra; to je jiný problém s jinou odpovědí. Pokud se adresa nikdy nezmění, projděte čtyři otázky popořadě: kterou adresu test vypsal, která rodina to byla, která aplikace požadavek odeslala a kterou trasu ten požadavek sledoval. Dokumentace Microsoftu k rozhodnutím o směrování VPN vysvětluje, jak klient Windows volí mezi tunelem a fyzickým adaptérem, když oba mají trasu.