VPN sous Windows : associez le client au profil

Windows signale le tunnel comme connecté alors que la page de l’intranet expire encore, et le profil vient de quelqu’un qui est parti depuis. Deux erreurs distinctes se cachent derrière cet état : le mauvais client pour le fichier et une attente erronée sur ce que couvre le tunnel. Les distinguer demande quelques commandes et évite une réinstallation. Aucune des deux ne se règle en redémarrant.

Le client intégré n’importe que ses propres types

Windows fournit un client VPN qui comprend certains types de connexion, et il n’importera ni un fichier OpenVPN ni une configuration WireGuard, quel que soit le nom du fichier. Ceux-là ont besoin de leur propre logiciel, installé depuis la page de téléchargement vérifiée de l’éditeur. Une entrée familière dans le menu réseau ne prouve pas que le serveur la prend en charge, et un profil renommé avec une extension familière reste le mauvais fichier. Le type de connexion doit correspondre à ce que l’opérateur a fourni, non à ce que le menu propose par hasard.

Pour une connexion native, ajoutez-la via les paramètres réseau et saisissez exactement les valeurs fournies. Un IKEv2 basé sur certificat et un point d’entrée avec nom d’utilisateur et mot de passe sont des configurations différentes, même lorsque les deux finissent sous le même intitulé. Si un appareil géré fournit déjà une connexion, utilisez-la au lieu d’en construire une seconde à côté.

Les étapes de connexion ne sont pas interchangeables

Une connexion peut exiger un nom d’utilisateur et un mot de passe, un certificat client, une invite interactive ou plusieurs de ces éléments à la suite. La phrase secrète d’une clé privée déverrouille une clé et n’est pas le mot de passe du service, même lorsque les deux sont saisis dans la même boîte de dialogue. Un avertissement de certificat porte sur l’identité ou la confiance, pas sur l’orthographe du nom de compte. Lire lequel des trois a échoué décide de l’étape suivante.

Lisez le rejet au lieu de le réessayer. Un échec d’authentification et un échec de confiance se ressemblent dans une fenêtre d’état et n’ont rien en commun en dessous : le premier a besoin d’un identifiant, le second d’une chaîne que le client accepte.

Gardez les identifiants et le matériel de certificat hors des captures d’écran. La photo d’une page de paramètres peut exposer à la fois une adresse de serveur et un nom d’utilisateur enregistré, et un fil d’assistance est un document public plus souvent qu’on ne le croit. Masquez avant de publier, pas après que quelqu’un l’a déjà cité.

Dans PowerShell, Get-VpnConnection liste ce que Windows croit configuré, y compris des entrées que la fenêtre des paramètres garde hors de vue. Depuis une invite cmd, rasdial se connecte par nom de connexion et ipconfig /all montre ce que l’adaptateur a réellement reçu. Les deux shells ne partagent pas d’analyseur, alors collez chaque ligne dans le bon.

Get-VpnConnection
Get-VpnConnection -Name "Office" | Format-List Name,ServerAddress,AuthenticationMethod

rasdial "Office"
ipconfig /all

C’est la table de routage qui décide, pas l’icône de l’adaptateur

Un tunnel d’entreprise peut ne router que les destinations du bureau, laissant la navigation ordinaire sur la connexion locale, tandis qu’un profil en tunnel complet fait l’inverse. Ouvrez la ressource réelle avant de conclure que l’un des deux comportements est faux. L’icône rapporte l’état de l’adaptateur, et la réponse se trouve dans la table de routage. Ces deux-là se contredisent plus souvent qu’une fenêtre d’état ne l’admet.

Des entrées plus spécifiques peuvent envoyer un sous-réseau dans le tunnel tandis que la route par défaut reste à l’extérieur, et c’est exactement à quoi doit ressembler un tunnel divisé. Une entrée manquante est l’autre résultat courant, et depuis le navigateur elle est identique à un tunnel coupé. Comparez le préfixe que vous n’atteignez pas à la table plutôt qu’à l’icône. C’est pourquoi l’icône et la table peuvent diverger alors que les deux disent la vérité sur des choses différentes.

Ne supprimez pas de routes parce que la table contient des adaptateurs que vous ne reconnaissez pas. Une machine virtuelle, un pilote de filtre ou un second client peuvent chacun en ajouter une, et la retirer casse quelque chose qui fonctionnait.

route print -4
nslookup intranet.corp.internal

Les noms privés ont besoin du résolveur de l’organisation

Les noms privés ont besoin du résolveur de l’organisation, et un navigateur doté de son propre DNS sécurisé peut contourner entièrement le paramètre système. Cela produit le cas déroutant où une requête en ligne de commande renvoie une adresse et où le même nom échoue encore dans le navigateur.

Vérifiez quel adaptateur a fourni la configuration DNS actuelle avant de changer quoi que ce soit. Conservez le résolveur de l’organisation pour les noms privés au lieu de le remplacer par un service public. Remplacer par un résolveur public répare généralement un nom public et casse tous les noms internes, ce qui est une panne pire que celle de départ. Si la connexion signale un succès et que rien ne fonctionne, passez en revue le transfert et le DNS avant de réinitialiser la pile réseau.

Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName intranet.corp.internal

La documentation de Microsoft sur les types de connexion VPN de Windows et les modules complémentaires est la référence pour savoir quel client gère quel type, et aucune étiquette de menu ne vous le dit. Reconnectez-vous après tout changement et retentez la véritable application plutôt que l’icône d’état. Enregistrez le profil qui fonctionne là où vous le retrouverez, et notez le résolveur et la route qui l’ont fait marcher, car la machine suivante aura besoin des deux.