IKEv2 NO_PROPOSAL_CHOSEN: que etapa rexeitou o conxunto?

NO_PROPOSAL_CHOSEN nun rexistro envía a xente á clave precompartida, e o erro sobrevive ao cambio. Nunca foi un problema de credenciais: o par rexeitou cada proposta ofrecida para ese intercambio, o que é unha afirmación sobre algoritmos e non sobre identidade. A primeira pregunta útil non é que algoritmo editar, senón que intercambio se rexeitou. Responda iso antes de comparar nada. Despois compare o conxunto completo ofrecido co conxunto completo que o par permite.

Primeiro: que intercambio se rexeitou

IKEv2 negocia dous tipos de asociación. A IKE SA protexe a propia negociación e a CHILD SA protexe o tráfico. Cada unha ten o seu propio conxunto de propostas, e cada unha pode fallar coa mesma notificación. Un rexeitamento durante a negociación IKE inicial e un rexeitamento durante a negociación CHILD necesitan correccións distintas, e o rexistro adoita nomear o intercambio unha ou dúas liñas por riba do aviso. Lea esas dúas liñas xuntas, ou editará a lista de propostas equivocada.

A notificación por si soa non identifica o intercambio. A liña superior nomea a SA que se está negociando, e ese nome apunta á lista de propostas que hai que inspeccionar.

Compare conxuntos completos, non palabras clave soltas

Unha proposta é unha combinación: algoritmo de cifrado, integridade ou AEAD, grupo de intercambio de claves e calquera función pseudoaleatoria. Comparar só o nome do cifrado é o erro habitual, porque dous pares poden coincidir en AES-256 e seguir discrepando en SHA-1 fronte a SHA-256. Escriba os conxuntos ofrecido e permitido un ao lado do outro na etapa fallida e despois busque a intersección baleira.

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

Comprobe tamén que ambas implementacións admiten o que configurou. Un nome copiado doutra plataforma pode parecer sintacticamente familiar mentres que o complemento ou a implementación falta por completo.

O conxunto IKE e o conxunto ESP son obxectos distintos

Editar a proposta IKE non reparará unha proposta CHILD rexeitada, e o contrario tamén é certo. En strongSwan son axustes separados, aproximadamente proposals = aes256-sha256-modp2048 para a IKE SA e unha lista ESP aparte para a CHILD SA. Cambie a lista que corresponde ao intercambio fallido e logo volva ler o rexistro en lugar de supor que a corrección funcionou.

Para a CHILD SA, o axuste relevante é a lista de propostas ESP, non a de IKE. Copiar a liña IKE nela produce unha configuración que se analiza e negocia o obxecto equivocado.

Un túnel que funciona e falla ao renovar a clave

Se o túnel funcionou durante unha hora e logo fallou, a negociación inicial non é o problema. Unha renovación de clave pode exercitar condicións distintas: un grupo de intercambio de claves diferente tras o primeiro intercambio, unha discrepancia de lifetime entre pares ou unha política de respondedor cambiada. Garde a marca de tempo de renovación e os identificadores de asociación de ambos os dous lados. Ese patrón necesita unha comparación de propostas na renovación, non un tempo de espera máis longo. Cambiar o tempo de espera oculta o síntoma e deixa a discrepancia no seu sitio.

ipsec statusall mostra cada asociación e os algoritmos realmente negociados. Esa saída é a forma máis rápida de confirmar que lista se usou, e separa un erro de configuración dun túnel obsoleto que nunca se renegociou.

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

Escolla unha intersección e logo confirme ambas as dúas fases

Faga que o administrador escolla unha intersección moderna documentada que ambos os pares admitan, e anótea. Non resolva o erro habilitando todos os algoritmos herdados nin desactivando a verificación de identidade, porque ningunha das dúas cousas se deduce dun rexeitamento. Tras o cambio, estableza unha conexión nova e logo force unha renovación de clave. A primeira conexión por si soa non demostra que a ruta de renovación funcione.

Conserve a combinación aceptada xunto coas versións de firmware. Se o seguinte erro trata de selectores de tráfico, tráteo por separado, xa que o acordo sobre criptografía non di nada sobre que subredes protexe o túnel. A documentación de propostas de strongSwan cobre a sintaxe de ambas as dúas listas.