IKEv2 NO_PROPOSAL_CHOSEN: en quina fase es va rebutjar el conjunt?

NO_PROPOSAL_CHOSEN en un registre envia la gent a la clau prèviament compartida, i l'error sobreviu al canvi. Mai no va ser un problema de credencials: el parell va rebutjar cada proposta oferta per a aquell intercanvi, cosa que parla d'algorismes i no d'identitat. La primera pregunta útil no és quin algorisme editar, sinó quin intercanvi es va rebutjar. Responeu-ho abans de comparar res. Després compareu el conjunt complet ofert amb el conjunt complet que el parell permet.

Primer: quin intercanvi es va rebutjar

IKEv2 negocia dos tipus d'associació. L'IKE SA protegeix la negociació mateixa, i el CHILD SA protegeix el trànsit. Cada un té el seu propi conjunt de propostes, i cada un pot fallar amb la mateixa notificació. Un rebuig durant la negociació IKE inicial i un rebuig durant la negociació CHILD necessiten correccions diferents, i el registre normalment anomena l'intercanvi una línia o dues per sobre de la notificació. Llegiu aquestes dues línies juntes, o editareu la llista de propostes equivocada.

La notificació sola no identifica l'intercanvi. La línia de sobre seu anomena l'SA que es negocia, i aquest nom assenyala la llista de propostes que cal inspeccionar.

Compareu conjunts complets, no paraules clau soltes

Una proposta és una combinació: algorisme de xifratge, integritat o AEAD, grup d'intercanvi de claus i qualsevol funció pseudoaleatòria. Comparar només el nom del xifratge és l'error habitual, perquè dos parells poden coincidir en AES-256 i encara discrepar en SHA-1 versus SHA-256. Escriviu els conjunts ofert i permès costat per costat a l'etapa fallida, i després busqueu la intersecció buida.

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

Comproveu també que les dues implementacions admetin el que heu configurat. Un nom copiat d'una altra plataforma pot semblar sintàcticament familiar mentre que el connector o la implementació falta del tot.

El conjunt IKE i el conjunt ESP són objectes diferents

Editar la proposta IKE no repararà una proposta CHILD rebutjada, i el contrari també és cert. A strongSwan són paràmetres separats, aproximadament proposals = aes256-sha256-modp2048 per a l'IKE SA i una llista ESP separada per al CHILD SA. Canvieu la llista que correspon a l'intercanvi fallit i torneu a llegir el registre en lloc de suposar que la correcció ha funcionat.

Per al CHILD SA, el paràmetre rellevant és la llista de propostes ESP, no la de IKE. Copiar-hi la línia IKE produeix una configuració que s'analitza i negocia l'objecte equivocat.

Un túnel que funciona i falla en la renegociació

Si el túnel va funcionar una hora i després va fallar, la negociació inicial no és el problema. Una renegociació pot exercitar condicions diferents: un grup d'intercanvi de claus diferent després del primer intercanvi, una discrepància de lifetime entre parells o una política de responedor canviada. Guardeu la marca de temps de renovació i els identificadors d'associació dels dos costats. Aquest patró necessita una comparació de propostes en la renovació, no un temps d'espera més llarg. Canviar el temps d'espera amaga el símptoma i deixa la discrepància al lloc.

ipsec statusall mostra cada associació i els algorismes realment negociats. Aquesta sortida és la manera més ràpida de confirmar quina llista es va fer servir, i separa un error de configuració d'un túnel antic que mai no es va renegociar.

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

Triar una intersecció i després confirmar les dues fases

Feu que l'administrador triï una intersecció moderna documentada que els dos parells admetin, i anoteu-la. No resolgueu l'error habilitant tots els algorismes antics ni desactivant la verificació d'identitat, perquè cap de les dues coses es dedueix d'un rebuig. Després del canvi, establiu una connexió nova i forceu una renegociació. La primera connexió sola no demostra que el camí de renovació funcioni.

Guardeu la combinació acceptada amb les versions del microprogramari. Si el següent error tracta de selectors de trànsit, tracteu-lo per separat, perquè l'acord sobre criptografia no diu res sobre quines subxarxes protegeix el túnel. La documentació de propostes de strongSwan cobreix la sintaxi de les dues llistes.