IPsec-alagút felületének monitorozása: mit érdemes olvasni

Egy útvonalalapú IPsec-terv virtuális felületet telepít, és ez a felület konkrét objektumot ad a monitorozásnak: valamit, aminek neve, számlálói és hozzá kapcsolt útvonala van. Önmagában nem egészségjel. A felület létezhet úgy, hogy nincs telepítve használható társítás, és a társítás lehet egészséges úgy, hogy egyetlen útvonal sem küldi felé az érdekes forgalmat. Négy állapot együttes olvasása az, ami egy csomagszámlálót diagnózissá tesz.

Haladjon végig rajtuk sorrendben, és álljon meg az elsőnél, amelyik elbukik.

Mit ad a felület a képhez

Szabályalapú tervnél a kiválasztás az IPsec-szabálytáblában él, és a kernel a forgalomszelektorok alapján dönti el, mi kerül védelem alá. Az útvonalalapú terv felületet és útvonalat ad hozzá, így a tcpdump és a felületi számlálók egyetlen határt látnak szelektorhalmaz helyett. Ez valódi nyereség a diagnosztika és az olyan útválasztási protokollok számára, amelyeknek felületre van szükségük a peeringhez.

A nyereség adminisztratív, nem kriptográfiai. A felület a rajta átmenő forgalomról számol be, és semmit sem mond arról, hogy a partner védelme jelenleg használható-e.

Olvassa el a négy állapotot, mielőtt az alagutat okolná

Kezdje a felülettel és az útvonallal, aztán a társítással, aztán az alkalmazással. Mindegyiknek saját parancsa és saját hiba-aláírása van. Egy tiszta eredmény az egyik rétegen nem tiszta eredmény a következőn. Futtassa mind a négyet, mielőtt következtetést von le. Egy zöld sor ritkán dönt el bármit.

ip -s link show xfrm0
ip route get 10.20.30.40
ip xfrm state
ip xfrm policy
swanctl --list-sas
tcpdump -ni xfrm0 -c 20 host 10.20.30.40

Az a felület, amelynek számlálója nő, de nincs hozzá tartozó állapotbejegyzés, olyan forgalmat ír le, amely olyan útra lép, ahol semmi sem védi, ami rosszabb, mint egy egyszerűen leállt alagút. Az útvonal nélküli állapotbejegyzés, amely kiválasztaná a felületet, azt jelenti, hogy a kriptográfia kész és kihasználatlan.

Az alkalmazásteszt szándékosan utolsóként jön: az alagút túloldalára sikeres ping nem bizonyítja, hogy a mögötte lévő szolgáltatás elfogad kapcsolatokat.

Hasonlítsa össze a belső számlálókat a külsőkkel

Az alagút felületének számlálói a belső forgalmat mérik; a fizikai felület számlálói és rögzítései a beágyazott cserét mutatják. A kettő nem fog egy az egyben megegyezni, mert a beágyazás fejléceket ad hozzá, az újraküldések megkettőznek néhány csomagot, és a megvalósítás elszámolása saját szabályokat követ. Arányra számítson, ne egyenlőségre.

A rögzítés helye azt is eldönti, milyen személyes adatokat gyűjt, ezért használjon szűk szűrőket és ártalmatlan tesztcímet a termelési forgalom teljes rögzítése helyett.

Ha a belső számlálók nőnek és a külsők nem, a hiányzó lépés általában az útvonal vagy a szabály, amely a csomagokat az alagútba küldi, nem maga az alagút.

Kövesse végig kulcscsere és átállás közben

Figyeljen meg egy kulcscserét, egy halott partner észlelési eseményt és egy kapcsolat-átállást, miközben ugyanazt a négy állapotot nézi. A felület megmaradhat egy soha be nem fejeződő kulcscsere alatt, és egy átállás olyan állapotbejegyzést hagyhat hátra, amely egy már elérhetetlen partner-címre mutat.

Arra a szolgáltatási útra riasszon, amelytől valóban függ, a társítás állapotával kontextusként, ne egyetlen fel- vagy le-flagre. Tartsa meg a felület nevét, a partner címét és az útvonalat a riasztás hasznos tartalmában, hogy a reagálónak ne kelljen újraépítenie őket.

A strongSwan a saját XFRM-felületmodelljét dokumentálja, más platformok pedig másképp nevezik el és valósítják meg az egyenértékű objektumot. Olvassa el az útvonalalapú összehasonlítást az előtte álló eszközre, mielőtt feltételezéseket visz át egy másik megvalósításból. Egy olyan monitorozási sablon, amely egy gyártó számlálóihoz illik, egy másiknál csendesen félrevezet.