Que contient une proposition IPsec ? Champs IKE et ESP

IKE démarre, les deux pairs annoncent AES, et le tunnel échoue quand même avec NO_PROPOSAL_CHOSEN. Le journal nomme la proposition mais pas le champ qui n'a pas correspondu. Une proposition est une offre complète, et un seul champ incompatible invalide toute la combinaison plutôt que cette seule ligne. La lire comme un sac de choix d'algorithmes indépendants est la raison habituelle pour laquelle l'écart reste invisible.

Deux négociations avec des listes de propositions distinctes

IKEv2 construit deux associations de sécurité. La première est l'IKE SA, qui protège l'échange de contrôle lui-même, et la seconde est la CHILD SA, qui transporte votre trafic via ESP. Chacune a sa propre liste de propositions, et un pair peut accepter l'une et rejeter l'autre.

Cette séparation explique une confusion courante : une IKE SA fonctionnelle prouve seulement que les algorithmes du canal de contrôle correspondent. Si la proposition CHILD échoue, le tunnel ne transporte pas un seul paquet, même si la première phase est terminée et que les journaux semblent sains en haut.

L'ordre à l'intérieur de chaque liste compte aussi. Le répondeur choisit parmi les offres ordonnées de l'initiateur, donc déplacer une entrée largement compatible au-dessus d'une entrée étroite change la suite installée sans changer aucun nom d'algorithme. Fixez cet ordre dans la configuration plutôt que de vous fier aux valeurs par défaut. Un ordre stable rend aussi la comparaison des journaux entre sites pertinente.

Quels champs appartiennent à quelle proposition

L'ensemble des champs est petit, mais il n'est pas identique dans les deux négociations. Lisez le tableau ligne par ligne, car un champ d'une colonne peut manquer dans l'autre. La syntaxe varie selon l'implémentation ; la documentation des propositions de strongSwan en est une référence concrète.

Le champ de chiffrement nomme le chiffrement et, dans la plupart des syntaxes, sa longueur de clé. Le champ d'intégrité nomme le hachage utilisé pour authentifier le texte chiffré, et le PRF nomme la fonction qui dérive le matériel de clé pour l'IKE SA. Le groupe DH établit un nouveau matériel secret partagé, et c'est pourquoi il apparaît des deux côtés mais à des fins différentes.

Les numéros de séquence étendus n'appartiennent qu'au chemin de données. Ils élargissent l'espace de séquence et se négocient dans le cadre de la proposition CHILD, donc un écart à cet endroit rejette une offre CHILD tout en laissant l'IKE SA intacte.

Comment une offre complète est sélectionnée

Chaque proposition est un ensemble, et le répondeur cherche un ensemble où chaque champ obligatoire est acceptable. Deux listes peuvent toutes deux contenir AES et SHA-256 et n'avoir aucune entrée compatible, parce que la longueur de clé, le PRF ou le groupe DH diffèrent. La comparaison se fait par proposition, pas par algorithme.

Quand rien ne correspond, le répondeur envoie NO_PROPOSAL_CHOSEN avec le type de SA qui a échoué. Lisez à quelle liste de propositions se rapporte la notification avant de modifier la configuration ; changer les algorithmes ESP alors que la proposition IKE a été rejetée gaspille un cycle de débogage.

Le comportement de sélection vaut la peine d'être connu lorsque vous réglez un profil. Certaines implémentations préfèrent l'ordre de l'initiateur, d'autres réordonnent selon la politique locale, donc une suite qui fonctionne entre deux fournisseurs peut disparaître lorsque vous inversez le côté qui démarre la connexion.

AEAD retire un champ au lieu d'en ajouter un

AES-GCM et ChaCha20-Poly1305 authentifient et chiffrent en une seule opération. Quand l'un ou l'autre est sélectionné pour ESP, l'algorithme d'intégrité n'est pas négocié séparément, car la construction AEAD le couvre déjà. Une proposition qui associe AES-GCM à SHA-256 est donc redondante au mieux et rejetée au pire.

Le PRF reste séparé côté IKE, puisqu'il dérive des clés pour le canal de contrôle plutôt que de protéger les charges utiles. C'est pourquoi une proposition IKE peut légitimement combiner un chiffrement AEAD avec un PRF et un groupe DH, tandis que la proposition ESP correspondante n'énumère que le chiffrement AEAD et le groupe PFS facultatif.

La longueur de clé fait partie du jeton de chiffrement, donc AES-128-GCM et AES-256-GCM sont des offres différentes. Un profil copié d'un guide qui supposait des clés 256-bit ne correspondra pas à un point de terminaison configuré pour 128-bit, même si les deux lignes disent AES-GCM. Deux pairs peuvent s'accorder sur la famille de chiffrements et néanmoins se rejeter à cause du nombre après le tiret.

Lisez l'SA installée, pas la configuration

La liste de propositions configurée est une offre ; l'SA installée est le résultat. Sur strongSwan et un noyau Linux, les deux vues sont disponibles :

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

swanctl --list-sas imprime les algorithmes négociés par SA, y compris si le CHILD utilise AEAD. ip xfrm state montre ce que le noyau a réellement installé, et c'est là qu'on confirme qu'une rotation de clés n'est pas retombée sur une suite différente de celle que vous avez documentée.

Conservez cette sortie à côté de la configuration après une correction. Lorsqu'une mise à jour du client change ses valeurs par défaut, la suite enregistrée vous donne une base de comparaison, et la comparaison pointe le champ qui a bougé au lieu de reprendre l'enquête depuis le début.