VPN Windows : le profil enregistré face à l’état de l’interface active

Un VPN Windows apparaît à deux endroits qui répondent à des questions différentes, et les confondre produit un diagnostic assuré mais faux. Le profil enregistré dit ce que quelqu’un a configuré ; l’interface active dit ce que la pile vient d’appliquer. Quand une connexion s’établit et que le trafic prend toujours le mauvais chemin, les deux vues doivent être lues, dans cet ordre. Aucune des deux seule ne vous dit si le paquet de l’application est sorti par le tunnel.

Deux vues du même tunnel

La vue du profil est la configuration : adresse du serveur, type de tunnel, méthode d’authentification, réglages du tunnel partagé. Elle peut être correcte alors que la connexion l’ignore, et elle peut être périmée alors que la connexion fonctionne parfaitement, car un client qui se reconnecte peut ne pas relire ce que vous avez modifié. La vue de l’interface est l’état appliqué : quels adaptateurs existent, quelles familles d’adresses ils portent, leurs métriques et leur état de connexion. Elle change au gré des tunnels, ce qui en fait le bon endroit pour une question de routage en direct et le mauvais endroit pour une question de configuration.

Les lire ensemble est toute la méthode, et n’en lire qu’une est la façon dont les gens finissent par supprimer un adaptateur sain. Les commandes ci-dessous produisent les deux vues sans rien changer.

Lisez les deux vues sans rien changer

Commencez par les profils enregistrés, car c’est le fait le moins coûteux à confirmer. Notez le type de tunnel et la valeur du tunnel partagé, puisque les deux décident quelles destinations doivent entrer dans le tunnel. Si le profil est faux, corrigez-le via sa surface de configuration prise en charge, car rien dans la liste des interfaces ne répare un profil qui pointe vers une mauvaise passerelle.

Get-VpnConnection | Select-Object Name,ServerAddress,TunnelType,SplitTunneling,ConnectionStatus

La vue de l’interface a une autre forme : un tunnel peut occuper deux lignes lorsqu’il porte les deux familles d’adresses. Lisez l’index comme l’identité et l’alias comme une étiquette choisie par quelqu’un, et attendez-vous à ce que l’alias change entre les versions du client.

Get-NetIPInterface | Select-Object InterfaceIndex,InterfaceAlias,AddressFamily,ConnectionState,InterfaceMetric

La présence n’est pas une preuve d’utilisation, car une interface peut exister, être connectée et ne pas être celle que choisit la route vers votre destination. Gardez cela en tête avant de traiter un adaptateur inconnu comme la faute. Ces deux défaillances se ressemblent de l’extérieur : un profil correct avec une route qui ne l’utilise jamais, et un profil faux avec une route qui l’utilise. Leurs corrections sont complètement différentes, et c’est pourquoi la section suivante existe.

Suivez la route jusqu’à la destination

Demandez à la pile quel chemin elle prendrait pour l’adresse que l’application contacte réellement. C’est la question à laquelle la liste des interfaces ne peut pas répondre seule.

Find-NetRoute -RemoteIPAddress 10.60.20.10 | Select-Object -First 1
Get-NetIPAddress -InterfaceIndex 37 | Select-Object IPAddress,AddressFamily,PrefixLength

La première commande rapporte deux champs qui valent la lecture : l’alias d’interface de la source choisie et le saut suivant pour cette destination. L’index 37 de la seconde commande est ce que la première sortie a imprimé, pas une constante à copier, et l’adresse 10.60.20.10 est illustrative. Si la source choisie appartient à l’adaptateur physique alors que la destination devrait être à l’intérieur du tunnel, vous avez trouvé le problème de sélection, car l’interface VPN peut être parfaitement saine et simplement non préférée. La métrique n’est qu’une partie de cette décision, car la spécificité de la route, la stratégie et l’état de l’interface y participent toutes.

Comparez trois états dans les mêmes conditions

Relevez la liste des interfaces et la route choisie avant de vous connecter, pendant la connexion et après la déconnexion, avec la même destination et les mêmes commandes à chaque fois. Cette comparaison sépare une interface de tunnel actuelle d’un ancien adaptateur caché laissé par une désinstallation, et d’un second client qui tourne aussi. Elle vous dit aussi si l’interface du tunnel disparaît proprement, car un adaptateur qui persiste après la déconnexion est un problème différent de celui qui n’est jamais apparu. Sans les trois instantanés, chaque alias inconnu ressemble au coupable.

Conservez les trois sorties avec le ticket, car deux sorties de commandes valent mieux qu’un paragraphe de description. Un collègue peut les comparer sans reprendre votre session.

Ne supprimez pas ce que vous n’avez pas identifié

Les adaptateurs inconnus appartiennent généralement à quelque chose : un client géré, un commutateur virtuel, un réseau de conteneurs ou un agent de sécurité. En supprimer un peut retirer un composant qui fonctionne et laisser le symptôme d’origine exactement où il était. Si la route est périmée, trouvez le propriétaire de la route et corrigez-la là ; si le profil est faux, modifiez le profil. La documentation de Get-NetIPInterface énumère les champs utilisés ci-dessus, y compris les colonnes de métrique et d’état qui rendent la comparaison significative.

Nommez l’objet, trouvez son propriétaire, puis agissez sur ce propriétaire. Tout le reste revient à renommer le problème plutôt qu’à le lire.