Što ulazi u IPsec prijedlog? IKE i ESP polja

IKE počinje, oba partnera oglašavaju AES, a tunel i dalje pada uz NO_PROPOSAL_CHOSEN. Zapis imenuje prijedlog, ali ne i polje koje se nije poklopilo. Prijedlog je jedna cjelovita ponuda, a jedno nekompatibilno polje poništava cijelu kombinaciju, a ne samo taj redak. Čitanje prijedloga kao vreće neovisnih izbora algoritama uobičajen je razlog zašto nepodudaranje ostaje nevidljivo.

Dva pregovora s odvojenim popisima prijedloga

IKEv2 gradi dvije sigurnosne asocijacije. Prva je IKE SA, koja štiti samu razmjenu upravljanja, a druga je CHILD SA, koja prenosi vaš promet kroz ESP. Svaka ima vlastiti popis prijedloga, a partner može prihvatiti jednu i odbiti drugu.

Ta podjela objašnjava čestu zbrku: ispravna IKE SA dokazuje samo da su se algoritmi upravljačkog kanala poklopili. Ako prijedlog CHILD ne uspije, tunel nikada ne prenese nijedan paket, iako je prva faza završena i zapisi na vrhu izgledaju zdravo.

Redoslijed unutar svakog popisa također je važan. Odgovarač bira iz inicijatorovih poredanih ponuda, pa premještanje široko kompatibilnog unosa iznad uskog mijenja koji će se skup instalirati, bez promjene ijednog imena algoritma. Fiksirajte taj redoslijed u konfiguraciji umjesto da se oslanjate na zadane vrijednosti. Stalan redoslijed čini i usporedbu zapisa između lokacija smislenom.

Koja polja pripadaju kojem prijedlogu

Skup polja je malen, ali nije isti u oba pregovora. Čitajte tablicu red po red, jer polje u jednom stupcu može izostati u drugom. Sintaksa se razlikuje po implementaciji; strongSwan dokumentacija o prijedlozima je jedan konkretan izvor.

Polje šifriranja imenuje šifru i, u većini sintaksi, duljinu ključa. Polje integriteta imenuje hash koji se koristi za autentifikaciju šifriranog teksta, a PRF imenuje funkciju koja izvodi ključni materijal za IKE SA. DH grupa uspostavlja novi zajednički tajni materijal, zbog čega se pojavljuje na obje strane, ali u različite svrhe.

Prošireni redni brojevi pripadaju samo podatkovnom putu. Oni proširuju prostor rednih brojeva i pregovaraju se kao dio CHILD prijedloga, pa nepodudaranje tamo odbija CHILD ponudu, dok IKE SA ostaje netaknut.

Kako se odabire jedna cjelovita ponuda

Svaki prijedlog je skup, a odgovarač traži skup u kojem je svako obvezno polje prihvatljivo. Dva popisa mogu oba sadržavati AES i SHA-256 i ipak nemati kompatibilan unos, jer se duljina ključa, PRF ili DH grupa razlikuju. Usporedba se obavlja po prijedlogu, a ne po algoritmu.

Kada se ništa ne poklopi, odgovarač šalje NO_PROPOSAL_CHOSEN s tipom SA koji nije uspio. Pročitajte na koji se popis prijedloga odnosi obavijest prije nego što uredite konfiguraciju; mijenjanje ESP algoritama kada je IKE prijedlog odbijen troši ciklus otklanjanja pogrešaka.

Ponašanje pri odabiru vrijedi znati kada podešavate profil. Neke implementacije preferiraju inicijatorov redoslijed, druge preslažu po lokalnoj politici, pa skup koji radi između dva dobavljača može nestati kada obrnete koju stranu pokreće vezu.

AEAD uklanja polje umjesto da ga dodaje

AES-GCM i ChaCha20-Poly1305 autentificiraju i šifriraju u jednoj operaciji. Kada se bilo koji od njih odabere za ESP, algoritam integriteta se ne pregovara odvojeno, jer AEAD konstrukcija već ga pokriva. Zato je prijedlog koji spaja AES-GCM sa SHA-256 u najboljem slučaju suvišan, a u najgorem odbijen.

PRF je i dalje odvojen na IKE strani, jer izvodi ključeve za upravljački kanal umjesto da štiti korisni teret. Zato IKE prijedlog može legitimno kombinirati AEAD šifru s PRF-om i DH grupom, dok odgovarajući ESP prijedlog navodi samo AEAD šifru i opcionalnu PFS grupu.

Duljina ključa dio je tokena za šifriranje, pa su AES-128-GCM i AES-256-GCM različite ponude. Profil kopiran iz vodiča koji je pretpostavljao 256-bit ključeve neće se poklopiti s krajnjom točkom konfiguriranom za 128-bit, iako oba retka kažu AES-GCM. Dva partnera mogu se složiti o obitelji šifri i ipak odbiti jedan drugoga zbog broja nakon crtice.

Čitajte instaliranu SA, a ne konfiguraciju

Konfigurirani popis prijedloga je ponuda; instalirana SA je rezultat. Na strongSwanu i Linux kernelu oba su prikaza dostupna:

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

swanctl --list-sas ispisuje pregovarane algoritme po SA, uključujući i to koristi li CHILD AEAD. ip xfrm state pokazuje što je kernel stvarno instalirao, i to je mjesto gdje potvrđujete da obnova ključa nije pala na drugačiji skup od onog koji ste dokumentirali.

Sačuvajte taj izlaz uz konfiguraciju nakon popravka. Kada ažuriranje klijenta promijeni zadane vrijednosti, zabilježeni skup daje vam osnovu za usporedbu, a usporedba pokazuje na polje koje se pomaknulo umjesto da istragu počinje iznova.