IKEv2 NO_PROPOSAL_CHOSEN: ce etapă a respins suita?

NO_PROPOSAL_CHOSEN într-un jurnal trimite oamenii la cheia prepartajată, iar eroarea supraviețuiește schimbării. Nu a fost niciodată o problemă de credențiale: partenerul a respins fiecare propunere oferită pentru acel schimb, ceea ce este o afirmație despre algoritmi și nu despre identitate. Prima întrebare utilă nu este ce algoritm să editați, ci care schimb a fost respins. Răspundeți la asta înainte de a compara ceva. Apoi comparați suita completă oferită cu suita completă pe care partenerul o permite.

Mai întâi: care schimb a fost respins

IKEv2 negociază două tipuri de asociere. IKE SA protejează negocierea în sine, iar CHILD SA protejează traficul. Fiecare are propriul set de propuneri și fiecare poate eșua cu aceeași notificare. O respingere în timpul negocierii IKE inițiale și o respingere în timpul negocierii CHILD necesită corecții diferite, iar jurnalul numește de obicei schimbul cu o linie sau două deasupra notificării. Citiți acele două linii împreună, altfel veți edita lista de propuneri greșită.

Notificarea singură nu identifică schimbul. Linia de deasupra numește SA care se negociază, iar acel nume indică lista de propuneri de inspectat.

Comparați suite complete, nu cuvinte-cheie izolate

O propunere este o combinație: algoritm de criptare, integritate sau AEAD, grup de schimb de chei și orice funcție pseudoaleatoare. Compararea doar a numelui criptării este greșeala obișnuită, deoarece doi parteneri pot fi de acord asupra AES-256 și totuși să nu fie de acord asupra SHA-1 față de SHA-256. Scrieți suitele oferită și permisă una lângă alta la etapa eșuată, apoi căutați intersecția vidă.

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

Verificați și că ambele implementări acceptă ceea ce ați configurat. Un nume copiat de pe altă platformă poate părea familiar sintactic în timp ce pluginul sau implementarea lipsește complet.

Suita IKE și suita ESP sunt obiecte diferite

Editarea propunerii IKE nu va repara o propunere CHILD respinsă, și invers este la fel de adevărat. În strongSwan acestea sunt setări separate, aproximativ proposals = aes256-sha256-modp2048 pentru IKE SA și o listă ESP separată pentru CHILD SA. Schimbați lista care corespunde schimbului eșuat, apoi recitiți jurnalul în loc să presupuneți că remedierea a funcționat.

Pentru CHILD SA, setarea relevantă este lista de propuneri ESP, nu lista IKE. Copierea liniei IKE în ea produce o configurație care este analizată dar negociază obiectul greșit.

Un tunel funcțional care eșuează la reînnoirea cheii

Dacă tunelul a funcționat o oră și apoi a eșuat, negocierea inițială nu este problema. O reînnoire de cheie poate testa alte condiții: un grup de schimb de chei diferit după primul schimb, o nepotrivire de durată de viață între parteneri sau o politică de responder modificată. Păstrați marcajul de timp al reînnoirii și identificatorii de asociere de pe ambele părți. Acel model necesită o comparație de propuneri la reînnoire, nu un timeout mai lung. Schimbarea timeout-ului ascunde simptomul și lasă nepotrivirea pe loc.

ipsec statusall afișează fiecare asociere și algoritmii negociați efectiv. Acea ieșire este cea mai rapidă cale de a confirma ce listă a fost folosită și separă o eroare de configurare de un tunel învechit care nu a fost niciodată renegociat.

ipsec statusall | grep -E "IKE:|ESP:"

Alegeți o intersecție, apoi confirmați ambele faze

Rugați administratorul să aleagă o intersecție modernă documentată pe care ambii parteneri o acceptă și să o noteze. Nu rezolvați eroarea activând toți algoritmii vechi sau dezactivând verificarea identității, pentru că niciuna nu decurge dintr-o respingere. După modificare, stabiliți o conexiune nouă și apoi forțați o reînnoire de cheie. Doar prima conexiune nu dovedește că calea de reînnoire funcționează.

Păstrați combinația acceptată împreună cu versiunile de firmware. Dacă următoarea eroare privește selectorii de trafic, tratați-o separat, deoarece acordul privind criptografia nu spune nimic despre ce subrețele protejează tunelul. documentația de propuneri a strongSwan acoperă sintaxa ambelor liste.