Az IPsec-átjáróról indított ping más forráscímet használ

Pingelje a túloldalt az IPsec-átjáróról, ne kapjon választ, és vonja le a következtetést, hogy az alagút elromlott, miközben az átjáró mögötti minden munkaterhelés normálisan továbbít forgalmat. A két eredmény nem mond ellent egymásnak. Az átjárón indított ping helyi forrású csomag, és az átjáró a saját útválasztási táblájából választ forráscímet. Ez a választás eltérhet a valódi telephelyi forgalom által használt címektől, ami megváltoztatja, melyik szabályzat illeszkedik és melyik visszaút érvényes. Döntse el, mit kell a tesztnek bizonyítania, mielőtt bármit is belemagyarázna az eredménybe.

Három különböző kérdés, amelyre egy ping válaszolhat

Az első kérdés, hogy a túloldal egyáltalán elérhető-e erről a hosztról. A második, hogy az alagút szelektorai vagy az útvonalalapú szabályzat beengedik-e egy adott forrás forgalmát. A harmadik, hogy az átjáró mögötti munkaterhelésből továbbított forgalom végponttól végpontig működik-e. Egy parancs nem tud mindháromra válaszolni, és a forráscím az, ami elválasztja őket.

Először a kérdést válassza. Különben a sikertelen ping bizonyíték lesz arra az elméletre, amely már korábban is megvolt.

Miért választ az átjáró olyan címet, amelyre nem számított

Amikor egy célállomást pingel, a helyi verem az ahhoz illeszkedő útvonalból választ forrást. Útvonalalapú alagútnál ez lehet az alagút-interfész kapcsolatcíme, amely sok telephely-tervben egy 169.254.x.x pár, amelyet a pont-pont ugráshoz választottak. Ezek a címek azért léteznek, hogy a kapcsolat működjön; a túloldalon nem hirdetik őket alkalmazás-forráshálózatként.

Így a túloldal olyan címről kaphat visszhangkérelmet, amelyre nincs visszaútja, vagy olyanról, amelyre egyetlen szelektor sem illeszkedik. Az alagút lehet egészséges, és a ping mégis elbukhat, és pontosan ez az a hamis negatív, amelyről ez a cikk szól.

Válassza a forrást szándékosan

Egy ellenőrzött Linux-átjárón válasszon olyan forrást, amely már helyileg hozzá van rendelve: ping -c 4 -I 10.30.0.1 10.40.0.20. Az itteni címek szemléltetőek, ezért helyettesítse az átjáró valódi belső címével és egy valódi távoli célállomással, és erősítse meg, hogy a választott forrás ehhez az eszközhöz tartozik, és a telephelyi szabályzat engedi.

Ne kérje kölcsön egy munkaterhelés címét a teszthez. Egy olyan hoszt megszemélyesítése, amely nincs az átjáróhoz rendelve, olyan eredményt hoz létre, amelyet senki sem tud megismételni, és egyes vermeken olyan módon bukik el, amely alagúthibának látszik.

A visszautat olvassa, ne csak a kérést

Ellenőrizze, melyik forrás érkezik meg valóban a távoli célállomásra, beleértve az útközbeni szándékos fordítást is. Ezután ellenőrizze a túloldal visszaútját ehhez a forráshoz, valamint azokat a szelektorokat vagy szabályzatot, amelyek engedélyezik. Egy váratlan forrással érkező kérés útválasztási és szabályzati kérdés, nem kriptográfiai.

Itt segít többet egy csomagrögzítés, mint egy újabb ping: megmutatja azt a forrást, amelyet a túloldal látott, és az a cím, amelyet a válaszának el kell érnie.

Ezután tesztelje a munkaterhelést

A döntő teszt egy ping az átjáró mögötti hétköznapi hosztról a távoli átjáró mögötti hétköznapi hosztra. Ez gyakorolja az átjáró továbbítási szerepét, az alkalmazás valódi forrását és a tényleges visszautat, és ez az a folyam, amely a felhasználóknak fontos.

Tartsa külön az eredményeket a jegyzeteiben: az átjáróról való elérhetőség, a kiválasztott forrás szabályzati engedélyezése és a továbbított forgalom. Egy sikeresen rögzített ping hasznos bizonyíték arra, hogy az alagút szállít valamit; nem bizonyíték arra, hogy minden továbbított folyam működik. És egy automatikusan választott átjáró-forrás, amely nem érhető el, nem bizonyíték arra, hogy a telephelyi alagút leállt.

Ne adjon hozzá általános útvonalat a 169.254.0.0/16-hoz csak azért, hogy egy diagnosztikai választ kapjon. Ez egy félrevezető tesztet cserél le egy állandó útválasztási döntésre, és a következő ember kontextus nélkül örökli.