Lokálna sieť nedostupná pri pripojenom VPN? Štyri kontroly

Tunel sa zdvihne, intranet sa objaví a tlačiareň prestane odpovedať. V sieti LAN sa nič nepokazilo; klient zmenil cestu, ktorú používa pre adresy, ktoré už nepovažuje za lokálne. Prejdite štyri kontroly nižšie po poradí a zastavte sa, keď jedna ukáže konkrétnu nezhodu, pretože ten istý príznak má štyri bežné príčiny a iba jedna z nich sa odstráni úpravou VPN.

Najprv sa pozrite na smerovaciu tabuľku, ktorú klient nainštaloval

Otvorte smerovaciu tabuľku klienta, kým je VPN pripojené. V Linuxe použite ip route, vo Windowse route print alebo Get-NetRoute a v macOS netstat -rn. Hľadáte predvolenú cestu tunelom a to, čo sa stalo s fyzickou predvolenou cestou.

Klient s plným tunelom často pridá dve polpredvolené cesty, 0.0.0.0/1 a 128.0.0.0/1, namiesto nahradenia 0.0.0.0/0. Pôvodná predvolená cesta zostane viditeľná, ale prehrá každé vyhľadanie, a preto môže tabuľka vyzerať nedotknutá, kým sa všetka prevádzka mimo podsiete presúva. Ak klient VPN ponúka možnosť rozdeleného tunela a politika to dovoľuje, je to najčistejšia oprava.

Ak musí tunel zostať predvolený, pripnite namiesto toho lokálnu podsieť. V Linuxe cesta uvádza fyzické rozhranie a bránu; vo Windowse pridajte -p, aby bola trvalá, a číslo rozhrania prečítajte z route print, namiesto toho, aby ste ho hádali:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

Pripnutá cesta vydrží len dovtedy, kým sa adresa, ktorú uvádza, nemení. Notebook, ktorý pri každom pripojení dostane nové číslo Wi-Fi adaptéra, pravidlo znova poruší, preto skontrolujte adresu rozhrania, kým usúdite, že oprava zlyhala.

Po druhé, potvrďte, že adresa bola lokálna od začiatku

Ak cieľ leží v pripojenej podsieti, predvolená cesta tunela sa nikdy neuplatní a VPN nie je príčinou. Tlačiareň na 192.168.1.40 na klientovi s 192.168.1.0/24 používa pripojenú cestu; ak tá adresa zlyhá, pozrite sa na zariadenie, prepínač alebo firewall na klientovi, nie na VPN.

Prípad, ktorý ľudí miat, je verejná adresa pre lokálny server. Zvnútra LAN dosiahnuť WAN adresu routera a vrátiť sa vyžaduje hairpin NAT a mnohé routery ho pre presmerovanie portov jednoducho neimplementujú. Otestujte privátnu adresu vedľa verejnej. Ak privátna funguje a verejná nie, VPN iba odhalilo obmedzenie NAT, ktoré existovalo už predtým.

Názov hostiteľa to zhoršuje. Ak sa lokálny názov teraz prekladá na verejnú adresu, klient bude ďalej skúšať cestu, ktorá sa nemôže vrátiť. Na test použite privátnu adresu a potom opravte názov, namiesto pridania ďalšieho presmerovania portov.

Po tretie, pozrite sa, kto teraz odpovedá na názvy

Podnikový resolver pozná intranet a zvyčajne nevie nič o názve hostiteľa NAS, názve Bonjour tlačiarne alebo lokálnom aliase routera. Keď VPN pretlačí svoje DNS servery, tieto názvy sa prestanú prekladať, hoci ich adresy sú stále dosiahnuteľné. Opýtajte sa na názov priamo a porovnajte odpoveď s adresou, o ktorej viete, že ju zariadenie má.

V Linuxe resolvectl query nas.local ukáže, ktorý resolver odpovedal. Vo Windowse nslookup nas.local uvedie server a ipconfig /all ukáže poradie resolverov. Ak lokálnu príponu teraz spravuje podnikový resolver, presmerujte tú príponu späť na lokálny resolver alebo použite pre zariadenie IP adresu.

Zisťovanie je samostatná vrstva. mDNS a vysielanie neprechádzajú smerovaným tunelom, takže zariadenie môže byť dostupné podľa adresy, kým jeho názov zostáva neviditeľný. Vyrieši to reflektor alebo lokálny DNS záznam; cesta nie.

Po štvrté, skontrolujte, či aj druhý stroj nie je vo VPN

Keď stroj, ku ktorému sa chcete dostať, tiež spúšťa klienta VPN, vaša relácia môže doraziť, kým odpoveď odchádza druhým tunelom. Vznikne spojenie, ktoré sa nadviaže a potom zasekne, alebo pokus o RDP a SSH, ktorý na vašej strane vyprší bez chyby. Skontrolujte smerovaciu tabuľku druhého hostiteľa a jeho predvolenú cestu, kým obviníte svojho klienta.

Skontrolujte aj adresu, na ktorej služba počúva. Poslucháč viazaný iba na adresu tunela prijíma spojenia z VPN a odmieta tie z LAN, aj keď je smerovanie dokonalé. Je to konfigurácia služby, nie sieťová cesta, a je bežná na rozhraniach správy, ktoré boli zamknuté na adresu VPN.

Udržujte cestu správy, ktorá nezávisí od tunela: statická cesta s vašou zdrojovou sieťou, iné rozhranie pripojené do LAN alebo konzola, ktorá tunel úplne obchádza. Navrhnúť tú cestu po páde relácie je oveľa ťažšie než pridať ju pred ďalším pripojením.

Použite opravu, ktorá zodpovedá zlyhanej kontrole

Ak smerovacia tabuľka ukázala polpredvolené prevzatie, zvoľte rozdelený tunel, keď to politika dovoľuje, a pripnutú lokálnu cestu, keď nie. Ak sa adresa ukázala ako verejná, prepnite test a názov na privátnu adresu. Ak resolver zmenil ruky, obmedzte sa na lokálnu príponu alebo použite adresu. Ak je druhý hostiteľ v tuneli, opravte jeho spätnú cestu alebo viazanie poslucháča.

Zmeňte jednu vec a potom zopakujte tú istú kontrolu. Cesta pridaná pre nesprávnu podsieť, prípona resolvera s preklepom a pripnutá cesta na rozhraní, ktoré dostáva nové čísla, vyzerajú všetky ako pôvodná porucha. Práve zopakovanie oddeľuje opravu od náhody.

Zapíšte cestu, adresu a resolver, ktoré fungovali, kým bolo VPN pripojené. Ďalšie opätovné pripojenie zmení aspoň jedno z nich a poznámka premení ďalší výpadok na krátke porovnanie namiesto nového vyšetrovania.