Identité IKE ou adresse de point de terminaison : ne les confondez pas

Lisez un champ étiqueté identité FQDN comme une chaîne littérale, non comme une demande du nom DNS inverse de votre adresse publique. Dans l'analyseur de strongSwan, c'est exactement cela, une chaîne, et sa lecture ne la résout jamais en un point de terminaison. Ce seul fait écarte la distraction la plus courante lorsque vous choisissez des identifiants pour un pair. Les contrôles ci-dessous empêchent les trois valeurs en jeu de se fondre en une seule.

Une étiquette n'est pas une recherche

Les interfaces des fournisseurs emploient des mots comme FQDN et hostname avec laxisme, et l'étiquette sur une boîte ne dit rien de l'encodage derrière. Un équipement qui nomme un champ Client FQDN peut envoyer un FQDN, une chaîne en forme d'adresse électronique ou une adresse nue. Traitez le texte et le type comme deux décisions distinctes et consignez les deux.

Rien dans une identité littérale n'exige DNS. C'est une affirmation que l'autre extrémité vérifie, non un nom que le réseau doit résoudre.

Trois valeurs distinctes, écrites séparément

Trois tâches se cachent derrière un seul écran de configuration, et les fusionner est l'erreur coûteuse. Une valeur est l'adresse du point de terminaison, qui décide où vont les paquets. Une autre est l'identité locale que ce pair présente, et la troisième est l'identité que vous attendez de l'extrémité distante avant de l'authentifier. Écrivez-les sur trois lignes dans le ticket de changement, car toute formulation moindre décrit un VPN plutôt qu'une relation.

Les identités d'exemple doivent être choisies et autorisées dans le cadre du déploiement. Ce sont des affirmations que l'authentification vérifie, non des identifiants qui rendraient un pair fiable, aussi une chaîne d'apparence plausible n'autorise-t-elle rien.

Le type fait partie de la valeur

La référence d'identités de strongSwan sépare FQDN, valeurs en forme d'adresse électronique, adresses IP et autres encodages, si bien que l'encodage compte autant que les caractères. Deux appareils peuvent accepter un texte identique sous des types différents et pourtant se refuser mutuellement. Une note qui consigne la valeur sans son type est une demi-configuration.

Demandez au fournisseur quel type l'équipement envoie réellement, et confirmez-le par un décodage plutôt que par l'étiquette de l'interface. Un type deviné est une inadéquation qui attend le prochain changement.

Chaque côté doit satisfaire l'autre

L'identité locale de chaque côté doit satisfaire la politique d'authentification de l'autre côté. Ce n'est pas la même chose que coller une chaîne dans chaque case d'identité des deux appareils, qui est le raccourci produisant une configuration que personne ne peut déboguer.

L'authentification par certificat ajoute ses propres exigences, car l'identité du certificat et les conditions de confiance se placent à côté de l'identité IKE que vous avez saisie. Une correspondance d'identité IKE seule n'autorise pas un pair à certificat.

Où DNS compte, et ce que votre version impose

Un nom d'hôte de passerelle utilisé pour la découverte a bien besoin d'un DNS fonctionnel, et cette exigence relève de la recherche du point de terminaison, non d'une recherche inverse d'une identité saisie. Gardez les deux séparés dans le ticket, car un échec de découverte et une inadéquation d'identité se lisent de façon similaire dans un journal client et se réparent à des endroits différents.

Lisez l'analyseur du produit et de la version que vous exécutez réellement avant de copier une syntaxe qui impose un type, car les anciennes versions de strongSwan se comportaient différemment et d'autres fournisseurs ajoutent leurs propres contraintes. Lorsque vous comparez les deux extrémités, tenez quatre éléments ensemble : identité attendue, identité présentée, type et erreur d'authentification. Cet ensemble transforme une inadéquation en preuve plutôt qu'en opinion.