Les noms d’utilisateur et les mots de passe voyagent dans un porteur, et MSCHAPv2 ne nomme que la méthode qui voyage. Demandez quel tunnel le porte avant de choisir un profil client, car la même chaîne de compte apparaît dans des agencements qui ne partagent pas une ligne de code. Chaque profil qu’on vous remet encode les deux décisions, même lorsque la fiche d’instructions n’en imprime qu’une. L’ordre ci-dessous est ce qu’un opérateur peut répondre sans deviner et ce que vous pouvez vérifier sans capture de paquets.

L’authentification roule à l’intérieur d’un tunnel

Un VPN prend deux décisions qui n’en font qu’une en apparence : comment les pairs construisent un canal protégé et comment une personne prouve son identité à l’intérieur. La seconde est imprimée sur la fiche d’instructions parce que c’est celle qu’un humain saisit. La première décide si un client fonctionnera tout court, et c’est celle que les gens sautent. Demandez à l’opérateur de nommer d’abord le porteur, puis la méthode, dans cet ordre. Deux connexions peuvent exiger le même nom de compte et le même mot de passe sans partager la moindre implémentation sous le champ de connexion.

C’est pourquoi des réglages copiés depuis le téléphone qui fonctionne d’un collègue peuvent échouer sur le vôtre, même quand le serveur accepte les deux identifiants. L’identifiant n’a jamais été la différence ; le profil qui l’entoure l’était. les deux côtés ont raison et rien ne se connecte est généralement précisément cette confusion, et elle se dissipe dès que le porteur est nommé.

Trois endroits où la même méthode apparaît

En PPP, l’étape d’authentification attend qu’une liaison existe, et RFC 2759 définit MS-CHAPv2 comme cette étape, ce qui explique pourquoi la méthode surgit dans L2TP et dans des déploiements PPTP plus anciens. Le tunnel se termine d’abord et la négociation PPP a lieu à l’intérieur, si bien qu’une étape PPP ratée peut laisser le tunnel paraître établi dans le journal du serveur. Lisez ces deux étapes séparément avant de conclure que les identifiants ont été rejetés. Un client configuré pour L2TP peut donc être parfaitement correct et rester le mauvais client pour une passerelle qui ne parle qu’IKEv2.

IKEv2 place au contraire EAP-MSCHAPv2 à l’intérieur de l’échange de clés, si bien que le même identifiant échoue à un autre moment et se manifeste comme une erreur d’authentification plutôt que comme une erreur de session. Le profil IKEv2 de la plateforme Android est l’exemple quotidien, et il demande un certificat ou un identifiant de serveur plutôt que des options PPP. Le nom de compte est identique dans les deux agencements, il ne peut donc pas vous dire lequel vous avez. Seule la liste des protocoles pris en charge par l’opérateur tranche.

Un VPN reposant sur TLS ajoute un troisième agencement, avec ses propres champs de nom d’utilisateur et de mot de passe et aucun MS-CHAPv2 nulle part dans l’échange. Voir un champ de mot de passe n’est donc pas une preuve du protocole derrière, car le formulaire est construit pour paraître familier. Confirmez le protocole à partir de la documentation du serveur, pas de la forme de la fenêtre du client.

Les réponses dont vous avez vraiment besoin

Envoyez la demande sous forme de liste, car une liste est difficile à répondre à moitié. Demandez le protocole du tunnel, la méthode à l’intérieur et le client que l’opérateur prend en charge sur votre plateforme. Demandez ensuite l’identité et les réglages de confiance de la passerelle, le format du compte et ce qui devrait être joignable une fois la connexion établie.

Les trois premières décident si vous obtenez un profil qui fonctionne. Les trois dernières décident si ce profil fait ce que le travail exige. Gardez la réponse attachée au ticket, car la personne suivante posera les mêmes six questions. Là où une réponse manque, traitez le vide comme une décision que l’opérateur n’a pas encore prise, non comme quelque chose que vous pouvez déduire.

What you ask forIf it is wrong, the symptom shows up as
Tunnel protocolNo profile can be built at all
Method inside the tunnelCredentials typed, then rejected
Gateway identityThe client refuses the server certificate
Account formatAuthentication fails only for some staff
Routes and DNSThe tunnel is up and nothing resolves

Ne relâchez pas la vérification de la passerelle

Le serveur prouve aussi son identité au client, et cette moitié de l’échange n’est pas décorative. Désactiver la vérification du certificat pour qu’un profil récalcitrant se connecte accepte n’importe quel point de terminaison qui répond, y compris un que personne ne visait. Cela masque aussi un vrai décalage au lieu de le résoudre, ce qui repousse la panne vers un moment plus tardif et moins évident. Un profil qui exige la vérification coupée est un profil qui pointe vers quelque chose qu’il ne peut pas vérifier.

Le décalage est généralement un nom, car un certificat émis pour un nom d’hôte échoue quand le profil compose une adresse. Composez le nom plutôt que de désactiver la vérification. Une autorité de certification privée échoue quand l’appareil n’a jamais reçu la racine, et le correctif est de distribuer cette racine par la voie approuvée. Les environnements gérés attendent de l’opérateur qu’il fournisse l’identité et l’ancre de confiance, et au profil qu’il référence les deux. Quand le champ est absent, demandez l’artefact plutôt que de renoncer à la vérification.

Adaptez le profil, puis prouvez chaque étape

Une fois le porteur connu, suivez le processus documenté de ce client et ne saisissez que les champs qu’il demande. Les champs supplémentaires remplis parce qu’ils existent restent des valeurs erronées, et ils échouent plus tard que les champs obligatoires. Enregistrez le profil inchangé après la première connexion réussie, afin qu’une modification ultérieure puisse être comparée à quelque chose dont on sait qu’il fonctionne.

Vérifiez ensuite par étapes : le tunnel s’établit, l’utilisateur s’authentifie, l’adresse et les routes attribuées apparaissent, et un service autorisé répond. Chaque étape laisse sa propre ligne de journal sur le serveur, et les lire dans l’ordre transforme une plainte vague en constat précis. Si la plateforme ne prend plus en charge l’agencement décrit par l’opérateur, c’est une conversation de migration et non une raison d’activer toutes les options héritées sur l’appareil. Porteur, méthode et profil sont trois réponses distinctes, et une connexion qui fonctionne les a toutes trois d’accord.

Articles similaires