Le secret de groupe vpnc ou votre identifiant : quel champ prend quoi ?

La première fois que quelqu'un vous remet un profil vpnc, la boîte de dialogue d'authentification demande quatre choses et se lit comme si elle voulait un seul mot de passe. Elle ne le veut pas : un secret de groupe prépartagé et une connexion XAuth individuelle sont des valeurs distinctes avec des propriétaires distincts, et mettre le mot de passe du compte dans le champ de groupe produit un échec qui ressemble à un mauvais mot de passe plutôt qu'à une mauvaise case. Bien établir cette correspondance est toute la tâche ici. Le protocole en dessous est le projet de migration de quelqu'un d'autre, et c'est pourquoi rien de tout cela n'est un argument pour construire de nouveaux tunnels IKEv1.

Deux secrets, deux propriétaires, une boîte de dialogue

Un secret de groupe appartient au profil de la passerelle. Tous ceux qui se connectent par ce profil utilisent la même valeur, et c'est exactement pourquoi il ne peut pas identifier une personne et ne peut pas être retiré à un ordinateur portable sans être changé pour tous les autres utilisateurs du profil. Le nom d'utilisateur et le mot de passe XAuth appartiennent en revanche à la personne, et la passerelle les évalue dans une seconde étape, une fois l'association IPsec déjà établie.

C'est cette forme en deux étapes que les gens manquent. L'établissement du tunnel et l'authentification de l'utilisateur sont des échanges différents avec des entrées différentes, donc un client qui n'atteint jamais l'invite d'authentification n'a pas échoué du tout à la connexion. Lisez la boîte de dialogue comme deux colonnes plutôt qu'une : les valeurs propres au profil à gauche, les valeurs personnelles à droite. Quand une connexion échoue, la colonne que vous avez remplie le plus récemment n'est pas automatiquement la coupable.

Associez les champs par rôle, pas par étiquette

vpnc nomme ses directives dans la documentation du projet, et chaque interface graphique les renomme. Traduisez le rôle de chaque valeur et les étiquettes cessent d'importer :

Une interface qui affiche « Nom d'utilisateur » et « Mot de passe » à côté d'un champ de groupe n'est pas fausse — ce sont les mêmes trois valeurs sous des noms différents. Ce qui casse, c'est de remplir une case parce qu'une valeur y tient. Un secret de groupe collé comme mot de passe utilisateur authentifie le profil puis échoue à l'étape utilisateur ; un mot de passe de compte collé comme secret de groupe échoue plus tôt, avant toute invite, et envoie les gens chercher des pare-feux pour un problème qui vit dans un champ texte.

Ce qu'un identifiant de groupe n'est pas

Le mot groupe invite à une mauvaise lecture. Un identifiant de groupe ici est un sélecteur qui dit à la passerelle quelle configuration de profil appliquer ; il ne dit rien sur l'appartenance à un annuaire, et un nom identique des deux côtés est une coïncidence tant que l'exploitant ne l'a pas confirmé. L'autorisation a lieu après la réussite de XAuth, décidée par ce que la passerelle est configurée à consulter, et rien de tout cela n'est visible dans la boîte de dialogue du client.

La même prudence vaut pour le secret de groupe. Le connaître n'est pas une identité, et faire circuler un seul secret dans une équipe est une décision opérationnelle aux conséquences que le client ne peut pas vous montrer.

Résolvez l'instruction ambiguë avant de vous connecter

Les notes de passation héritées contiennent souvent une ligne comme « utilisez l'IP publique dédiée ». Cette phrase peut désigner l'adresse depuis laquelle une liste d'autorisation en face attend que votre trafic arrive, ce qui est une propriété de sortie du réseau de l'exploitant et n'a rien à voir avec le point de terminaison que vous tapez dans le champ de la passerelle. Demandez laquelle des deux est visée avant que la valeur aille où que ce soit. Remplie à l'envers, elle envoie chaque paquet vers une adresse qui ne répond jamais, et le délai d'attente qui en résulte se lit comme un port bloqué.

Demandez quatre choses par le canal vérifié de l'organisation : quel client et quel protocole sont pris en charge, quel point de terminaison utiliser, quelle identité la passerelle présentera et comment les identifiants sont remis. Gardez les vrais secrets hors des captures d'écran, des tickets et des notes de dépannage partagées. Ne désactivez pas les contrôles de certificat et ne collez pas une ancienne liste de chiffrement pour faire paraître compatible un service configuré différemment, car une connexion qui ne fonctionne qu'en affaiblissant la vérification n'est pas la connexion qu'on vous a demandé de construire.

Gardez le profil hérité honnête

IKEv1 est obsolète, et le RFC 9395 est le document à citer quand la question de la migration se pose. Une correspondance de champs réussie n'est pas la preuve que le protocole appartient à une nouvelle conception ; ce qu'elle achète, c'est une connexion fonctionnelle pendant que le remplacement est planifié, plus un périmètre écrit et un responsable pour cette migration.

Vérifiez ensuite par rapport à l'exigence plutôt que par rapport à la boîte de dialogue. Après connexion, confirmez que l'interface du tunnel porte l'adresse attendue et qu'une destination interne passe par elle ; si l'exigence initiale nommait une adresse de sortie pour une liste d'autorisation, confirmez aussi cette adresse, car c'est un fait différent du tunnel étant monté. Un profil qui s'authentifie correctement et ne route rien a quand même échoué à la tâche pour laquelle il a été créé.