Azure-VM erreicht IMDS und WireServer nach VPN-Start nicht mehr

Die VM läuft, der VPN-Client meldet eine Verbindung, und wenige Minuten später beginnt der Azure-Agent, einen schlechten Zustand zu melden. Manchmal überlebt SSH, während Run Command aus dem Portal nicht mehr geht, was die Leute zum Agenten statt zur Routentabelle schickt. Die Weiterleitungsentscheidungen des Gasts änderten sich, als der Tunnel hochkam, und zwei Plattformadressen sind meist die ersten Opfer. Ich behandle das als Routing-Symptom, bevor ich es als Agentenfehler behandle.

Das Symptom sieht nach einem kaputten Agenten aus

Beide Adressen unten werden als Lösung vorgeschlagen, sind aber nicht derselbe Dienst. Eine /32 für die eine zu kopieren, weil sie für die andere funktioniert hat, ist genau der Weg, auf dem ein vorübergehender Workaround zu einer dauerhaften Konfiguration wird, die niemand zu entfernen wagt.

Die Reihenfolge, die funktioniert: erst bestätigen, welche Adresse der fehlschlagende Aufruf tatsächlich anspricht, dann lesen, wie der Gast sie auflöst. Alles andere ist Raten mit zusätzlichen Schritten und einem längeren Änderungsfenster.

168.63.129.16 ist kein öffentliches Ziel

168.63.129.16 ist die spezielle virtuelle Plattformadresse von Azure, und eine ihrer Rollen ist WireServer, den der VM-Agent für die Kommunikation mit dem Fabric nutzt. Microsoft dokumentiert, dass Agentenverkehr zu den TCP-Ports 80 und 32526 verfügbar bleiben muss. Es ist kein gewöhnlicher Internet-Host, und es ist nichts, was ein Full-Tunnel-VPN an einen entfernten Ausgang tragen sollte. Deshalb kann ein Tunnel, der gesund aussieht, den Agenten trotzdem aushungern.

Die Dokumentation zur Plattformadresse sagt außerdem, dass diese Adresse nicht benutzerdefinierten Routen unterliegt, was eine Eigenschaft des Azure-Fabric ist und kein Versprechen für Ihren Gast. Eine lokale Firewallregel oder die eigene Routing-Policy des VPN-Clients kann den Pfad trotzdem brechen, und beides lebt nicht in der Routentabelle des VNet.

Wenn der Agent das Problem meldet, prüfen Sie den Dienststatus und den Pfad zu dieser Adresse, bevor Sie irgendetwas neu installieren.

169.254.169.254 hat eigene Regeln

169.254.169.254 ist die Link-Local-Adresse des Azure Instance Metadata Service. Anfragen dorthin haben eigene Anforderungen: die primäre NIC und primäre IP, eine DHCP-Konfiguration, die die Adresse unterstützt, und die Umgehung jedes HTTP-Proxys. Sie über einen entfernten VPN-Ausgang oder ein beliebiges Internet-Gateway zu schicken, ist nicht das Zugriffsmodell, das Microsoft beschreibt.

Diese Proxy-Klausel erwischt Leute, die die Route repariert haben und trotzdem Fehler sehen. Ein HTTP-Proxy im Gast kann IMDS brechen, während ip route get genau die erwartete Schnittstelle zurückgibt, also prüfen Sie die Proxy-Ausnahmen ebenso wie die Routen.

Kleben Sie keine Metadaten-Antworten in ein Support-Ticket, während Sie das debuggen. Sie können Zugangsdaten und Instanzdetails enthalten, die den Vorfall überleben.

Lesen Sie das Policy-Routing des Gasts, nicht nur die Haupttabelle

Auf einem Linux-Gast trennen drei Nur-Lese-Befehle die Schichten: ip -4 rule show für die Policy-Regeln, dann ip -4 route get 168.63.129.16 und ip -4 route get 169.254.169.254 für die Entscheidungen, die der Kernel tatsächlich trifft. Führen Sie sie vor und nach dem VPN-Verbindungsaufbau aus. Die Differenz zwischen diesen beiden Ausgaben ist Ihr Änderungssatz und nützlicher als jede Vermutung darüber, was der Client getan hat.

Ein VPN-Client, der Policy-Regeln installiert, kann die Haupttabelle unangetastet lassen und diese Lookups trotzdem umleiten. Deshalb scheint eine Korrektur nur an der Haupttabelle auf einem Host zu wirken und auf dem nächsten nichts zu tun. Gäste mit mehreren NICs fügen dasselbe Problem aus der anderen Richtung hinzu, weil die Antwort davon abhängt, welche NIC und Quelladresse die Regel wählt.

Widerstehen Sie dem Rezept, beide /32-Routen über das alte Gateway hinzuzufügen. Ein Link-Local-Plattformpfad und ein allgemeiner WAN-Next-Hop sind verschiedene Objekte, und eine Pauschalausnahme verdeckt den echten Policy-Konflikt.

Halten Sie Administration und Wiederherstellung getrennt

Ihre SSH- oder RDP-Antwort kann ebenfalls von einem Full-Tunnel-Default abgefangen werden, aber sie zielt auf die beobachtete Adresse des Administrators und nicht auf einen der Plattform-Endpunkte. Diagnostizieren Sie sie aus ihrem eigenen Anfrage-Antwort-Paar, und halten Sie einen unabhängigen Wiederherstellungskanal wie die serielle Konsole bereit, bevor Sie die VPN-Policy ändern. Wenn ein Deployment die VM neu startet und der Agent einen schlechten Zustand meldet, prüfen Sie die aufgezeichnete Aktion und den verantwortlichen Dienst, statt anzunehmen, die Routenänderung habe den Neustart verursacht.

Prüfen Sie dann die drei Flüsse getrennt: die private Ressource, die Sie eigentlich wollten, die unterstützte Agenten- und Plattformkommunikation und den Administrationspfad. Einen davon wiederherzustellen ist kein Beweis, dass die anderen beiden überlebt haben.

Schreiben Sie die genehmigte Ausnahme beim Eigentümer des Gastnetzwerks und der VPN-Konfiguration fest, einschließlich dessen, was bei Wiederverbindung und Neustart passiert. Azure-UDRs sind nicht die Routentabelle des Gasts, und sie zu bearbeiten behebt keine lokale Policy-Regel.