Router VPN-kliensmódban: miért tűnnek el a LAN-eszközök

Az a hit, hogy a kliensmód önmagában megöli a LAN-hozzáférést, az embereket a rossz beállításmenübe küldi, és a valódi okok általában ketten vannak. Az alagút nem távolítja el a LAN-hidat, és nem akadályozza meg a vezetékes és vezeték nélküli klienseket abban, hogy elérjék egymást. A helyi hozzáférést vagy a router továbbítási útvonalában ülő ellenőrző funkció töri meg, vagy egy LAN-címtartomány, amely elmozdult, amikor a firmware tette. Mindkettő ugyanazt a panaszt okozza, és egyiket sem javítja a VPN-profil újratelepítése.

A mítosz, és mit változtat meg valójában a kliensmód

A kliensmód hozzáad egy alagút-interfészt és egy alapértelmezett útvonalat, amely azon keresztül megy, majd továbbítja a LAN-forgalmat ebbe az alagútba. A vezetékes portok és a vezeték nélküli rádiók közötti híd érintetlen marad, csakúgy, mint a helyi kapcsolás. Ami változik, az a szabályzat: melyik forgalom kerül továbbításra, hol fordítódik le, és melyik feloldót kapják a kliensek.

Ez a különbség számít, mert a törött LAN általában azt jelenti, hogy a három szabályzat egyike megváltozott, nem azt, hogy a router megszűnt switch lenni. Az a router, amely még mindig válaszol a saját felügyeleti oldalára, bizonyíték arra, hogy a LAN-interfész él. Az a router, amely egyáltalán semmire sem válaszol, más problémával küzd, például megváltozott LAN-címmel vagy rossz alhálózaton lévő klienssel.

Tehát a hasznos első lépés annak megállapítása, melyik réteg tört el, nem pedig annak a rétegnek a megváltoztatása, amelyre gyanakszik.

Teszteljen három célt, mielőtt bármelyik beállításhoz nyúl

Egy vezetékes kliensről teszteljen három célt külön-külön, és írja fel mindegyik eredményét: a router saját LAN-címét, egy másik eszközt ugyanazon a switch-en IP szerint, és valamit, ami csak az alagúton keresztül érhető el. Ebben a sorrendben tegye, mert mindegyik eredmény más réteget zár ki. Az első körben címeket használjon nevek helyett, mert a névhiba DNS-t kever egy kapcsolódási kérdésbe.

A válaszok mintája az diagnózis. Az a router, amely válaszol, miközben a helyi eszközök nem, helyi kapcsolásra vagy szűrőfunkcióra utal, nem útvonalválasztásra. A helyi eszközök, amelyek válaszolnak, miközben az alagút oldala nem, az alagút útvonalára vagy a távoli tűzfalra utalnak. Ha minden cím szerint válaszol, de a nevek meghiúsulnak, az feloldó kérdés, és semmilyen útvonal-szerkesztés nem javítja meg.

Tartsa a táblázatot a teszteredmények mellett. Egy homályos panaszt egy cselekvhető sorrá alakít.

A biztonsági réteg a továbbítási útvonalon belül

A fogyasztói routerek egyre gyakrabban tartalmaznak olyan ellenőrző funkciót, amely figyeli a továbbított forgalmat, és ugyanazon az útvonalon fut, amely a LAN-ból az alagútba viszi a csomagokat. Amikor ez az ellenőrzés nem tudja osztályozni az alagút forgalmát, a továbbítás elakadhat, miközben maga az alagút fennmarad, és a router egészséges kapcsolatot jelent. A VPN-naplóban semmi sem mutatja ezt, mert a VPN valóban csatlakozott.

A diagnózis kontrollált kísérlet, nem állandó változtatás. Jegyezze fel a jelenlegi beállítást, kapcsolja ki a funkciót egy teszt idejére, hozza fel újra az alagutat, és teszteljen egyetlen helyi gazdagépet cím szerint. A visszatérő továbbítás a szükséges bizonyíték, és akkor a kompromisszum döntéssé válik találgatás helyett. Ha semmi sem változik, azonnal kapcsolja vissza, és térjen át a címzés okára.

Egy fizetett biztonsági funkciót kikapcsolva hagyni, hogy az alagút tovább működjön, olyan kompromisszum, amelyet szándékosan kell megtenni és leírni. Érdemes azt is megkérdezni, hogy az alagút más eszközre való-e, mert a mindent ellenőrizni kényszerülő router és a mindent továbbítani kényszerülő router két különböző munka.

A második ok: a LAN-tartomány elmozdult

A firmware-frissítések rutinszerűen visszaállítják a LAN-címet a gyártó alapértelmezésére, és egyes routereknek kifejezett módkapcsolójuk van, amely eldönti, hogy a LAN megtart-e egy privát tartományt, vagy örököl egyet a felette lévő eszköztől. Az a kliens, amely 192.168.8.x-et vár, 10.64.0.x-re kerülhet, és akkor egy SSH-munkamenet a gazdagéphez lejár, pedig az alagút teljesen egészséges.

ipconfig /all
ip addr show
ip route get 192.168.8.20

Olvassa ki az előtagot és az átjárót a bérletből, mielőtt megnyitja a router oldalát. Az első két parancs megmutatja, mit kapott a kliens valójában, a harmadik pedig azt, melyik interfészt használná a kliens egy helyi címhez, és így árulja el magát egy maradék útvonal vagy egy elavult alhálózat. Ezután hasonlítsa össze a LAN-oldallal és a router módjával.

Ha a tartomány nem tud visszatérni, frissítse minden objektumot, amely megnevezi: DHCP-foglalásokat, minden statikus útvonalat a régi alhálózatba, és minden tűzfalszabályt, amely a korábbi előtagot hordozza. A tartomány, amely ütközik az alagút távoli alhálózatával, a rosszabb változat, mert a helyi eszközök elérhetők maradnak, miközben a távoli célok csendben a LAN-ba irányítódnak.

Csatlakozzon újra, és teszteljen újra csomagsorrendben

Bármelyik változtatás után csatlakoztassa újra az alagutat, és ismételje meg a teszteket csomagsorrendben: router, helyi gazdagép, távoli gazdagép, majd nevek, majd az alkalmazás. Az alkalmazás elsőként tesztelése elrejti, melyik réteg törött még, és a böngésző újrapróbálkozása egy gyorsítótárazott névvel útvonalválasztási hibának tűnhet.

Jegyezze fel a firmware verzióját, a LAN-előtagot és az ellenőrző funkció állapotát a VPN-profil mellé. Mindhárom olyan konfiguráció, amelyet a következő frissítés felülírhat, és két sor jegyzet megspórolja az imént eltöltött órát.