Kohalik võrk on VPN-iga ühendatud ajal kättesaamatu? Neli kontrolli

Tunnel tõuseb, intranet ilmub ja printer lakkab vastamast. Kohalikus võrgus ei ole miski katki läinud; klient muutis teed, mida ta kasutab aadresside jaoks, mida ta enam kohalikuks ei pea. Käige allolevad neli kontrolli järjekorras läbi ja peatuge, kui üks annab konkreetse lahknevuse, sest samal sümptomil on neli tavalist põhjust ja ainult ühte neist parandab VPN-i muutmine.

Esiteks vaadake marsruutimistabelit, mille klient paigaldas

Avage kliendi marsruutimistabel, kui VPN on ühendatud. Linuxis kasutage ip route, Windowsis route print või Get-NetRoute ja macOS-is netstat -rn. Te otsite vaikimisi marsruuti läbi tunneli ja seda, mis juhtus füüsilise vaikimisi marsruudiga.

Täistunneli klient lisab sageli kaks pool-vaikimisi marsruuti, 0.0.0.0/1 ja 128.0.0.0/1, selle asemel et 0.0.0.0/0 asendada. Algne vaikimisi marsruut jääb nähtavale, kuid kaotab iga otsingu, mistõttu võib tabel paista terve, samal ajal kui kogu liiklus väljaspool alamvõrku liigub. Kui VPN-klient pakub jagatud tunneli valikut ja poliitika lubab seda, on see puhtaim parandus.

Kui tunnel peab jääma vaikimisi marsruudiks, kinnitage hoopis kohalik alamvõrk. Linuxis nimetab marsruut füüsilist liidest ja lüüsi; Windowsis lisage -p, et see oleks püsiv, ja lugege liidese number välja route print-st, mitte ärge oletage seda:

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

Kinnitatud marsruut püsib ainult seni, kuni aadress, mida see nimetab, jääb samaks. Sülearvuti, mis nummerdab oma Wi-Fi-adapteri igal ühendamisel ümber, rikub reegli jälle, seega kontrollige liidese aadressi enne, kui otsustate, et parandus ebaõnnestus.

Teiseks kinnitage, et aadress oli algusest peale kohalik

Kui sihtkoht asub ühendatud alamvõrgu sees, ei rakendu tunneli vaikimisi marsruut kunagi ja VPN ei ole põhjus. Printer aadressil 192.168.1.40 kliendis, millel on 192.168.1.0/24, kasutab ühendatud marsruuti; kui see aadress ei toimi, vaadake seadet, kommutaatorit või kliendi tulemüüri, mitte VPN-i.

Juhtum, mis inimesi eksitab, on avalik aadress kohaliku serveri jaoks. Kohaliku võrgu seest nõuab ruuteri WAN-aadressile jõudmine ja tagasi tulemine hairpin-NAT-i ning paljud ruuterid lihtsalt ei rakenda seda pordiedastuste jaoks. Testige privaatset aadressi avaliku kõrval. Kui privaatne aadress töötab ja avalik mitte, paljastas VPN vaid NAT-piirangu, mis oli juba varem olemas.

Hostinimi teeb selle hullemaks. Kui kohalik nimi laheneb nüüd avalikuks aadressiks, jätkab klient tee proovimist, mis ei saa tagasi tulla. Kasutage testiks privaatset aadressi ja parandage seejärel nimi, selle asemel et lisada veel üks pordiedastus.

Kolmandaks vaadake, kes nüüd nimedele vastab

Ettevõtte resolver tunneb intranetti ja tavaliselt ei tea midagi NAS-i hostinimest, printeri Bonjour-nimest ega ruuteri kohalikust aliaksest. Kui VPN surub peale oma DNS-serverid, lakkavad need nimed lahenemast, kuigi nende aadressid on endiselt kättesaadavad. Küsige nime otse ja võrrelge vastust aadressiga, mille seadmel teadaolevalt on.

Linuxis näitab resolvectl query nas.local, milline resolver vastas. Windowsis nimetab nslookup nas.local serveri ja ipconfig /all näitab resolverite järjekorda. Kui kohalikku sufiksit haldab nüüd ettevõtte resolver, suunake see sufiks tagasi kohalikule resolverile või kasutage seadme IP-aadressi.

Avastamine on eraldi kiht. mDNS ja ringhääling ei ületa marsruuditud tunnelit, seega võib seade olla aadressi järgi kättesaadav, samal ajal kui selle nimi jääb nähtamatuks. Reflektor või kohalik DNS-kirje lahendab selle; marsruut mitte.

Neljandaks kontrollige, kas ka teine masin on VPN-is

Kui masin, kuhu soovite pääseda, käitab samuti VPN-klienti, võib teie seanss saabuda, samal ajal kui selle vastus lahkub teise tunneli kaudu. See tekitab ühenduse, mis luuakse ja seejärel takerdub, või RDP ja SSH katse, mis aegub ilma veata teie poolel. Kontrollige teise hosti marsruutimistabelit ja selle vaikimisi teed enne, kui süüdistate oma klienti.

Kontrollige ka aadressi, millel teenus kuulab. Ainult tunneli aadressiga seotud kuulaja võtab VPN-ist ühendusi vastu ja keeldub kohalikust võrgust neist, isegi kui marsruutimine on täiuslik. See on teenuse konfiguratsioon, mitte võrgutee, ja see on tavaline haldusliidestel, mis lukustati VPN-i aadressi külge.

Hoidke haldustee, mis ei sõltu tunnelist: staatiline marsruut, mis nimetab teie lähtevõrku, teine kohaliku võrguga ühendatud liides või konsool, mis möödub tunnelist täielikult. Selle tee kujundamine pärast seansi katkemist on palju raskem kui selle lisamine enne järgmist ühendust.

Rakendage parandus, mis vastab ebaõnnestunud kontrollile

Kui marsruutimistabel näitas pool-vaikimisi haaramist, valige jagatud tunnel, kui poliitika lubab, ja kinnitatud kohalik marsruut, kui ei luba. Kui aadress osutus avalikuks, lülitage test ja nimi privaatsele aadressile. Kui resolver vahetus, piirake kohalik sufiks või kasutage aadressi. Kui teine host on tunnelis, parandage selle tagasitee või kuulaja sidumine.

Muutke ühte asja ja korrake seejärel sama kontrolli. Vale alamvõrgu jaoks lisatud marsruut, kirjaveaga resolveri sufiks ja kinnitatud marsruut liidesel, mis nummerdab ümber, näevad kõik välja nagu algne rike. Kordamine on see, mis eristab parandust juhusest.

Kirjutage üles marsruut, aadress ja resolver, mis töötasid VPN-i ühendatud ajal. Järgmine taasühendus muudab vähemalt ühte neist ja märkus muudab järgmise katkestuse uue uurimise asemel lühikeseks võrdluseks.