VPN blokuje miestnu LAN vo Windows: trasa alebo politika klienta?

Tlačiareň, NAS alebo vývojový stroj na vlastnom stole prestanú odpovedať v okamihu, keď sa pripojí pracovná VPN. Niekedy to jedna trasa príkazu opraví za sekundy; inokedy je tá istá trasa správna a pakety napriek tomu miznú, čo znamená, že sa pozeráte na iný problém s podobným príznakom. Rozhodnutie sa redukuje na tri otázky a práve ich nesprávne poradie je dôvod, prečo ľudia trávia celý večer mazaním a opätovným pridávaním trás.

Tri otázky pred akýmkoľvek príkazom

Po prvé: existuje záznam pre miestny prefix a ukazuje na fyzický adaptér? Po druhé: dostáva klient pri pripojení povolenie alebo zamietnutie miestnej siete od brány? Po tretie: potrebujete iba odchádzajúci prístup do LAN, alebo musí niečo na internete tiež dosiahnuť službu, ktorá beží na vašom stroji?

Prvá otázka oddeľuje chybu smerovania od chyby filtrovania. Druhá hovorí, či smie oprava trasy vôbec fungovať. Tretia mení opravu: trasa opravuje odchádzajúcu prevádzku, zatiaľ čo nedostupná prichádzajúca služba je zvyčajne problém naviazania poslucháča a spätnej cesty, ktorý trasa ešte zhorší.

Otázka prvá: trasa, filter alebo názov

Prečítajte si tabuľku, skôr než do nej niečo pridáte. Na indexe rozhrania záleží, pretože každý príkaz trasy nižšie je naň ukotvený:

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

Priamo pripojená podsieť zvyčajne zachováva trasu na spoji aj pri aktívnom tuneli, takže záznam môže existovať a prevádzka napriek tomu zlyhá. Taká kombinácia je podpis filtra, ktorý beží po smerovaní, a to je prípad, keď druhá, konkrétnejšia trasa nezmení vôbec nič.

Testujte oddelene podľa adresy a podľa názvu. Ak ping 192.168.1.50 odpovedá a net view 192.168.1.50 nie, tabuľka smerovania nikdy nebola problém: tunel zmenil resolver a miestny názov sa už neprekladá. Pridávať na to trasu je zbytočná práca.

Otázka druhá: povoľuje brána prístup k miestnej LAN?

Komerčný klient inštaluje viac než trasy. Pri pripojení dostáva politiku a tá politika môže obsahovať výslovné povolenie miestnej siete. V nasadeniach Cisco IPsec skupinová politika nesie nastavenie split-tunneling a samostatnú vlajku prístupu k miestnej LAN; zaškrtávacie políčko v klientovi je žiadosť, ktorú brána môže odmietnuť. V AnyConnect profil riadi zoznamy zahrnutia a vylúčenia split a to isté povolenie. Vo Windows RRAS sú ekvivalentmi voľba predvolenej brány v profile plus statické trasy, ktoré server pridelí.

Keď je vlajka vypnutá, dokumentované správanie je, že klient blokuje prevádzku do priamo pripojenej podsietsi, hoci existuje platná, konkrétnejšia trasa. Preto aj trasy, ktoré klient nevlastní, môžu zmiznúť sekundy po pridaní: klient znovu stavia stav, ktorý mu bolo prikázané postaviť, nebojuje proti vám.

Klientsky protokol zaznamenáva rozhodnutie pri pripojení a čítať ho je rýchlejšie než akýkoľvek experiment na stroji. Ak protokol hovorí, že miestny prístup je zablokovaný, zastavte sa: žiadna oprava z príkazového riadka to neprežije a zostávajú len zmena politiky, dosiahnutie prostriedku tunelom alebo uzavretie klienta do virtuálneho stroja a ponechanie hostiteľa v miestnej sieti.

Otázka tretia: ktorý smer potrebujete?

Odchádzajúca prevádzka k blízkemu zariadeniu je otázka smerovania. Nasmerujte prefix LAN na miestnu bránu s metrikou dosť nízkou na to, aby porazila predvolenú trasu tunela:

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 pripína jediné zariadenie, čo je to, čo chcete, keď je celou požiadavkou jedna adresa. Ekvivalent netsh zaznamenáva rovnaké rozhodnutie podľa názvu rozhrania, nie podľa indexu:

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

Príkazy trasy zlyhajú s Parameter je nesprávny, keď sa adresa a maska nezhodujú, napríklad adresa hostiteľa s maskou /24. Pre trasu podsietsi použite adresu siete a pre jedného hostiteľa masku hostiteľa.

Prichádzajúca je iná. Server VNC alebo SSH na tom istom stroji sa stane nedostupným, keď odpovede na prichádzajúce spojenie odídu cez bránu VPN a už sa nikdy nevrátia. Predtým, než sa dotknete trás, skontrolujte, na čom služba načúva:

netstat -ano | findstr :5900

Poslucháč naviazaný na jednu konkrétnu adresu nebude odpovedať na druhom rozhraní. Naviazať ho na všetky rozhrania je vedomé rozhodnutie, prijaté spolu s pravidlom firewallu obmedzeným na sieť, ktorej dôverujete. Až potom oprava trasy obnoví spätnú cestu.

Použite najmenšiu vhodnú zmenu

Ďalším častým krokom je odškrtnúť „Používať predvolenú bránu vo vzdialenej sieti“ v rozšírených vlastnostiach IPv4. Drží internetovú prevádzku lokálne, ale robí dve veci naraz: VPN prestáva byť predvolenou cestou a klient prestáva dostávať trasy pre vzdialenú sieť, vrátane multicastu. Odškrtnite to a vzdialená LAN zmizne, ak server neprotlačí konkrétne vzdialené prefixy, ktoré každý klient potrebuje.

Táto asymetria rozhoduje o poradí práce. Ak má vzdialená strana zostať plne dostupná, protlačte vzdialené podsietsi zo servera a miestnu predvolenú nechajte tak. Ak server nemôžete zmeniť, pridajte trvalú trasu k vzdialenému prefixu cez adresu, ktorú tunel pridelil, a pomocou route print overte, že prefix ukazuje na rozhranie VPN, zatiaľ čo predvolená stále ukazuje na fyzickú bránu.

Potom potvrďte, že oprava prežije opätovné pripojenie, pretože netrvalé trasy umierajú s adaptérom a skript, ktorý sa spúšťa po každom pripojení, je pre ne čestné miesto. Otestujte jedno miestne zariadenie a jeden vzdialený prostriedok v tej istej relácii, odpojte sa, pripojte sa znova a otestujte znova. Ak miestne zariadenie stále zlyháva, kým trasa vyzerá správne, vráťte sa k druhej otázke: klient filtruje a odpoveďou je zmena politiky, nie druhá konkurenčná trasa.