Co obsahuje IPsec návrh? Pole IKE a ESP

IKE začne, oba partneři inzerují AES, a tunel přesto selže s NO_PROPOSAL_CHOSEN. Záznam pojmenuje návrh, ale ne pole, které se neshodovalo. Návrh je jedna úplná nabídka a jedno nekompatibilní pole zneplatní celou kombinaci, ne jen ten řádek. Čtení návrhu jako pytle nezávislých voleb algoritmů je obvyklý důvod, proč nesoulad zůstává neviditelný.

Dvě vyjednávání s oddělenými seznamy návrhů

IKEv2 staví dvě bezpečnostní asociace. První je IKE SA, která chrání samotnou řídicí výměnu, a druhá je CHILD SA, která přenáší váš provoz přes ESP. Každá má vlastní seznam návrhů a partner může jednu přijmout a druhou odmítnout.

Toto rozdělení vysvětluje časté zmatení: funkční IKE SA dokazuje jen to, že algoritmy řídicího kanálu si sedly. Pokud návrh CHILD selže, tunel nepřenese jediný paket, i když je první fáze dokončená a záznamy nahoře vypadají zdravě.

Pořadí uvnitř každého seznamu také hraje roli. Odpovídající strana vybírá z iniciátorových seřazených nabídek, takže přesunutí široce kompatibilní položky nad úzkou změní, která sada se nainstaluje, aniž by se změnil jediný název algoritmu. Zafixujte toto pořadí v konfiguraci, místo abyste spoléhali na výchozí hodnoty. Stabilní pořadí také dělá srovnání záznamů mezi lokalitami smysluplným.

Která pole patří kterému návrhu

Sada polí je malá, ale v obou vyjednáváních není stejná. Čtěte tabulku řádek po řádku, protože pole v jednom sloupci může v druhém chybět. Syntaxe se liší podle implementace; dokumentace návrhů strongSwan je jeden konkrétní odkaz.

Pole šifrování pojmenuje šifru a ve většině syntaxí i délku klíče. Pole integrity pojmenuje hash použitý k autentizaci šifrovaného textu a PRF pojmenuje funkci, která odvozuje klíčový materiál pro IKE SA. Skupina DH vytváří nový společný tajný materiál, a proto se objevuje na obou stranách, ale s různými účely.

Rozšířená pořadová čísla patří jen datové cestě. Rozšiřují prostor pořadových čísel a vyjednávají se jako součást návrhu CHILD, takže nesoulad tam odmítne nabídku CHILD, zatímco IKE SA zůstane nedotčena.

Jak se vybírá jedna úplná nabídka

Každý návrh je sada a odpovídající strana hledá sadu, ve které je každé povinné pole přijatelné. Dva seznamy mohou oba obsahovat AES a SHA-256 a přesto nemít kompatibilní položku, protože se liší délka klíče, PRF nebo skupina DH. Srovnání probíhá po návrzích, ne po algoritmech.

Když nic nesedí, odpovídající strana pošle NO_PROPOSAL_CHOSEN s typem SA, který selhal. Přečtěte si, na který seznam návrhů se oznámení vztahuje, než začnete upravovat konfiguraci; změna algoritmů ESP, když byl návrh IKE odmítnut, promarní jeden ladicí cyklus.

Chování při výběru stojí za to znát, když ladíte profil. Některé implementace preferují pořadí iniciátora, jiné přeskládají podle místní politiky, takže sada, která funguje mezi dvěma dodavateli, může zmizet když obrátíte, která strana spojení zahajuje.

AEAD pole odebírá, místo aby ho přidával

AES-GCM a ChaCha20-Poly1305 autentizují a šifrují v jedné operaci. Když je některý z nich vybrán pro ESP, algoritmus integrity se nevyjednává zvlášť, protože konstrukce AEAD ho už pokrývá. Návrh, který páruje AES-GCM s SHA-256, je proto v nejlepším případě nadbytečný a v nejhorším odmítnutý.

PRF zůstává na straně IKE oddělený, protože odvozuje klíče pro řídicí kanál, místo aby chránil užitečné zatížení. Proto může návrh IKE legitimně kombinovat AEAD šifru s PRF a skupinou DH, zatímco odpovídající návrh ESP uvádí jen AEAD šifru a volitelnou skupinu PFS.

Délka klíče je součástí šifrovacího tokenu, takže AES-128-GCM a AES-256-GCM jsou různé nabídky. Profil zkopírovaný z návodu, který předpokládal 256-bit klíče, se neshoduje s koncovým bodem nastaveným na 128-bit, i když oba řádky říkají AES-GCM. Dva partneři se mohou shodnout na rodině šifer a přesto se navzájem odmítnout kvůli číslu za pomlčkou.

Čtěte nainstalovanou SA, ne konfiguraci

Nakonfigurovaný seznam návrhů je nabídka; nainstalovaná SA je výsledek. Na strongSwan a v jádře Linuxu jsou dostupné oba pohledy:

sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policy

swanctl --list-sas vypíše vyjednané algoritmy pro každou SA, včetně toho, zda CHILD používá AEAD. ip xfrm state ukazuje, co jádro skutečně nainstalovalo, a to je místo, kde potvrdíte, že obnova klíčů nespadla na jinou sadu, než kterou jste zdokumentovali.

Uložte tento výstup vedle konfigurace po opravě. Když aktualizace klienta změní výchozí hodnoty, zaznamenaná sada vám dá základnu pro srovnání a srovnání ukáže na pole, které se posunulo, místo aby se vyšetřování začínalo od začátku.