Lokalnetværket er utilgængeligt, mens VPN er forbundet? Fire kontroller

Tunnelen kommer op, intranettet dukker op, og printeren holder op med at svare. Intet på LAN'et er fejlet; klienten har ændret den vej, den bruger til adresser, som den ikke længere betragter som lokale. Gå de fire kontroller nedenfor igennem i rækkefølge, og stop når en af dem giver en konkret uoverensstemmelse, for det samme symptom har fire almindelige årsager, og kun én af dem rettes ved at redigere VPN'et.

Først: se på den routingtabel, klienten har installeret

Åbn klientens routingtabel, mens VPN'et er forbundet. På Linux brug ip route, på Windows brug route print eller Get-NetRoute, og på macOS brug netstat -rn. Du leder efter en standardrute gennem tunnelen og efter, hvad der skete med den fysiske standardrute.

En full-tunnel-klient tilføjer ofte to halve standardruter, 0.0.0.0/1 og 128.0.0.0/1, i stedet for at erstatte 0.0.0.0/0. Den oprindelige standardrute forbliver synlig, men mister hvert opslag, og derfor kan tabellen se intakt ud, mens al trafik uden for subnettet flytter sig. Hvis VPN-klienten tilbyder en split-tunnel-mulighed, og politikken tillader det, er det den reneste reparation.

Hvis tunnelen skal forblive standardruten, så fasthold i stedet det lokale subnet. På Linux angiver ruten det fysiske interface og gatewayen; på Windows tilføj -p for at gøre den permanent, og læs interface-nummeret fra route print i stedet for at gætte det:

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

En fastholdt rute holder kun, så længe adressen, den angiver, forbliver den samme. En bærbar computer, der omnummererer sin Wi-Fi-adapter ved hver forbindelse, vil bryde reglen igen, så kontrollér interface-adressen, før du konkluderer, at reparationen slog fejl.

For det andet: bekræft, at adressen var lokal i første omgang

Hvis destinationen ligger inde i det forbundne subnet, gælder tunnelens standardrute aldrig og VPN'et er ikke årsagen. En printer på 192.168.1.40 hos en klient med 192.168.1.0/24 bruger den forbundne rute; hvis den adresse fejler, så se på enheden, switchen eller firewallen på klienten i stedet for VPN'et.

Det tilfælde, der narre folk, er en offentlig adresse til en lokal server. Inde fra LAN'et kræver det hairpin-NAT at nå routerens WAN-adresse og komme tilbage, og mange routere implementerer det simpelthen ikke for portforwarding. Test den private adresse ved siden af den offentlige. Hvis den private adresse virker, og den offentlige ikke gør, har VPN'et kun blotlagt en NAT-begrænsning, der allerede var der.

Et værtsnavn gør det værre. Hvis det lokale navn nu opløses til den offentlige adresse, vil klienten blive ved med at forsøge den vej, der ikke kan løbe tilbage. Brug den private adresse til testen, og ret derefter navnet i stedet for at tilføje endnu en portforwarding.

For det tredje: se, hvem der svarer på navne nu

En virksomhedsresolver kender intranettet og normalt intet om et NAS-værtsnavn, en printers Bonjour-navn eller en routers lokale alias. Når VPN'et skubber sine DNS-servere ud, holder de navne op med at opløses, selv om deres adresser stadig er tilgængelige. Forespørg navnet direkte, og sammenlign svaret med den adresse, du ved enheden har.

På Linux viser resolvectl query nas.local, hvilken resolver der svarede. På Windows angiver nslookup nas.local serveren, og ipconfig /all viser rækkefølgen af resolvere. Hvis det lokale suffix nu håndteres af virksomhedsresolveren, så send suffixet tilbage til den lokale resolver, eller brug enhedens IP-adresse.

Opdagelse er et separat lag. mDNS og broadcast krydser ikke en routet tunnel, så en enhed kan være tilgængelig via adresse, mens dens navn forbliver usynligt. En reflektor eller en lokal DNS-post løser det; en rute gør ikke.

For det fjerde: kontrollér, om den anden maskine også er på et VPN

Når maskinen, du vil nå, også kører en VPN-klient, kan din session ankomme, mens dens svar forlader gennem den anden tunnel. Det giver en forbindelse, der etableres og derefter går i stå, eller et RDP- og SSH-forsøg, der timer ud uden fejl på din side. Kontrollér den anden værts routingtabel og dens standardvej, før du bebrejder din klient.

Kontrollér også den adresse, tjenesten lytter på. En listener, der kun er bundet til tunneladressen, accepterer forbindelser fra VPN'et og afviser dem fra LAN'et, selv når routing er perfekt. Det er en tjenestekonfiguration, ikke en netværksvej, og det er almindeligt på administrationsgrænseflader, der blev låst til VPN-adressen.

Hold en administrationsvej, der ikke afhænger af tunnelen: en statisk rute, der angiver dit kildenettet, en anden grænseflade tilsluttet LAN'et eller en konsol, der omgår tunnelen helt. At designe den vej, efter sessionen er faldet, er meget sværere end at tilføje den før næste forbindelse.

Anvend den reparation, der passer til den kontrol, der fejlede

Hvis routingtabellen viste en halv-standard-opsnapning, så vælg split tunnel, når politikken tillader det, og en fastholdt lokal rute, når den ikke gør. Hvis adressen viste sig at være offentlig, så skift testen og navnet til den private adresse. Hvis resolveren skiftede hænder, så afgræns det lokale suffix, eller brug adressen. Hvis den anden vært er tunelleret, så ret dens returvej eller dens listener-binding.

Ændr én ting, og gentag derefter den samme kontrol. En rute, der er tilføjet for det forkerte subnet, et resolver-suffix med en tastefejl og en fastholdt rute på et interface, der omnummererer, ser alle ud som den oprindelige fejl. Gentagelsen er det, der skiller en reparation fra en tilfældighed.

Skriv ruten, adressen og resolveren ned, som virkede, mens VPN'et var forbundet. Den næste genforbindelse vil ændre mindst én af dem, og noten gør den næste afbrydelse til en kort sammenligning i stedet for en ny undersøgelse.