Miért működik az IPsec-alagút az első CHILD SA kulcsmegújításig

Az alagút feljött, a ping válaszolt, és mindenki aláírt. Négy órával később a munkamenet leesik, a felek javaslat- vagy kulcscsere-hibát naplóznak, és az első feltevés az, hogy valami megváltozott a hálózaton. Semmi sem változott. A forgalmat átvivő alagút bizonyította, hogy a két fél egyetért abban, hogyan kell hitelesíteni és hogyan kell megvédeni az első gyermektársulást, és semmit nem bizonyított arról a kulcscseréről, amelyet a megújításkor követelni fognak. Az eltérés a két esemény közötti résben ül.

A csatlakozás nem jelenti azt, hogy a PFS-beállítások megegyeznek

IKEv2 esetén az első gyermektársulás a hitelesítési csere során jön létre, és a kulcsai abból az anyagból származnak, amelyet az IKE-társulás már előállított. Ehhez a gyermekhez nem történik külön Diffie-Hellman-csere, ezért a megújításkor ilyet előíró szabályzat nem kerül kipróbálásra a felépítéskor.

A megújítás más csere. Amikor egy gyermektársulás kulcsa megújul, a felek friss kulcscserét végezhetnek a javaslataikban megnevezett csoporttal, és ez az első pillanat, amikor a csoportbeállításokat összehasonlítják. Ezért két eltérő álláspontú fél hitelesíthet, telepíthet egy gyermektársulást és átvihet forgalmat, majd elbukhat a megújításkor.

Hol rejtőzik az eltérés a javaslat karakterláncában

A strongSwanban a csoport a gyermekjavaslathoz fűződik, ezért egy olyan karakterlánc, mint aes256gcm16-prfsha256-ecp256 titkosítási választásnak tűnik, de kulcscsere-követelményt is hordoz. Egy fél, amely csak aes256gcm16-prfsha256 kínál, nem rendelkezik ilyen követelménnyel, és a két lista a titkosításban találkozik, a cserében viszont eltér.

Olvassa a gyermekjavaslatot és az IKE-javaslatot külön listaként. Az IKE-listában megjelenő csoport semmit nem mond a gyermeklistáról, és az egyik szerkesztése a másik olvasása közben a szokásos módja annak, hogy ez elkerülje a figyelmet.

A hibát olvassa, ne a fájlt, amelyet szerkesztett

Keresse meg a cserét lezáró notify-t. Az a gyermekkulcs-megújítás, amely „nincs elfogadható javaslat” választ adja, a javaslatlistákra mutat; az a megújítási kérés, amely soha nem kap választ, az útvonalra vagy egy hallgatást abbahagyott félre mutat. Ez a kettő különböző javítást igényel, és a naplósor megfogalmazása választja el őket.

A futó konfigurációt erősítse meg, ne a lemezen lévőt. Egy mentett, de be nem töltött fájl, vagy egy másik include-ból újraolvasott kapcsolat olyan eltérést eredményez, amelyet a látható fájl semmilyen szerkesztése nem tud kijavítani.

Három esemény, amelyet mindenki kulcsmegújításnak nevez

Az IKE-társulás kulcsmegújítása, az IKE-újrahitelesítés és a gyermektársulás kulcsmegújítása külön műveletek, külön javaslatszabályokkal. Az egyiknél jelentett hiba semmit nem mond közvetlenül a többiről, és az ezeket összekeverő napló egyetlen visszatérő hibaként olvasható, holott három.

Jegyezze meg, melyik eseményt nevezi meg a fél, majd csak annak az eseménynek a javaslatait ellenőrizze. Módosítson egy listát, töltse újra, és kényszerítse ki ismét ugyanazt az eseményt. Ha a napló újrahitelesítést nevez meg, az IKE-javaslatot kell olvasni. Ha gyermekkulcs-megújítást nevez meg, a gyermekjavaslat hordozza a fontos csoportot.

A megújítás kikapcsolása nem javítás

A kulcsmegújítási idő nullára állítása elnyomja a meghiúsuló cserét, és az alagút aztán addig él, amíg le nem bontják vagy a fél újra nem indul. Amit vásárolt, az egy hosszabb életű kulcs és egy eltérés, amely áttelepítés, audit vagy szállítói frissítés során újra találkozni fog önnel. Ugyanez vonatkozik a másik fél által elvárt szabályzaton messze túlnyújtott élettartamokra.

Inkább hangolja össze a javaslatokat. Válasszon egy csoportot, amelyet mindkét fél megvalósít, tegye be mindkét végén a gyermekjavaslatba, és tartsa a megújítási szabályzatot abban a tartományban, amelyet a szervezet valóban megkövetel.

Bizonyítsa a meghiúsult cserével

Rövidítse le a gyermekkulcs-megújítási időt egy karbantartási ablakban, hogy az esemény órák helyett percek alatt megérkezzen, vagy indítson kézi gyermekkulcs-megújítást. Utána figyeljen egy sikeres megújítást, és erősítse meg, hogy a forgalom tovább halad rajta, mert egy olyan új kézfogás, amely gyermektársulást telepít, de elejti az alkalmazásfolyamot másik hiba.

Utána állítsa vissza a normál élettartamot, és őrizze meg mindkét eseményfeljegyzést, a meghiúsultat és a sikereset. A bizonyíték, amit akar, az, hogy a kapcsolat túléli a saját életciklusát, nem az, hogy túlélt egy pinget.