A VPN csatlakozik, de a LAN-eszközök nem érhetők el: mit kell ellenőrizni

A forgalom belép az alagútba, az átjáró a saját címén válaszol, és mögötte semmi sem válaszol. Ez a minta gyakori, és nem ellentmondás: az átjáró válasza bizonyítja, hogy az alagút befejeződött, és semmit sem bizonyít arról, mi történik a mögé címezett csomaggal. A két teszt különböző kódutakat gyakorol ugyanazon a gépen.

Mostantól teszteljen valamit az átjáró túloldalán. Az átjáró saját címe továbbra is válaszol, bármennyire is törött a továbbítás.

Az átjáró a saját vereméből válaszol

Az átjárónak címzett csomag a helyi bemeneti útvonalára kerül, ahol a kernel eldönti, hogy egy figyelő socket elfogadja-e. Az átjáró mögötti gazdagépnek címzett csomag ehelyett a továbbítási útvonalra kerül, ahol más ellenőrzések érvényesek. A továbbítás teljesen ki lehet kapcsolva, vagy a kernel bekapcsolhatja, majd egy olyan szűrőszabály utasíthatja el, amely soha nem említi az alagutat. Mindez nem érinti az átjáró saját válaszát, ezért vezet félre olyan megbízhatóan a tünet.

Az alagúton keresztül elért adminisztrációs oldalak szintén az első kategóriába tartoznak. Bizonyítékok az alagútról, nem a mögötte lévő hálózatról.

Kövesse a forgalmat az első határig, amely elejti

Kezdje az ügyfélnél, és erősítse meg az útvonalat és a forrás címet, amelyet a forgalom használni fog. Ezután figyelje az átjárót, hogy pontosan ez a forgalom megérkezik-e, majd ismét ugyanezt a forgalmat a LAN felé távozva. Ha soha nem érkezik meg, a probléma az ügyfél oldalán vagy az alagút engedélyezett előtagjaiban van. Ha megérkezik és soha nem távozik, a probléma a továbbításban vagy az előre vezető útvonal szűrőjében van, és a rögzítés már megmondta, melyik.

Ugyanannak a tesztnek az átjáróról való futtatása elrejti az érdekes felét, mert az átjáróról származó csomagnak más a forrása és más a visszatérési követelménye. Minden lépésnél az ügyfél forgalmát használja, a saját forráscímével együtt. A rossz interfészen készült rögzítés magabiztos ostobaságot ad.

A visszatérési útvonalak és a gazdagép-tűzfalak külön-külön hibáznak

Miután a csomag eléri a gazdagépet, három további dolognak kell teljesülnie. A szolgáltatásnak azon a címen kell figyelnie, ahová a csomagot küldték, a gazdagép tűzfalának el kell fogadnia, és a válasznak visszafelé vezető útvonallal kell rendelkeznie az ügyfélkészlet felé. Az utolsó gyakran meghiúsul, mert a gazdagép alapértelmezett útvonala olyan routerre mutat, amely soha nem hallott az alagút tartományáról. Az eredmény egy kapcsolat, amely a gazdagép szemszögéből jön létre, és a másik irányban csendben meghal.

Tesztelje szándékosan a visszatérési utat azzal, hogy az ügyféltől küld, és figyeli a visszatérést. Az egyirányú rögzítés másodpercek alatt eldönti azt, amit egy óra találgatás nem fog eldönteni.

Erősítse meg minden ugrást az ügyfél forráscímével

Futtassa az ellenőrzéseket sorrendben, és őrizzen meg minden kimenetet, mert az érték az összehasonlításban van, nem egyetlen sorban. Az alábbi parancsok rögzítik a forráscímet, megmutatják a választott útvonalat, és rögzítik a továbbítás mindkét oldalát. Cserélje ki a saját LAN-gazdagépét és alagút-interfészét.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

Az útvonal-lekérdezés megmutatja, hogy az ügyfél egyáltalán elküldené-e ezt a csomagot az alagútba, a ping pedig megmutatja, hogy jött-e vissza valami a gazdagéptől. A két rögzítés összehasonlítása elválasztja a megérkezést a távozástól, mivel az alagút interfészén lévő keret a LAN interfészén lévő megfelelő nélkül továbbítási döntés, nem szolgáltatáshiba. Ha mindkét rögzítés mutatja a kérést, és csak az egyik mutatja a választ, a visszatérési útvonal a fennmaradó gyanúsított.

Jegyezze fel, melyik cím válaszolt, és melyik továbbított célcím hiúsult meg. Ez a mondat cselekvőképessé teszi a jelentést azzal a kijelentéssel szemben, hogy a kiszolgáló elérhetetlen.