Une route VPN épinglée à un index d’interface casse à la reconnexion

La route a fonctionné pendant des semaines, puis elle a commencé à envoyer le trafic nulle part, la destination restant inchangée et rien n’ayant été modifié. Ce qui a changé, c’est le numéro : une route créée pour un index d’interface précis fait référence à un adaptateur qui n’existe plus après une reconnexion, et le préfixe de destination continue de pointer vers une infrastructure qui a été remplacée. Ajouter de la persistance à cette commande n’aide pas, car le problème n’a jamais été de savoir si la route survivait à un redémarrage. La solution est d’attacher l’intention à la connexion, qui survit par conception aux changements d’adaptateur.

Vérifiez ce que la route désigne réellement

Commencez par lire l’entrée de route et les adaptateurs côte à côte. Une route dont le saut suivant se trouve sur l’interface VPN et dont l’index ne correspond à aucun adaptateur actuel est la signature de cette panne ; le même préfixe sur un autre index est soit un reliquat, soit la route que vous voulez vraiment. Lisez les deux listes avant de modifier l’une ou l’autre, car la comparaison intéressante est entre le numéro de la route et les numéros qui existent maintenant. Si l’index de la route figure dans la liste des adaptateurs, l’index n’est pas votre problème et la recherche passe aux métriques, à la stratégie ou à l’extrémité distante. S’il n’y figure pas, il n’y a rien d’autre à diagnostiquer : la route est rattachée à une infrastructure qui n’existe plus.

Get-NetRoute -DestinationPrefix '10.77.0.0/16' | Select-Object DestinationPrefix, NextHop, InterfaceIndex, Store
Get-NetAdapter | Where-Object InterfaceDescription -like '*VPN*' | Select-Object Name, InterfaceIndex, InterfaceDescription
Get-VpnConnection -Name 'Lab VPN' | Select-Object Name, ServerAddress, SplitTunneling

La colonne Store distingue une entrée qui persiste entre les redémarrages de celle qui disparaît avec l’adaptateur, et cette différence détermine si la panne reviendra demain. Une entrée dans le magasin persistant qui pointe vers un index disparu est le pire cas, car elle survit aux redémarrages sans jamais correspondre à quoi que ce soit.

Liez le préfixe au profil, pas à l’adaptateur

Un VPN natif de Windows peut porter sa propre liste de routes, si bien que la connexion réutilise le bon adaptateur chaque fois qu’elle apparaît. La route suit alors le profil plutôt qu’un numéro que vous avez observé une fois, et aucun script n’a à deviner un index après chaque appel. L’ajout d’un préfixe est aussi réversible via la commande de suppression correspondante, ce qui garde la modification auditable. Le préfixe est stocké avec la connexion plutôt que dans un script de démarrage, de sorte qu’un profil copié vers un autre utilisateur emporte l’intention avec lui.

Add-VpnConnectionRoute -ConnectionName 'Lab VPN' -DestinationPrefix '10.77.0.0/16' -PassThru

La référence de Add-VpnConnectionRoute documente l’association à la connexion, et la portée du carnet d’adresses compte : un profil par utilisateur et un profil pour tous les utilisateurs sont des objets différents. Ce mécanisme appartient au client VPN de Windows lui-même, de sorte qu’un adaptateur de fournisseur géré par son propre service peut tirer ses routes d’une source de stratégie entièrement différente.

Nettoyez les anciennes routes avant d’ajouter la nouvelle

Deux routes avec le même préfixe et des propriétaires différents sont pires qu’une seule route erronée, car le gagnant dépend de métriques que personne n’a notées. Inspectez ce qui existe déjà pour le préfixe, y compris les entrées du magasin persistant, et ne supprimez que ce qui appartient à la tentative échouée. Un reliquat d’une conception précédente est courant dans ce domaine, la route défaillante ayant généralement remplacé quelque chose qui fonctionnait. Notez quelles entrées appartiennent à quelle connexion avant de supprimer quoi que ce soit, et conservez la liste dans le journal des modifications.

Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like '10.77.*'
Remove-NetRoute -DestinationPrefix '10.77.0.0/16' -NextHop '0.0.0.0' -Confirm:$false

Faites correspondre préfixe, saut suivant, magasin et propriétaire ensemble au lieu de supprimer tout ce qui se ressemble. Une autre connexion peut légitimement dépendre d’une partie de cet espace, et une suppression massive transforme une réparation soignée en incident de support.

Reconnectez-vous dans un ordre différent

Reproduisez la condition au lieu d’espérer que la première tentative était représentative. Déconnectez, reconnectez et confirmez le chemin sélectionné vers la même ressource distante pendant que le tunnel est actif ; avec plusieurs VPN en jeu, montez-les dans un ordre différent et observez si le chemin choisi change. L’ordre est la variable que la plupart des gens sautent, et c’est celle qui révèle une route rattachée à la mauvaise connexion.

rasdial 'Lab VPN' /disconnect
rasdial 'Lab VPN'
Find-NetRoute -RemoteIPAddress 10.77.5.20 | Select-Object -First 1

Le résultat que vous voulez n’est pas qu’un adaptateur conserve son numéro une fois. C’est que la route apparaisse avec le numéro que la connexion reçoit, à chaque fois, et disparaisse quand la connexion se ferme. Se reconnecter deux fois est le moyen le moins coûteux de distinguer ces issues.

Sachez ce que la route ne peut pas faire

Une route de profil fournit un chemin et rien d’autre. Elle n’ouvre pas un pare-feu distant, ne crée pas de route de retour à l’extrémité distante et ne résout pas deux sites qui utilisent la même plage d’adresses ; chacun de ces points est une configuration distincte avec un propriétaire distinct. Confirmer le chemin est donc le début du test d’acceptation et non la totalité de ce test.

Gardez la liste des préfixes avec le profil et notez sous quelle portée il a été ajouté, afin que la personne suivante puisse lire la conception prévue au lieu de la déduire d’une table de routage. Les routes qui n’existent que dans la mémoire de quelqu’un sont celles qui sont reconstruites de travers après la reconnexion suivante. Un commentaire d’une ligne dans les notes de déploiement coûte moins qu’un après-midi de redécouverte.