Pair IPsec entrant sans profil correspondant ? Vérifiez quatre champs

Votre pair signale que le tunnel est monté, votre côté n'affiche aucune association de sécurité et le fichier de configuration contient manifestement un nom de connexion correspondant. Ces trois affirmations peuvent être vraies simultanément. Une négociation entrante est comparée à la configuration en cours, selon l'adresse du pair, l'identité qu'il présente et le trafic qu'il propose. Un fichier sur disque qui n'a jamais été chargé, une identité qui ne correspond pas à la valeur attendue ou une paire de sélecteurs décalée d'un préfixe produiront chacun un silence. Parcourez les quatre groupes de champs dans l'ordre que suit le répondeur.

Partez du paquet, pas du fichier

Le répondeur reçoit une demande IKE, cherche une définition capable d'accepter ce pair, puis poursuit avec l'authentification et la sélection du trafic. Si aucune définition chargée ne correspond à la première étape, la négociation se termine avant qu'une erreur utile n'atteigne l'utilisateur.

C'est pourquoi « la configuration semble correcte » n'est pas une preuve. La question est ce que le service en cours a chargé et quelle entrée il a sélectionnée pour cette tentative. Une liste d'état répond à cela en une commande, tandis que le tampon de l'éditeur répond à une autre question. Vérifiez la liste avant de modifier à nouveau le fichier.

Premier groupe de champs : la définition réellement chargée

Vérifiez l'état en cours avec l'outil qui possède le démon : une commande d'état listant les connexions chargées, pas le tampon de l'éditeur. Confirmez que l'entrée attendue est présente, qu'elle est activée pour le comportement de démarrage voulu et qu'elle a été chargée après votre dernière modification. Un fichier enregistré sans rechargement est la cause la plus fréquente de « je l'ai corrigé et rien n'a changé ».

Confirmez aussi quel fichier le service lit. Les distributions diffèrent, et une connexion écrite dans la mauvaise inclusion est ignorée en silence plutôt que rejetée. Si la liste d'état n'affiche pas du tout votre entrée, soupçonnez le chemin d'inclusion avant la syntaxe.

Deuxième groupe de champs : les extrémités ne sont pas des identités

L'adresse depuis laquelle le pair se connecte et l'identité avec laquelle il s'authentifie sont des champs distincts. Un nom d'hôte, un nom distinctif, un identifiant de clé et une adresse peuvent tous servir d'identité IKE selon la configuration, et ils n'ont pas du tout besoin de ressembler à l'adresse publique.

La correspondance des extrémités peut aussi impliquer une vue NAT : l'adresse vue sur le réseau peut différer de celle que le pair croit avoir. Dans le modèle de connexions de libreswan, left et right sont des étiquettes des deux participants et non un ordre fixe local et distant, ce qui explique que copier une configuration fonctionnelle d'un autre site en inversant les adresses ne soit pas une traduction fiable.

Notez l'identité attendue de chaque côté et le justificatif qui la valide. Si ces deux lignes divergent, aucun ajustement d'adresses ne produira de correspondance.

Troisième groupe de champs : le trafic protégé

Les sélecteurs décrivent les plages internes de source et de destination, leur famille d'adresses et toute restriction de protocole ou de port. Une proposition pour l'adresse d'un seul hôte n'est pas la même demande que pour un sous-réseau entier, et un répondeur configuré pour le sous-réseau peut la refuser ou la restreindre.

Lorsque les deux extrémités divergent, comparez le flux prévu des deux points de vue au lieu d'élargir chaque sélecteur pour que quelque chose se connecte. Demandez à chaque administrateur quel flux il croit protéger, puis comparez les deux réponses. L'écart est généralement un préfixe d'hôte d'un côté et un sous-réseau de l'autre. Un tunnel qui correspond parce qu'il protège désormais tout est une autre décision de sécurité, et une que personne n'a approuvée.

Quatrième groupe de champs : vous lisez une implémentation

Libreswan, l'ancien Openswan et strongSwan ont des outils de gestion différents, une syntaxe de configuration différente et un ordre de correspondance différent. Un exemple fonctionnel de l'un ne dit rien de précis sur la priorité de sélection de profil ou la formulation des erreurs de l'autre, vérifiez donc avec la documentation du démon de cet hôte.

Corrélez une tentative de bout en bout : l'adresse source de l'initiateur, l'identité offerte et les sélecteurs proposés, face au message de sélection du répondeur et à l'entrée chargée qu'il nomme. Des compteurs d'encapsulation et de décapsulation à zéro disent seulement que les associations observées n'ont pas transporté ces paquets ; ils ne nomment pas l'extrémité qui a rejeté la proposition et ne prouvent pas qu'une entrée correspondante existait à cet instant.

Après une correction coordonnée, confirmez le profil et l'association sélectionnés, puis testez le service réellement autorisé et son chemin de réponse. Une correspondance de profil permet la négociation, et la négociation n'est pas le dernier contrôle d'accès.