Nem érhető el a helyi hálózat, miközben a VPN csatlakoztatva van? Négy ellenőrzés

Az alagút felépül, az intranet megjelenik, a nyomtató pedig abbahagyja a válaszadást. A LAN-on semmi nem hibásodott meg; az ügyfél változtatta meg, melyik útvonalat használja azokhoz a címekhez, amelyeket már nem tekint helyinek. Menj végig sorrendben az alábbi négy ellenőrzésen, és állj meg, amikor az egyik konkrét eltérést mutat, mert ugyanannak a tünetnek négy gyakori oka lehet, és közülük csak egyet orvosol a VPN szerkesztése.

Először nézd meg az ügyfél által telepített útvonaltáblát

Nyisd meg az ügyfél útvonaltábláját, amíg a VPN csatlakoztatva van. Linuxon használd az ip route parancsot, Windows alatt a route print vagy a Get-NetRoute parancsot, macOS-en pedig a netstat -rn parancsot. Azt keresed, hogy van-e alapértelmezett útvonal az alagúton keresztül, és hogy mi történt a fizikai alapértelmezett útvonallal.

A teljes alagutas ügyfél gyakran két fél-alapértelmezett útvonalat ad hozzá, a 0.0.0.0/1 és a 128.0.0.0/1 hálózatot, ahelyett hogy lecserélné a 0.0.0.0/0 útvonalat. Az eredeti alapértelmezett útvonal látható marad, de minden keresést elveszít, ezért tűnhet úgy, hogy a tábla sértetlen, miközben az alhálózaton kívüli forgalom mind elmozdul. Ha a VPN-ügyfél kínál osztott alagút lehetőséget, és a szabályzat engedi, az a legtisztább megoldás.

Ha az alagútnak kell maradnia az alapértelmezettnek, rögzítsd inkább a helyi alhálózatot. Linuxon az útvonal megnevezi a fizikai interfészt és az átjárót; Windows alatt add hozzá a -p kapcsolót, hogy állandó legyen, és olvasd ki az interfész számát a route print kimenetéből, ne találgasd:

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

A rögzített útvonal csak addig érvényes, amíg a benne megnevezett cím változatlan. Az a laptop, amely minden csatlakozáskor új számot kap a Wi-Fi adapterére, ismét megszegi a szabályt, ezért az interfész címét ellenőrizd, mielőtt arra jutnál, hogy a javítás nem működött.

Másodszor: erősítsd meg, hogy a cím eleve helyi volt

Ha a cél a csatlakoztatott alhálózaton belül van, az alagút alapértelmezett útvonala soha nem érvényesül, és nem a VPN az ok. Egy 192.168.1.40 címen lévő nyomtató egy 192.168.1.0/24 hálózatú ügyfélen a csatlakoztatott útvonalat használja; ha ez a cím nem működik, akkor az eszközt, a kapcsolót vagy az ügyfél tűzfalát nézd meg a VPN helyett.

Az az eset téveszti meg az embereket, amikor egy helyi szerverhez nyilvános cím tartozik. A LAN-on belülről az útválasztó WAN-címének elérése és az onnan való visszatérés hajtű-NAT-ot igényel, és sok útválasztó egyszerűen nem valósítja meg porttovábbításokhoz. Teszteld a privát címet a nyilvános mellett. Ha a privát cím működik, a nyilvános pedig nem, akkor a VPN csak egy már korábban is fennálló NAT-korlátot tett láthatóvá.

Egy hosztnév ezt csak súlyosbítja. Ha a helyi név most a nyilvános címre oldódik fel, az ügyfél folyamatosan azt az útvonalat próbálja, amely nem tud visszakanyarodni. A teszthez használd a privát címet, majd a nevet javítsd, ahelyett hogy újabb porttovábbítást adnál hozzá.

Harmadszor: nézd meg, ki válaszol most a nevekre

Egy vállalati feloldó ismeri az intranetet, és általában semmit sem tud egy NAS hosztnevéről, egy nyomtató Bonjour-nevéről vagy egy útválasztó helyi aliasáról. Amikor a VPN felküldi a DNS-kiszolgálóit, ezek a nevek már nem oldódnak fel, pedig a címeik továbbra is elérhetők. Kérdezd le a nevet közvetlenül, és hasonlítsd össze a választ azzal a címmel, amelyről tudod, hogy az eszköz használja.

Linuxon a resolvectl query nas.local megmutatja, melyik feloldó válaszolt. Windows alatt az nslookup nas.local megnevezi a kiszolgálót, az ipconfig /all pedig a feloldók sorrendjét mutatja. Ha a helyi utótagot most a vállalati feloldó kezeli, vagy irányítsd vissza azt az utótagot a helyi feloldóhoz, vagy használd az eszköz IP-címét.

A felderítés külön réteg. Az mDNS és a broadcast nem kel át egy routolt alagúton, ezért egy eszköz elérhető lehet cím alapján, miközben a neve láthatatlan marad. Egy reflector vagy egy helyi DNS-bejegyzés megoldja ezt; egy útvonal nem.

Negyedszer: ellenőrizd, hogy a másik gép is VPN-en van-e

Amikor az elérni kívánt gép is VPN-ügyfélt futtat, előfordulhat, hogy a munkameneted megérkezik, a válasza viszont a másik alagúton távozik. Ebből olyan kapcsolat lesz, amely felépül, majd megakad, vagy olyan RDP- és SSH-kísérlet, amely a te oldaladon hiba nélkül fut időtúllépésre. Nézd meg a másik hoszt útvonaltábláját és alapértelmezett útvonalát, mielőtt az ügyfelet hibáztatnád.

Azt is ellenőrizd, melyik címen figyel a szolgáltatás. Egy csak az alagút címéhez kötött listener elfogadja a VPN felől érkező kapcsolatokat, és visszautasítja a LAN felől érkezőket, még akkor is, ha az útvonalválasztás tökéletes. Ez szolgáltatáskonfiguráció, nem hálózati útvonal, és gyakori azokon a felügyeleti felületeken, amelyeket a VPN-címre zártak le.

Tarts fenn egy olyan felügyeleti útvonalat, amely nem függ az alagúttól: egy statikus útvonalat a forráshálózatod megnevezésével, egy másik, a LAN-hoz csatlakozó interfészt, vagy egy konzolt, amely teljesen megkerüli az alagutat. Ezt az útvonalat a munkamenet megszakadása után megtervezni sokkal nehezebb, mint a következő csatlakozás előtt hozzáadni.

Alkalmazd a bukott ellenőrzéshez illő javítást

Ha az útvonaltábla fél-alapértelmezett átvételt mutatott, válaszd az osztott alagutat, ha a szabályzat engedi, és rögzített helyi útvonalat, ha nem. Ha a cím nyilvánosnak bizonyult, állítsd át a tesztet és a nevet a privát címre. Ha a feloldó gazdát cserélt, szűkítsd a helyi utótagra, vagy használd a címet. Ha a másik hoszt alagúton van, javítsd a visszatérési útvonalát vagy a listener kötését.

Változtass egy dolgot, majd ismételd meg ugyanazt az ellenőrzést. Egy rossz alhálózatra felvett útvonal, egy elírt feloldó-utótag és egy olyan interfészre rögzített útvonal, amely új számot kap, mind az eredeti hibához hasonlítanak. Az ismétlés az, ami elválasztja a javítást a véletlentől.

Írd fel az útvonalat, a címet és a feloldót, amely a VPN csatlakoztatása mellett működött. A következő újracsatlakozás legalább egyet megváltoztat közülük, és a feljegyzés a következő kiesést rövid összehasonlítássá teszi egy újabb vizsgálódás helyett.