IKEv2 NO_PROPOSAL_CHOSEN : quelle étape a rejeté la suite ?

NO_PROPOSAL_CHOSEN dans un journal envoie les gens vers la clé pré-partagée, et l'erreur survit au changement. Ce n'était jamais un problème d'identifiants : le pair a rejeté chaque proposition offerte pour cet échange, ce qui est une affirmation sur les algorithmes et non sur l'identité. La première question utile n'est pas quel algorithme modifier, mais quel échange a été rejeté. Répondez-y avant de comparer quoi que ce soit. Comparez ensuite la suite complète offerte avec la suite complète que le pair autorise.

D'abord : quel échange a été rejeté

IKEv2 négocie deux types d'association. L'IKE SA protège la négociation elle-même, et la CHILD SA protège le trafic. Chacune a son propre ensemble de propositions, et chacune peut échouer avec la même notification. Un rejet lors de la négociation IKE initiale et un rejet lors de la négociation CHILD exigent des correctifs différents, et le journal nomme généralement l'échange une ou deux lignes au-dessus de la notification. Lisez ces deux lignes ensemble, sinon vous modifierez la mauvaise liste de propositions.

La notification seule n'identifie pas l'échange. La ligne au-dessus nomme l'SA en cours de négociation, et ce nom désigne la liste de propositions à inspecter.

Comparez des suites complètes, pas des mots-clés isolés

Une proposition est une combinaison : algorithme de chiffrement, intégrité ou AEAD, groupe d'échange de clés et toute fonction pseudo-aléatoire. Comparer seulement le nom du chiffrement est l'erreur habituelle, car deux pairs peuvent s'accorder sur AES-256 et rester en désaccord sur SHA-1 face à SHA-256. Écrivez les suites offerte et autorisée côte à côte à l'étape qui a échoué, puis cherchez l'intersection vide.

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

Vérifiez aussi que les deux implémentations prennent en charge ce que vous avez configuré. Un nom copié depuis une autre plateforme peut sembler syntaxiquement familier alors que le greffon ou l'implémentation est totalement absent.

La suite IKE et la suite ESP sont des objets différents

Modifier la proposition IKE ne réparera pas une proposition CHILD rejetée, et l'inverse est vrai aussi. Dans strongSwan, ce sont des réglages distincts, environ proposals = aes256-sha256-modp2048 pour l'IKE SA et une liste ESP séparée pour la CHILD SA. Changez la liste qui correspond à l'échange échoué, puis relisez le journal au lieu de supposer que le correctif a fonctionné.

Pour la CHILD SA, le réglage pertinent est la liste de propositions ESP, pas celle d'IKE. Y copier la ligne IKE produit une configuration qui s'analyse et négocie le mauvais objet.

Un tunnel qui fonctionne et échoue au renouvellement de clé

Si le tunnel a tourné une heure puis a échoué, la négociation initiale n'est pas le problème. Un renouvellement de clé peut solliciter d'autres conditions : un groupe d'échange de clés différent après le premier échange, un décalage de durée de vie entre les pairs ou une politique de répondeur modifiée. Conservez l'horodatage de renouvellement et les identifiants d'association des deux côtés. Ce schéma exige une comparaison de propositions au renouvellement, pas un délai plus long. Un changement de délai masque le symptôme et laisse le désaccord en place.

ipsec statusall affiche chaque association et les algorithmes réellement négociés. Cette sortie est le moyen le plus rapide de confirmer quelle liste a été utilisée, et elle sépare une erreur de configuration d'un tunnel obsolète qui n'a jamais été renégocié.

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

Choisissez une intersection, puis confirmez les deux phases

Demandez à l'administrateur de choisir une intersection moderne documentée que les deux pairs prennent en charge, et de l'écrire. Ne résolvez pas l'erreur en activant tous les algorithmes hérités ni en désactivant la vérification d'identité, car ni l'un ni l'autre ne découle d'un rejet. Après le changement, établissez une nouvelle connexion puis forcez un renouvellement de clé. La première connexion seule ne prouve pas que le chemin de renouvellement fonctionne.

Conservez la combinaison acceptée avec les versions de firmware. Si l'erreur suivante concerne les sélecteurs de trafic, traitez-la séparément, car l'accord sur la cryptographie ne dit rien sur les sous-réseaux que le tunnel protège. La documentation des propositions de strongSwan couvre la syntaxe des deux listes.