La VM Azure n'atteint plus IMDS ni WireServer après le démarrage du VPN

La VM est allumée, le client VPN annonce une connexion, et quelques minutes plus tard l'agent Azure commence à signaler un état dégradé. Parfois SSH survit et Run Command depuis le portail non, ce qui pousse les gens vers l'agent plutôt que vers la table de routage. Les décisions de transfert de l'invité ont changé à la montée du tunnel, et deux adresses de plateforme sont généralement les premières victimes. Je traite cela comme un symptôme de routage avant de le traiter comme une panne de l'agent.

Le symptôme ressemble à un agent cassé

Les deux adresses ci-dessous sont proposées comme correctif, et ce ne sont pas le même service. Copier un /32 pour l'une parce que cela a marché pour l'autre est exactement comment un contournement temporaire devient une configuration permanente que personne n'ose retirer.

L'ordre qui fonctionne est de confirmer quelle adresse l'appel en échec cible réellement, puis de lire comment l'invité la résout. Tout le reste est une supposition avec des étapes en plus et une fenêtre de changement plus longue.

168.63.129.16 n'est pas une destination publique

168.63.129.16 est l'adresse virtuelle spéciale de la plateforme Azure, et l'un de ses rôles est WireServer, que l'agent de la VM utilise pour parler à la fabrique. Microsoft documente que le trafic de l'agent vers les ports TCP 80 et 32526 doit rester disponible. Ce n'est pas un hôte internet ordinaire, et ce n'est pas quelque chose qu'un VPN en tunnel complet devrait transporter vers une sortie distante. C'est pourquoi un tunnel qui paraît sain peut quand même affamer l'agent.

La documentation de l'adresse de plateforme indique aussi que cette adresse n'est pas soumise aux routes définies par l'utilisateur, ce qui est une propriété de la fabrique Azure et non une promesse sur votre invité. Une règle de pare-feu locale ou la politique de routage du client VPN lui-même peuvent encore casser le chemin, et ni l'une ni l'autre ne vit dans la table de routage du VNet.

Si c'est l'agent qui signale le problème, vérifiez l'état du service et le chemin vers cette adresse avant de réinstaller quoi que ce soit.

169.254.169.254 a ses propres règles

169.254.169.254 est l'adresse link-local du service Azure Instance Metadata Service. Les requêtes vers elle ont leurs propres exigences : la NIC et l'IP principales, une configuration DHCP qui prend en charge l'adresse, et le contournement de tout proxy HTTP. Les envoyer par une sortie VPN distante ou une passerelle internet arbitraire n'est pas le modèle d'accès que Microsoft décrit.

Cette clause de proxy attrape ceux qui ont corrigé la route et voient toujours des échecs. Un proxy HTTP dans l'invité peut casser IMDS alors que ip route get renvoie exactement l'interface attendue, donc vérifiez les exclusions de proxy autant que les routes.

Ne collez pas de réponses de métadonnées dans un ticket de support pendant que vous déboguez. Elles peuvent porter des identifiants et des détails d'instance qui survivent à l'incident.

Lisez le routage par politique de l'invité, pas seulement la table principale

Sur un invité Linux, trois commandes en lecture seule séparent les couches : ip -4 rule show pour les règles de politique, puis ip -4 route get 168.63.129.16 et ip -4 route get 169.254.169.254 pour les décisions que le noyau prend réellement. Exécutez-les avant et après la connexion du VPN. La différence entre ces deux sorties est votre jeu de changements, et elle est plus utile que toute supposition sur ce que le client a fait.

Un client VPN qui installe des règles de politique peut laisser la table principale intacte tout en redirigeant ces recherches. C'est pourquoi un correctif limité à la table principale semble marcher sur un hôte et ne fait rien sur le suivant. Les invités à plusieurs NIC ajoutent le même problème par l'autre bout, car la réponse dépend de la NIC et de l'adresse source que la règle sélectionne.

Résistez à la recette qui ajoute les deux routes /32 via l'ancienne passerelle. Un chemin de plateforme link-local et un prochain saut WAN général sont des objets différents, et une exception globale masque le vrai conflit de politique.

Gardez l'administration et la récupération séparées

Votre réponse SSH ou RDP peut aussi être capturée par un défaut de tunnel complet, mais elle cible l'adresse observée de l'administrateur et non un point de terminaison de plateforme. Diagnostiquez-la depuis sa propre paire requête-réponse, et gardez un canal de récupération indépendant comme la console série avant de changer la politique VPN. Si un déploiement redémarre la VM et que l'agent signale un état dégradé, inspectez l'action enregistrée et le service responsable au lieu de supposer que le changement de route a causé le redémarrage.

Vérifiez ensuite les trois flux séparément : la ressource privée que vous vouliez vraiment, la communication prise en charge entre l'agent et la plateforme, et le chemin d'administration. Restaurer l'un d'eux ne prouve pas que les deux autres ont survécu.

Écrivez l'exception approuvée sous le propriétaire du réseau invité et de la configuration VPN, y compris ce qui se passe à la reconnexion et au redémarrage. Les UDR Azure ne sont pas la table de routage de l'invité, et les modifier ne corrigera pas une règle de politique locale.