Čo patrí do IPsec návrhu? Polia IKE a ESP

IKE začne, obe strany inzerujú AES, a tunel napriek tomu zlyhá s NO_PROPOSAL_CHOSEN. Záznam pomenuje návrh, ale nie pole, ktoré sa nezhodovalo. Návrh je jedna úplná ponuka a jedno nekompatibilné pole zneplatní celú kombináciu, nielen ten riadok. Čítanie návrhu ako vreca nezávislých volieb algoritmov je obvyklý dôvod, prečo nezhoda zostáva neviditeľná.

Dve vyjednávania s oddelenými zoznamami návrhov

IKEv2 stavia dve bezpečnostné asociácie. Prvá je IKE SA, ktorá chráni samotnú riadiacu výmenu, a druhá je CHILD SA, ktorá prenáša váš prenos cez ESP. Každá má vlastný zoznam návrhov a partner môže jednu prijať a druhú odmietnuť.

Toto rozdelenie vysvetľuje častý zmätok: funkčná IKE SA dokazuje len to, že algoritmy riadiaceho kanála si sadli. Ak návrh CHILD zlyhá, tunel nepreenesie ani jeden paket, hoci prvá fáza je dokončená a záznamy navrchu vyzerajú zdravo.

Poradie vnútri každého zoznamu tiež hrá rolu. Odpovedajúca strana vyberá z iniciátorových zoradených ponúk, takže presunutie široko kompatibilnej položky nad úzku zmení, ktorá sada sa nainštaluje, bez zmeny jediného názvu algoritmu. Zafixujte toto poradie v konfigurácii, namiesto spoliehania sa na predvolené hodnoty. Stabilné poradie robí aj porovnanie záznamov medzi lokalitami zmysluplným.

Ktoré polia patria ktorému návrhu

Sada polí je malá, ale v oboch vyjednávaniach nie je rovnaká. Čítajte tabuľku riadok po riadku, pretože pole v jednom stĺpci môže v druhom chýbať. Syntax sa líši podľa implementácie; dokumentácia návrhov strongSwan je jeden konkrétny odkaz.

Pole šifrovania pomenuje šifru a vo väčšine syntaxí aj dĺžku kľúča. Pole integrity pomenuje hash použitý na autentizáciu šifrovaného textu a PRF pomenuje funkciu, ktorá odvodzuje kľúčový materiál pre IKE SA. Skupina DH vytvára nový spoločný tajný materiál, a preto sa objavuje na oboch stranách, ale s rôznymi účelmi.

Rozšírené poradové čísla patria len dátovej ceste. Rozširujú priestor poradových čísel a vyjednávajú sa ako súčasť návrhu CHILD, takže nezhoda tam odmietne ponuku CHILD, pričom IKE SA zostane nedotknutá.

Ako sa vyberá jedna úplná ponuka

Každý návrh je sada a odpovedajúca strana hľadá sadu, v ktorej je každé povinné pole prijateľné. Dva zoznamy môžu oba obsahovať AES a SHA-256 a napriek tomu nemajú žiadnu kompatibilnú položku, pretože sa líši dĺžka kľúča, PRF alebo skupina DH. Porovnanie prebieha po návrhoch, nie po algoritmoch.

Keď nič nesedí, odpovedajúca strana pošle NO_PROPOSAL_CHOSEN s typom SA, ktorý zlyhal. Prečítajte si, na ktorý zoznam návrhov sa oznámenie vzťahuje, kým začnete upravovať konfiguráciu; zmena algoritmov ESP, keď bol návrh IKE odmietnutý, premrhá jeden ladiaci cyklus.

Správanie pri výbere stojí za to poznať, keď ladíte profil. Niektoré implementácie uprednostňujú poradie iniciátora, iné preskladávajú podľa miestnej politiky, takže sada, ktorá funguje medzi dvoma dodávateľmi, môže zmiznúť keď obrátite, ktorá strana spojenie iniciuje.

AEAD pole odoberá, namiesto toho aby ho pridával

AES-GCM a ChaCha20-Poly1305 autentizujú a šifrujú v jednej operácii. Keď je niektorý z nich vybraný pre ESP, algoritmus integrity sa nevyjednáva zvlášť, pretože konštrukcia AEAD ho už pokrýva. Preto je návrh, ktorý páruje AES-GCM s SHA-256, v najlepšom prípade nadbytočný a v najhoršom odmietnutý.

PRF zostáva na strane IKE oddelený, pretože odvodzuje kľúče pre riadiaci kanál, namiesto ochrany užitočného zaťaženia. Preto môže návrh IKE legitímne kombinovať AEAD šifru s PRF a skupinou DH, zatiaľ čo zodpovedajúci návrh ESP uvádza len AEAD šifru a voliteľnú skupinu PFS.

Dĺžka kľúča je súčasťou šifrovacieho tokenu, takže AES-128-GCM a AES-256-GCM sú rôzne ponuky. Profil skopírovaný z návodu, ktorý predpokladal 256-bit kľúče, sa nezhoduje s koncovým bodom nastaveným na 128-bit, aj keď oba riadky hovoria AES-GCM. Dvaja partneri sa môžu dohodnúť na rodine šifier a napriek tomu sa navzájom odmietnuť kvôli číslu za pomlčkou.

Čítajte nainštalovanú SA, nie konfiguráciu

Nakonfigurovaný zoznam návrhov je ponuka; nainštalovaná SA je výsledok. Na strongSwan a v jadre Linuxu sú dostupné oba pohľady:

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

swanctl --list-sas vypíše vyjednané algoritmy pre každú SA, vrátane toho, či CHILD používa AEAD. ip xfrm state ukazuje, čo jadro skutočne nainštalovalo, a to je miesto, kde potvrdíte, že obnova kľúčov nespadla na inú sadu, než ste zdokumentovali.

Uložte tento výstup vedľa konfigurácie po oprave. Keď aktualizácia klienta zmení predvolené hodnoty, zaznamenaná sada vám dá základňu na porovnanie a porovnanie ukáže na pole, ktoré sa posunulo, namiesto začínania vyšetrovania od začiatku.