Azure P2S : un client Windows perd ses routes après un changement de VNet

Deux portables s'authentifient sur la même passerelle Azure point-to-site, et un seul atteint le VNet récemment connecté. Les deux affichent Connected, donc l'authentification n'est pas la différence ; les routes de destination qu'ils détiennent le sont. Partez du client qui échoue, comparez une seule destination, et décidez seulement ensuite si l'écart appartient au paquet de la passerelle ou à la table de routage locale.

Partez du client qui échoue, pas de la passerelle

Confirmez la topologie avant de blâmer le portable. Vérifiez quels VNets sont connectés au VNet de la passerelle et si le nouveau réseau est appairé directement ou atteint par un tunnel site-to-site distinct. Si le nouveau VNet n'est pas du tout connecté au VNet de la passerelle, aucun paquet client ne peut y router, et le portable qui fonctionne est l'anomalie à expliquer. Notez la réponse, car elle décide si vous déboguez un client ou une passerelle.

Une fois la topologie correcte, placez les deux portables côte à côte. Même passerelle, même pool d'adresses, même protocole et même version du client constituent la comparaison que vous voulez ; tout le reste est une seconde variable qu'il faudra éliminer ensuite.

Comparez une destination avec route print

Choisissez une IP de ressource autorisée et comparez les deux portables deux fois : déconnectés, puis connectés. Sous Windows, route print -4 liste les routes IPv4 avec le préfixe de destination, l'interface, le saut suivant et la métrique. Notez la ligne qui l'emporterait réellement pour cette destination plutôt que de compter les entrées contenant le mot VPN.

La sélection se fait d'abord par le préfixe le plus long, puis par la métrique, si bien qu'une route locale plus spécifique peut battre la route du tunnel sans paraître erronée. Si la destination visée est dans 10.24.0.0/16, un client sain affiche une route correspondante sur l'interface VPN, tandis que le client en échec envoie la même adresse à sa passerelle par défaut.

Un préfixe local en conflit peut produire le même symptôme. Avant d'ajouter quoi que ce soit, déterminez lequel des deux cas vous avez : aucune route de tunnel, ou une route de tunnel qui perd face à une plus spécifique.

TTL expired n'est pas un bug de distribution des routes

Un ping qui renvoie TTL expired in transit indique que le paquet a épuisé son quota de sauts, ce qui signifie généralement une boucle de transfert et non un pilote VPN cassé. Le ping de Windows accepte un TTL jusqu'à 255, et augmenter la valeur ne répare pas une boucle ; elle ne fait que retarder la même erreur. Traitez le message comme un symptôme du chemin, non comme une preuve sur la distribution des routes.

Utilisez tracert -4 10.24.1.10 pour voir où le chemin se répète. Si les deux mêmes sauts apparaissent encore et encore, cherchez une route qui renvoie le trafic destiné au tunnel dans le tunnel ou vers un routeur local qui le réachemine.

Régénérez le paquet sur la passerelle qui le détient

Microsoft documente que les paquets clients Windows doivent être téléchargés et installés de nouveau après des changements de topologie significatifs. Récupérez le paquet courant depuis la passerelle Azure qui sert ce profil, puis appliquez-le avec la procédure prise en charge pour ce client. Remplacer l'exécutable d'une application VPN sans rapport n'est pas la même opération que régénérer des réglages propres à la passerelle. Retélécharger le paquet est bon marché ; deviner des routes locales ne l'est pas.

Reconnectez-vous et relisez la route de la destination d'origine. Conservez les lignes avant et après avec le compte rendu de changement afin que le résultat soit plus précis que j'ai réinstallé le client.

Les scénarios de routage Azure P2S séparent les VNets appairés directement des réseaux atteints par d'autres tunnels, et un nouveau paquet ne peut pas rendre l'appairage transitif. Certains scénarios Windows site-to-site ou BGP nécessitent aussi des routes distantes configurées à la main, donc le rafraîchissement du paquet n'est pas un mécanisme universel de distribution des routes.

Laissez une route temporaire temporaire

Une route manuelle peut isoler une route client manquante, mais construisez-la à partir de la conception réelle : route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, sans l'indicateur persistant, afin qu'elle disparaisse au redémarrage. Choisissez l'index d'interface et le saut suivant sur l'adaptateur VPN connecté, pas au hasard.

Ne laissez pas une route expérimentale comme propriétaire concurrent permanent. De futures mises à jour de profil peuvent ajouter le même préfixe avec une autre métrique, et l'entrée manuelle décide alors silencieusement quel chemin gagne. Notez l'étape de retrait dans le changement.

Une fois la bonne route active, testez l'application cible plutôt qu'un ping. Si les paquets atteignent Azure mais que le service échoue encore, vérifiez le groupe de sécurité réseau et le chemin de retour, car ils sont indépendants du fait que le portable a appris le préfixe.