IPsec ESP: mit szállít, és hogyan bizonyítható, hogy folyik

Az ESP szállítja a forgalmat egy IPsec VPN-ben, és a runbookja egy szabállyal kezdődik: olvassa el a biztonsági társítást, mielőtt szabályzatot módosít. A legtöbb megmagyarázatlan ESP-viselkedés olyan szelektorra vezethető vissza, amely nem egyezett, olyan módra, amelyet olvasás helyett feltételeztek, vagy olyan számlálóra, amelyet senki sem ellenőrzött, miközben egyetlen folyamot küldtek. Az alábbi három lépés megállapítja, mi mit szállít, bizonyítja, hogy egy folyam használja, és olyan visszaállítást hagy hátra, amely nem függ az emlékezettől. Minden lépés egy megfigyelést ad, amelyet érdemes leírni.

Ismerje a mezőket, mielőtt olvassa őket

Az ESP fejlécet tesz a védett adatok elé és trailert mögéjük. A fejléc biztonsági paraméterindexet hordoz, amely azonosítja, melyik társítást használja a fogadó, sorszámot az ismétlés észleléséhez, a trailerben pedig kitöltést, amely a hasznos terhet a titkosítóhoz igazítva tartja. A trailer következő fejléc mezője megmondja, mi a védett tartalom, és így tudja a fogadó, mit fejtett ki a burkolásból.

A mód megváltoztatja, mi van a védelem belsejében. Alagút módban a védett anyag egy teljes belső IP-csomag, és egy új külső fejléc szállítja a végpontok között. Szállítási módban a védelem egy meglévő csomag felső rétegének hasznos terhét burkolja, így nincs második IP-fejléc, amelyet ki kellene bontani. Hogy melyik mód van használatban, konfigurációs tény, nem értelmezés kérdése. Olvassa ki az állapotbejegyzésből, ne következtesse egy diagramból.

Egyik mód sem rejti el a külső címzést, amelynek a csomagot kézbesítenie kell. Ez a tervezés tulajdonsága, nem hiányosság, és ezért egy közbenső megfigyelő továbbra is látja, melyik két cím beszél, akkor is, ha a hasznos teher átlátszatlan.

Első lépés: olvassa el az állapotot, majd a szabályzatot

Az állapotbejegyzések tartják a kulcsokat és a számlálókat; a szabályzatbejegyzések tartják a szelektorokat, amelyek eldöntik, mi használhatja őket. Linuxon mindkettő látható csomagrögzítés nélkül, és ebben a sorrendben olvasva a két kérdés külön marad.

ip xfrm state
ip xfrm policy

Az állapotkimenetben ellenőrizze a társítás forrását és célját, a módot, és hogy a burkolás mutat-e UDP-portokat. Azok a portok azt jelentik, hogy NAT-áthaladás van használatban, ami megváltoztatja, mit kell engedélyeznie egy közbenső tűzfalmak, de nem azt, mely szelektorok vagy kulcsok érvényesek a végpontokon.

Ezután olvassa el a szabályzat szelektorait. Az a szelektor, amely szűkebb előtagot nevez meg, mint a tesztelt forgalom, a leggyakoribb oka annak, hogy egy működő alagút úgy tűnik, figyelmen kívül hagy egy folyamot, és a rossz protokollhoz tartozó szelektor ugyanazt a csendet adja.

A gyártói eszközök ugyanazt az információt barátságosabb formában nyomtatják. ipsec statusall a strongSwanon felsorolja a gyermektársításokat, azok szelektorait és bájt-számlálóit, ami gyakran gyorsabb, mint a nyers xfrm-kimenet olvasása, ha már tudja, melyik gyermeket nézze.

Második lépés: bizonyítsa, hogy egy folyam mozgatja a számlálókat

A számlálóknak csak akkor van értelmük, ha tudja, minek kellett volna mozgatnia őket, ezért válasszon olyan forrást és célt, amelyet a szelektor biztosan lefed, és küldjön egy ártalmatlan kérést. Ezután olvassa el újra ugyanazt a bejegyzést, és hasonlítsa össze.

ip -s xfrm state
tcpdump -ni any esp

Két leolvasás kétféle történetet mesél. A kimenő oldalon növekvő, de a bejövő oldalon soha nem növekvő csomagok továbbítási vagy visszaúti problémára utalnak, nem kulcsproblémára, mert a csomagot beburkolták és elment. Ha egyetlen számláló sem mozdul, a forgalom soha nem egyezett a szabályzattal, és a szelektor az a hely, ahol keresni kell.

Az ugyanezen lépésben készült rögzítés megerősíti a burkolást a vezetéken, beleértve azt is, hogy a külső csomagok ESP-k vagy UDP-be burkolt ESP-k. Azt is megmutatja, mely címek szállították valójában a folyamot, és ezek néha eltérnek a konfigurációban látottaktól.

Harmadik lépés: változtasson egy dolgot, és tartson meg egy visszaállítást

Jegyezze fel a társítás forrását, célját, módját, szelektorait és számlálóit, mielőtt bármit szerkesztene. Ha egy változtatás ront a helyzeten, éppen ez a feljegyzés teszi lehetővé az előző állapot helyreállítását ahelyett, hogy egy működő konfigurációt találgatásból építene újra. A feljegyzés egy percet vesz igénybe, és később egy órát takarít meg. Ez az egyetlen olyan dokumentum is, amely túléli a változtatást végző embert.

Változtasson meg egy szelektort vagy egy paramétert, töltse újra, és ismételje meg a második lépést ugyanazon a folyamon. Egy társítás törlése minden őt használó folyamot lerombol, ezért a célzott szerkesztés és a gyermek újratöltése szinte mindig jobb, mint az állapot kiürítése, hogy lássa, mi történik.

A szelektor szerkesztésének visszaállítása az előző szabályzat helyreállítása és újratöltése, azzal a fenntartással, hogy a partnernek egyező változtatásra lehet szüksége, ha a szelektorról tárgyalnak, és nem helyi. Írja fel ezt a függőséget, amíg friss, mert egy félig helyreállított párt nehezebb átgondolni, mint bármelyik végállapotot.

Végül tartsa őszintén a hatókört. Egy folyó ESP-társítás bizonyítja, hogy a két átjáró védi és kézbesíti a szegmenst, és semmit nem mond arról, hogy a felette lévő alkalmazás hitelesíti-e a felhasználóit, vagy titkosítja-e, amit tárol. Ezek külön kontrollok külön bizonyítékokkal, és a runbook csak akkor kész, ha a következő ember a jegyzetekből meg tudja ismételni.