Rozdělený tunel ve Windows: políčko brány a chybějící prefix

Tunel hlásí, že je připojen, a wiki se stále načítá. Pak se stahování zasekne a sdílená složka na poličce přestane odpovídat. Tunel udělal svou práci a profil si prostě nárokoval každé cílové umístění.

Windows považuje připojení VPN za rozhodnutí o trase. Dokud se toto rozhodnutí nezúží, stroj se chová, jako by se přestěhoval do kanceláře.

Proč fungující tunel působí jako výpadek

Profil, kterému je povoleno použít vzdálenou bránu, nainstaluje výchozí trasu přes tunel. Každé cílové umístění, které není na místním spoji, pak odchází přes kancelářský firewall. Místní sdílené složky přestanou odpovídat, protože jejich provoz teď cestuje na jiný kontinent a zpět. Nic ve stavu klienta to neodráží.

Příznaky jsou záměrně matoucí. Překlad jmen může stále fungovat, zatímco sdílená složka vyprší, nebo naopak. Uživatel hlásí, že VPN je rozbitá, klient hlásí, že je v pořádku, a obě tvrzení jsou přesná.

Zaškrtávací pole ukryté v dialogu IPv4

Nastavení leží několik dialogů hluboko. Otevřete ncpa.cpl, klikněte pravým tlačítkem na připojení, pak na vlastnosti IPv4, pak na Upřesnit, a zrušte možnost, která připojení dovoluje stát se vzdálenou výchozí bránou. To jedno pole rozhoduje o tom, zda je profil plný tunel. Všechno ostatní v profilu stále platí.

Porovnejte route print -4 před opětovným připojením a po něm. Záznam 0.0.0.0, který dřív ukazoval na tunel, by měl zmizet a podnikové prefixy by měly zůstat.

route print -4 | findstr /c:"0.0.0.0"
Get-VpnConnection -Name 'Work VPN' | Select-Object Name, SplitTunneling, Routes

Změna metriky rozhraní to nenahradí. Metrika rozhoduje jen mezi dvěma konkurenčními výchozími trasami a klient, který při každém připojení znovu instaluje svou výchozí trasu, tenhle souboj vyhraje bez ohledu na nastavené číslo.

Prefix, který nikdo neuvedl

Rozdělený tunel zpřístupňuje přesně ty prefixy zapsané v profilu. Kancelářská podsíť přidaná po napsání profilu zůstává nedostupná, i když je tunel naprosto zdravý. Hlášení pak dorazí jako jeden rozbitý server, a ne jako rozbitá VPN.

Trasa přidaná ručně překlene mezeru, dokud se adresa brány nezmění. Zapsat prefix do připojení je pevnější, protože prefix pak následuje připojení místo odhadnuté adresy.

route -p add 172.20.8.0 mask 255.255.255.0 10.8.0.1
Add-VpnConnectionRoute -ConnectionName 'Work VPN' -DestinationPrefix 172.20.8.0/24
Get-VpnConnection -Name 'Work VPN' | Select-Object -ExpandProperty Routes

Čtěte uložený seznam a živou tabulku společně. Uložený prefix může existovat, zatímco tabulka ho nikdy nedostane, což se stává, když agent pro správu filtruje trasy po navázání připojení. Opak se také děje, když trasa v registru ukazuje na adaptér, který je vypnutý. Ani jeden pohled sám neřekne celý příběh.

Prokázání výsledku po restartu

Trasujte oběma směry a rozlišujte podle jména. Veřejné trasování by mělo odejít přes poskytovatele, vnitřní trasování by mělo vstoupit do tunelu a vnitřní host by měl odpovídat jménem, ne jen adresou.

tracert -4 www.example.com
tracert -4 wiki.corp.example
ping -4 fileserver.corp.example
ping -4 172.20.8.20

Zopakujte to po odpojení, opětovném připojení a jednom restartu. Prefix, který přežije ruční opětovné připojení a po restartu zmizí, nebyl v profilu nikdy uložen.

Nechte v testu i tiskárnu a NAS, protože rozdělený tunel, který odřízne zařízení vedle notebooku, vyřešil jeden problém tím, že vytvořil menší a otravnější. Reference Microsoftu k Add-VpnConnectionRoute je místo, kde porovnáte pravopis parametrů s verzí svého modulu.