Prečo váš tunel IPsec funguje až do prvého obnovenia kľúča CHILD SA

Tunel sa zdvihol, ping odpovedal a všetci podpísali. O štyri hodiny neskôr relácia padne, strany zalogujú chybu v návrhu alebo vo výmene kľúčov, a prvý predpoklad je, že sa v sieti niečo zmenilo. Nič sa nezmenilo. Tunel, ktorý prenáša prevádzku, preukázal, že sa obe strany zhodujú v tom, ako sa autentizovať a ako chrániť prvú podriadenú asociáciu, a nepreukázal nič o výmene kľúčov, ktorú budú vyžadovať pri obnovení. Nesúlad sedí v medzere medzi týmito dvoma udalosťami.

Pripojenie neznamená, že nastavenia PFS sedia

Pri IKEv2 vzniká prvá podriadená asociácia počas autentizačnej výmeny a jej kľúče sa odvodzujú z materiálu, ktorý asociácia IKE už vytvorila. Pre túto podriadenú asociáciu neprebieha samostatná výmena Diffie-Hellman, takže zásada, ktorá ju vyžaduje pri obnovení, sa pri zdvihnutí nepreveruje.

Obnovenie je iná výmena. Keď sa obnovuje kľúč podriadenej asociácie, strany môžu vykonať novú výmenu kľúčov so skupinou uvedenou v ich návrhoch, a to je prvý okamih, keď sa nastavenia skupiny porovnávajú. Dve strany, ktoré sa nezhodujú, sa teda môžu autentizovať, nainštalovať podriadenú asociáciu a prepustiť prevádzku, a potom zlyhať pri obnovení.

Kde sa nesúlad skrýva v reťazci návrhu

V strongSwane sa skupina pripája k návrhu podriadenej asociácie, a preto reťazec ako aes256gcm16-prfsha256-ecp256 vyzerá ako voľba šifrovania, ale nesie aj požiadavku na výmenu kľúčov. Strana, ktorá ponúka len aes256gcm16-prfsha256 nemá takúto požiadavku, a oba zoznamy sa pretínajú v šifrovaní, ale rozchádzajú sa vo výmene.

Čítajte návrh podriadenej asociácie a návrh IKE ako oddelené zoznamy. Skupina, ktorá sa objaví v zozname IKE, nehovorí nič o podriadenom zozname, a upravovať jeden pri čítaní druhého je obvyklý spôsob, ako to prehliadnuť.

Čítajte zlyhanie, nie súbor, ktorý ste upravili

Nájdite notify, ktorý ukončil výmenu. Obnovenie kľúča podriadenej asociácie, ktoré vráti „žiadny prijateľný návrh“, ukazuje na zoznamy návrhov; žiadosť o obnovenie, ktorá nikdy nedostane odpoveď, ukazuje na cestu alebo na stranu, ktorá prestala počúvať. Tieto dva prípady chcú rôzne opravy a formulácia riadku v logu ich oddeľuje.

Potvrďte bežiacu konfiguráciu, nie tú na disku. Súbor uložený, ale nenačítaný, alebo spojenie znova načítané z iného include, vytvoria nesúlad, ktorý žiadna úprava viditeľného súboru neopraví.

Tri udalosti, ktorým všetci hovoria obnovenie kľúča

Obnovenie kľúča asociácie IKE, opätovná autentizácia IKE a obnovenie kľúča podriadenej asociácie sú samostatné operácie so samostatnými pravidlami návrhov. Zlyhanie hlásené pri jednej z nich nehovorí priamo nič o ostatných, a log, ktorý ich mieša, sa číta ako jediná opakujúca sa porucha, hoci sú tri.

Všimnite si, ktorú udalosť strana pomenuje, a potom skontrolujte návrhy len pre túto udalosť. Zmeňte jeden zoznam, znova načítajte a znova vynúťte tú istú udalosť. Ak log pomenuje opätovnú autentizáciu, čítať sa má návrh IKE. Ak pomenuje obnovenie kľúča podriadenej asociácie, dôležitú skupinu nesie návrh podriadenej asociácie.

Vypnutie obnovovania nie je oprava

Nastavenie času obnovenia kľúča na nulu potláča výmenu, ktorá zlyháva, a tunel potom prežije, kým sa nerozpojí alebo kým sa strana nereštartuje. Kúpili ste dlhšie trvajúci kľúč a nesúlad, ktorý vás znova stretne pri migrácii, audite alebo aktualizácii od dodávateľa. To isté platí pre životnosti natiahnuté ďaleko za zásadu, ktorú očakáva druhá strana.

Namiesto toho zosúlaďte návrhy. Vyberte skupinu, ktorú implementujú obe strany, dajte ju do návrhu podriadenej asociácie na oboch koncoch a udržte zásadu obnovovania v rozsahu, ktorý organizácia skutočne vyžaduje.

Dokážte to výmenou, ktorá zlyhala

Skráťte čas obnovenia kľúča podriadenej asociácie v servisnom okne, aby udalosť prišla v minútach, nie v hodinách, alebo spustite ručné obnovenie. Potom sledujte úspešné obnovenie a potvrďte, že prevádzka ním ďalej prechádza, pretože nový handshake, ktorý nainštaluje podriadenú asociáciu, ale zahodí tok aplikácie je iná porucha.

Potom obnovte normálnu životnosť a uchovajte oba záznamy udalostí, ten neúspešný aj ten úspešný. Dôkaz, ktorý chcete, je, že spojenie prežije vlastný životný cyklus, nie že prežilo ping.