Miért nem egy útválasztási tábla bejegyzése az IPsec biztonsági szabályzat

Pingelje a 10.20.0.5-öt az alagúton keresztül, és semmi sem jön vissza, miközben az útválasztási tábla azt állítja, hogy az az alhálózat elérhető. Az útválasztás és az IPsec különböző kérdésekre válaszol, és csak az egyik szól az elérhetőségről. Az előretekintő keresés kiválaszt egy útvonalat, majd a biztonsági szabályzat adatbázisa eldönti, hogy azt az útvonalat védeni kell, békén kell hagyni vagy el kell utasítani. Amikor a kettő ellentmond egymásnak, a csomag csendben meghal, ezért ebben a sorrendben olvassa őket.

A kereséssel kezdje, ne a táblával

Kérdezze meg a kernelt, mit tenne valójában: a ip route get 10.20.0.5 kiírja a kiválasztott útvonalat, a kimenő interfészt és a forrás címet, amelyet használna. Egy előtag, egy szabályzatszabály, egy jelölés vagy egy előnyben részesített forrás mind megváltoztathatja ezt a választ, ezért az élő keresés jobb, mint a tábla szemmel való olvasása.

A védett tartományon belüli célpontot tesztelje, ne az átjáró címét. A túloldali átjáró elérése csak azt bizonyítja, hogy létezik valamilyen útvonal; semmit nem mond arról az alhálózatról, amelyre valóban szüksége van. Ezután erősítse meg, hogy a keresés által kiválasztott interfész az, amelyet az alagúttól vár.

Egyeztesse a szelektorokat mindkét oldalon

A szabályzat adatbázisának saját bejegyzései vannak, és mindegyik megnevez egy irányt, egy forrást, egy célt és egy protokollt, majd megmondja, mi történjen az egyező csomagokkal. A listázáshoz használja az ip xfrm policy parancsot; a jelzők megmutatják, hogy a művelet védelem, megkerülés vagy blokkolás. Egy szabályzat, amelynek szelektorai szélesebbek vagy szűkebbek a tesztfolyamánál, nem fog egyezni vele, és a csomag védelem nélkül távozik. Ez az a hiba, amelyet keres, nem egy hiányzó útvonal.

Hasonlítsa össze a tényleges értékeket: forrás, cél, protokoll és portok. Ha a keresés egy cím párt oldott fel, miközben a szabályzat bejegyzése egy másikat fed le, a két nézet különböző forgalmat ír le. Futtassa mindkettőt újra ugyanazzal a tuple-lel, mielőtt következtetést von le, különben olyan szabályzatot szerkeszt, amely soha nem volt az útvonalon.

A szabályzat egyezése nem telepített állapot

Az egyező szabályzat csak azt mondja, hogy a csomagot védeni kell; a kernelnek még mindig szüksége van egy biztonsági társításra a védelem végrehajtásához. Listázza őket az ip xfrm state paranccsal, vagy a swanctl --list-sas paranccsal, amikor a strongSwan tárgyal, és olvassa el az egyes bejegyzések szelektorait és számlálóit.

Amikor egy szabályzat egyezik, és egyetlen társítás sem fedi le ugyanazokat a szelektorokat, a csomag eldobásra kerül, ahelyett hogy nyílt szövegben küldenék el. Ez az a dobás, amelyet akkor kell keresni, amikor az alagút fent van, de egyetlen alhálózat meghibásodik. A számlálók elmondják a többit: egy társítás, amely soha nem nő, soha nem lett kiválasztva, míg az, amely nő és mégis dobással végződik, a távoli oldalra mutat. A szelektorok javítása és a kulcsok megújítása különböző javítások, ezért döntse el, melyikre van szüksége, mielőtt hozzányúl a konfigurációhoz.

Mit követel még az útvonalalapú alagút

Az XFRM interfész olyan eszköznek láttatja az alagutat, amelybe útvonalat lehet irányítani, ami valóban hasznos. Nem távolítja el azt a szabályzatot és állapotot, amelyek eldöntik, mi történik, amikor a csomag odaér. Az útvonal egy következő ugrást ad, semmi többet.

Ha az eszköz létezik, és az útvonal bele mutat, miközben egyetlen társítás sem egyezik a belső szelektorokkal, a csomag eldobásra kerül, és az útvonalak szerkesztése semmilyen mennyiségben nem állít elő kulcsokat vagy szelektorokat. Ellenőrizze az interfészt ugyanazzal a forrással és céllal, amelyet átirányított, majd hasonlítsa össze az állapotlistával.

Tisztázza a tulajdonjogot, mielőtt bármit szerkeszt

A gazdagép tűzfala egy harmadik döntést ad hozzá, amelyet a két adatbázis egyike sem ismer. Egy helyes útvonal plusz egy egyező szabályzat plusz egy telepített társítás még mindig eldobott csomaggal végződhet, és az alkalmazás csak az időtúllépést jelenti. Erősítse meg, hogy a tűzfal engedélyezi a védett forgalmat, mielőtt az IPsecet hibáztatja. Az alagút eszközén és a fizikai interfészen végzett rögzítés megmutatja, a titkosítás melyik oldalán tűnt el a csomag.

A konfiguráció tulajdonjoga dönti el, hogy a javítása túléli-e az újraindítást. Az egyik komponens telepíthet állapotot, míg egy másik az útvonalakat kezeli, és a másodikon végzett kézi szerkesztés felülíródik, amikor az alagút legközelebb feljön. Módosítsa a tulajdonos konfigurációt, majd olvassa újra mindkét nézetet; az RFC 4301 külön tartja a két adatbázist, amikor a felosztást valaki másnak kell elmagyaráznia.