Ce intră într-o propunere IPsec? Câmpuri IKE și ESP

IKE pornește, ambele părți anunță AES, iar tunelul eșuează totuși cu NO_PROPOSAL_CHOSEN. Jurnalul numește propunerea, dar nu câmpul care nu s-a potrivit. O propunere este o ofertă completă, iar un singur câmp incompatibil invalidează întreaga combinație, nu doar acea linie. Citirea ei ca un sac de alegeri independente de algoritmi este motivul obișnuit pentru care nepotrivirea rămâne invizibilă.

Două negocieri cu liste de propuneri separate

IKEv2 construiește două asocieri de securitate. Prima este IKE SA, care protejează schimbul de control în sine, iar a doua este CHILD SA, care transportă traficul prin ESP. Fiecare are propria listă de propuneri, iar o parte poate accepta una și respinge cealaltă.

Această separare explică o confuzie obișnuită: o IKE SA funcțională dovedește doar că algoritmii canalului de control s-au potrivit. Dacă propunerea CHILD eșuează, tunelul nu transportă niciun pachet, chiar dacă prima fază s-a încheiat și jurnalele par sănătoase în partea de sus.

Și ordinea din interiorul fiecărei liste contează. Responderul alege dintre ofertele ordonate ale inițiatorului, așa că mutarea unei intrări larg compatibile deasupra uneia înguste schimbă ce set se instalează fără a schimba vreun nume de algoritm. Fixați acea ordine în configurație în loc să vă bazați pe valorile implicite. O ordine stabilă face și comparația jurnalelor între locații semnificativă.

Ce câmpuri aparțin cărei propuneri

Setul de câmpuri este mic, dar nu este identic în cele două negocieri. Citiți tabelul rând cu rând, pentru că un câmp dintr-o coloană poate lipsi din cealaltă. Sintaxa diferă în funcție de implementare; documentația propunerilor strongSwan este o referință concretă.

Câmpul de criptare numește cifrul și, în majoritatea sintaxelor, lungimea cheii. Câmpul de integritate numește hash-ul folosit pentru autentificarea textului cifrat, iar PRF numește funcția care derivă material de cheie pentru IKE SA. Grupul DH stabilește material secret comun nou, motiv pentru care apare pe ambele părți, dar cu scopuri diferite.

Numerele de secvență extinse aparțin doar căii de date. Extind spațiul de secvență și sunt negociate ca parte a propunerii CHILD, așa că o nepotrivire acolo respinge o ofertă CHILD lăsând IKE SA neatinsă.

Cum este selectată o ofertă completă

Fiecare propunere este un set, iar responderul caută un set în care fiecare câmp obligatoriu este acceptabil. Două liste pot conține ambele AES și SHA-256 și totuși să nu aibă nicio intrare compatibilă, pentru că lungimea cheii, PRF-ul sau grupul DH diferă. Comparația se face pe propunere, nu pe algoritm.

Când nimic nu se potrivește, responderul trimite NO_PROPOSAL_CHOSEN cu tipul de SA care a eșuat. Citiți la ce listă de propuneri se referă notificarea înainte de a edita configurația; schimbarea algoritmilor ESP când propunerea IKE a fost respinsă risipește un ciclu de depanare.

Merită să cunoașteți comportamentul de selecție când reglați un profil. Unele implementări preferă ordinea inițiatorului, altele reordonează după politica locală, așa că un set care funcționează între doi furnizori poate dispărea când inversați partea care începe conexiunea.

AEAD elimină un câmp în loc să adauge unul

AES-GCM și ChaCha20-Poly1305 autentifică și criptează într-o singură operație. Când unul dintre ele este selectat pentru ESP, algoritmul de integritate nu este negociat separat, pentru că structura AEAD îl acoperă deja. Așadar, o propunere care asociază AES-GCM cu SHA-256 este redundantă în cel mai bun caz și respinsă în cel mai rău.

PRF-ul rămâne separat pe partea IKE, deoarece derivă chei pentru canalul de control în loc să protejeze încărcăturile utile. De aceea o propunere IKE poate combina legitim un cifru AEAD cu un PRF și un grup DH, în timp ce propunerea ESP corespunzătoare listează doar cifrul AEAD și grupul PFS opțional.

Lungimea cheii face parte din tokenul de criptare, deci AES-128-GCM și AES-256-GCM sunt oferte diferite. Un profil copiat dintr-un ghid care presupunea chei de 256-bit nu se va potrivi cu un punct final configurat pentru 128-bit, chiar dacă ambele linii spun AES-GCM. Două părți se pot înțelege asupra familiei de cifruri și totuși se pot respinge reciproc din cauza numărului de după cratimă.

Citiți SA instalată, nu configurația

Lista de propuneri configurată este o ofertă; SA instalată este rezultatul. Pe strongSwan și pe un kernel Linux, ambele vizualizări sunt disponibile:

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

swanctl --list-sas afișează algoritmii negociați pentru fiecare SA, inclusiv dacă CHILD folosește AEAD. ip xfrm state arată ce a instalat de fapt kernelul, și acolo se confirmă că o reînnoire de chei nu a recăzut pe un set diferit de cel documentat.

Păstrați acea ieșire lângă configurație după o corectare. Când o actualizare a clientului își schimbă valorile implicite, setul înregistrat vă oferă o linie de bază pentru comparație, iar comparația indică câmpul care s-a mutat în loc să reia investigația de la început.