VPN blokuje místní LAN ve Windows: trasa, nebo zásada klienta?

Tiskárna, NAS nebo vývojový stroj na vašem vlastním stole přestanou odpovídat v okamžiku, kdy se připojí pracovní VPN. Někdy to příkaz trasy spraví během sekund; jindy je stejná trasa správná a pakety přesto mizí, což znamená, že se díváte na jiný problém s podobným příznakem. Rozhodnutí se redukuje na tři otázky a právě špatné pořadí je důvod, proč lidé tráví celý večer mazáním a znovupřidáváním tras.

Tři otázky před jakýmkoli příkazem

Za prvé: existuje záznam pro místní prefix a ukazuje na fyzický adaptér? Za druhé: dostává klient při připojení od brány povolení, nebo zamítnutí místní sítě? Za třetí: potřebujete jen odchozí přístup do LAN, nebo musí něco na internetu také dosáhnout služby běžící na vašem stroji?

První otázka odděluje chybu směrování od chyby filtrování. Druhá říká, zda smí oprava trasy vůbec fungovat. Třetí mění opravu: trasa spraví odchozí provoz, zatímco nedostupná příchozí služba je obvykle problém navázání posluchače a zpětné cesty, který trasa ještě zhorší.

Otázka první: trasa, filtr, nebo jméno

Přečtěte si tabulku, než do ní něco přidáte. Na indexu rozhraní záleží, protože každý příkaz trasy níže je na něj ukotven:

route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric

Přímo připojená podsíť obvykle zachovává trasu na spoji i při aktivním tunelu, takže záznam může existovat a provoz přesto selže. Taková kombinace je podpis filtru, který běží po směrování, a to je případ, kdy druhá, konkrétnější trasa nezmění vůbec nic.

Testujte zvlášť podle adresy a podle jména. Pokud ping 192.168.1.50 odpovídá a net view 192.168.1.50 ne, směrovací tabulka nikdy nebyla problémem: tunel změnil resolver a místní jméno se už nepřekládá. Přidávat kvůli tomu trasu je zbytečná práce.

Otázka druhá: povoluje brána přístup k místní LAN?

Komerční klient neinstaluje jen trasy. Při připojení dostává zásadu a ta může obsahovat výslovné povolení místní sítě. V nasazeních Cisco IPsec nese skupinová zásada nastavení split-tunneling a samostatný příznak přístupu k místní LAN; zaškrtávací políčko v klientu je žádost, kterou brána může odmítnout. V AnyConnect profil řídí seznamy zahrnutí a vyloučení split a stejné povolení. Ve Windows RRAS jsou ekvivalenty volba výchozí brány v profilu plus statické trasy, které server přiděluje.

Když je příznak vypnutý, dokumentované chování je, že klient blokuje provoz do přímo připojené podsítě, i když existuje platná, konkrétnější trasa. Proto také trasy, které klient nevlastní, mohou zmizet sekundy poté, co je přidáte: klient znovu staví stav, který mu byl nařízen, nebojuje proti vám.

Klientský protokol zaznamenává rozhodnutí při připojení a jeho čtení je rychlejší než jakýkoli experiment na stroji. Pokud protokol říká, že místní přístup je blokován, zastavte se: žádná oprava z příkazové řádky to nepřežije a zbývají jen změna zásady, dosažení prostředku tunelem, nebo uzavření klienta do virtuálního stroje a ponechání hostitele v místní síti.

Otázka třetí: který směr potřebujete?

Odchozí provoz k blízkému zařízení je otázka směrování. Nasměrujte prefix LAN na místní bránu s metrikou dost nízkou, aby porazila výchozí trasu tunelu:

route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -p

Druhá forma připíchne jediné zařízení, což je to, co chcete, když je celým požadavkem jedna adresa. Ekvivalent netsh zaznamenává stejné rozhodnutí podle jména rozhraní, ne podle indexu:

netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistent

Příkazy trasy selhávají s Parametr je nesprávný, když se adresa a maska neshodují, například adresa hostitele s maskou /24. Pro trasu podsítě použijte adresu sítě a pro jednoho hostitele masku hostitele.

Příchozí je jiné. Server VNC nebo SSH na stejném stroji se stane nedostupným, když odpovědi na příchozí spojení odejdou přes bránu VPN a už se nevrátí. Než se dotknete tras, zjistěte, na čem služba naslouchá:

netstat -ano | findstr :5900

Posluchač navázaný na jednu konkrétní adresu nebude odpovídat na druhém rozhraní. Navázat ho na všechna rozhraní je vědomé rozhodnutí, učiněné spolu s pravidlem firewallu omezeným na síť, které důvěřujete. Teprve potom oprava trasy obnoví zpětnou cestu.

Použijte nejmenší změnu, která sedí

Další častý krok je odškrtnout „Používat výchozí bránu ve vzdálené síti“ v rozšířených vlastnostech IPv4. Drží internetový provoz lokálně, ale dělá dvě věci najednou: VPN přestane být výchozí cestou a klient přestane dostávat trasy pro vzdálenou síť, včetně multicastu. Odškrtněte to a vzdálená LAN zmizí, pokud server neprotlačí konkrétní vzdálené prefixy, které každý klient potřebuje.

Tato asymetrie rozhoduje o pořadí práce. Pokud má vzdálená strana zůstat plně dostupná, protlačte vzdálené podsítě ze serveru a místní výchozí nechte být. Pokud server změnit nemůžete, přidejte trvalou trasu ke vzdálenému prefixu přes adresu, kterou tunel přidělil, a pomocí route print ověřte, že prefix ukazuje na rozhraní VPN, zatímco výchozí stále ukazuje na fyzickou bránu.

Pak potvrďte, že oprava přežije opětovné připojení, protože netrvalé trasy umírají s adaptérem a skript, který se spouští po každém připojení, je pro ně poctivé místo. Otestujte jedno místní zařízení a jeden vzdálený prostředek ve stejné relaci, odpojte se, připojte se znovu a otestujte znovu. Pokud místní zařízení stále selhává, zatímco trasa vypadá správně, vraťte se k druhé otázce: klient filtruje a odpovědí je změna zásady, ne druhá konkurenční trasa.