Lokální síť nedostupná při připojeném VPN? Čtyři kontroly

Tunel se zvedne, intranet se objeví a tiskárna přestane odpovídat. V lokální síti nic neselhalo; klient změnil cestu, kterou používá pro adresy, jež už nepovažuje za lokální. Projděte čtyři kontroly níže popořadě a zastavte se u první, která ukáže konkrétní nesoulad, protože stejný symptom má čtyři časté příčiny a jen jedna z nich se řeší úpravou VPN.

Za prvé, podívejte se na směrovací tabulku, kterou klient nainstaloval

Otevřete směrovací tabulku klienta, dokud je VPN připojená. V Linuxu použijte ip route, ve Windows route print nebo Get-NetRoute a v macOS netstat -rn. Hledáte výchozí trasu tunelem a to, co se stalo s fyzickou výchozí trasou.

Klient plného tunelu často přidá dvě polovině-výchozí trasy, 0.0.0.0/1 a 128.0.0.0/1, místo aby nahradil 0.0.0.0/0. Původní výchozí trasa zůstává viditelná, ale ztrácí každé hledání, a proto tabulka může vypadat nedotčeně, zatímco veškerý provoz mimo podsíť se přesouvá. Pokud klient VPN nabízí rozdělený tunel a politika to dovoluje, je to nejčistší oprava.

Pokud musí tunel zůstat výchozí trasou, připněte raději lokální podsíť. V Linuxu trasa uvádí fyzické rozhraní a bránu; ve Windows přidejte -p, aby byla trvalá, a číslo rozhraní čtěte z route print, místo abyste 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

Připnutá trasa drží jen tak dlouho, dokud adresa, kterou uvádí, zůstává stejná. Notebook, který při každém připojení přečísluje svůj Wi-Fi adaptér, pravidlo znovu poruší, takže před rozhodnutím, že oprava selhala, zkontrolujte adresu rozhraní.

Za druhé, potvrďte, že adresa byla lokální už od začátku

Pokud cíl leží uvnitř připojené podsítě, výchozí trasa tunelu se nikdy neuplatní a VPN není příčinou. Tiskárna na 192.168.1.40 u klienta s 192.168.1.0/24 používá připojenou trasu; pokud tato adresa selže, dívejte se na zařízení, switch nebo firewall na klientovi, ne na VPN.

Případ, který lidi mate, je veřejná adresa pro lokální server. Zevnitř lokální sítě vyžaduje dosažení WAN adresy routeru a návrat zpět hairpin NAT a mnoho routerů ho pro přesměrování portů prostě neimplementuje. Otestujte privátní adresu vedle veřejné. Pokud privátní adresa funguje a veřejná ne, VPN jen odhalila omezení NAT, které tu bylo už dřív.

Název hostitele to zhoršuje. Pokud se lokální jméno nyní překládá na veřejnou adresu, klient bude dál zkoušet cestu, která se nemůže vrátit. Pro test použijte privátní adresu a potom opravte jméno, místo abyste přidávali další přesměrování portu.

Za třetí, podívejte se, kdo teď odpovídá na jména

Firemní resolver zná intranet a obvykle nic neví o jménu hostitele NAS, jménu tiskárny v Bonjour ani o lokálním aliasu routeru. Když VPN protlačí své DNS servery, tato jména přestanou fungovat, i když jsou jejich adresy stále dostupné. Zeptejte se na jméno přímo a porovnejte odpověď s adresou, o které víte, že ji zařízení má.

V Linuxu resolvectl query nas.local ukáže, který resolver odpověděl. Ve Windows nslookup nas.local pojmenuje server a ipconfig /all ukáže pořadí resolverů. Pokud lokální sufix nyní obsluhuje firemní resolver, buď sufix nasměrujte zpět na lokální resolver, nebo pro zařízení použijte IP adresu.

Zjišťování je samostatná vrstva. mDNS a broadcast nepřekročí směrovaný tunel, takže zařízení může být dostupné podle adresy, zatímco jeho jméno zůstává neviditelné. Reflector nebo lokální záznam DNS to vyřeší; trasa ne.

Za čtvrté, zkontrolujte, jestli je na VPN i druhý stroj

Když stroj, ke kterému se chcete dostat, také spouští klienta VPN, vaše relace může dorazit, zatímco jeho odpověď odchází druhým tunelem. To vytvoří spojení, které se naváže a pak uvízne, nebo pokus o RDP a SSH, který vyprší bez chyby na vaší straně. Zkontrolujte směrovací tabulku druhého hostitele a jeho výchozí cestu, než obviníte svého klienta.

Zkontrolujte také adresu, na které služba naslouchá. Posluchač vázaný jen na adresu tunelu přijímá spojení z VPN a odmítá je z lokální sítě, i když je směrování bezchybné. To je konfigurace služby, ne síťová cesta, a bývá to běžné u rozhraní pro správu, která byla uzamčena na adresu VPN.

Udržujte si cestu pro správu, která nezávisí na tunelu: statickou trasu pojmenovávající vaši zdrojovou síť, jiné rozhraní připojené k lokální síti nebo konzoli, která tunel úplně obejde. Navrhnout takovou cestu po pádu relace je mnohem těžší než ji přidat před dalším připojením.

Použijte opravu, která odpovídá kontrole, jež selhala

Pokud směrovací tabulka ukázala zachycení polovinou-výchozí trasy, zvolte rozdělený tunel, když to politika dovoluje, a připnutou lokální trasu, když ne. Pokud se adresa ukázala jako veřejná, přepněte test i jméno na privátní adresu. Pokud resolver změnil majitele, ohraničte lokální sufix nebo použijte adresu. Pokud je druhý hostitel v tunelu, opravte jeho návratovou cestu nebo navázání posluchače.

Změňte jednu věc a potom zopakujte stejnou kontrolu. Trasa přidaná pro špatnou podsíť, sufix resolveru s překlepem a připnutá trasa na rozhraní, které se přečísluje, vypadají všechny jako původní závada. Právě opakování odděluje opravu od náhody.

Zapište trasu, adresu a resolver, které fungovaly, dokud byla VPN připojená. Příští připojení změní alespoň jedno z nich a poznámka promění příští výpadek v krátké srovnání místo nového vyšetřování.