Azure-VM erreecht IMDS oder WireServer net méi, nodeems de VPN start

D'VM leeft, de VPN-Client seet, hie wier verbonnen, an e puer Minutte méi spéit fänkt den Azure-Agent un, en ongesonde Zoustand ze mellen. Heiansdo iwwerlieft SSH an de Run Command aus dem Portal net, wat d'Leit bei den Agent schéckt amplaz bei d'Routentabelle. Dem Gast seng eege Weiderleedungsentscheedungen hunn sech geännert, wéi den Tunnel opgaangen ass, an zwou Plattformadressen sinn normalerweis déi éischt Affer. Ech behandelen dat als Routing-Symptom, ier ech et als Agentfehler behandelen.

D'Symptom gesäit aus wéi en kaputten Agent

Béid Adressen hei drënner ginn als Léisung proposéiert, an et sinn net dee selwechten Service. Eng /32 fir déi eng kopéieren, well se fir déi aner geschafft huet, ass genau de Wee, wéi en temporäre Workaround eng permanent Konfiguratioun gëtt, déi kee sech traut ewechzehuelen.

D'Reiefolleg, déi funktionéiert, ass fir d'éischt ze bestätegen, wéi eng Adress den octhege Ruff tatsächlech adresséiert, an dann ze liesen, wéi de Gast se opléist. Alles anescht ass roden mat extra Schrëtt an engem méi laange Ännerungsfenster.

168.63.129.16 ass keen ëffentlechen Zil

168.63.129.16 ass dem Azure seng speziell virtuell Plattformadress, an eng vun hire Rolle ass WireServer, deen den VM-Agent benotzt, fir mat der Fabric ze schwätzen. Microsoft dokumentéiert, datt den Agenttrafic op d'TCP-Porten 80 an 32526 disponibel bleiwe muss. Et ass keen normale Internethost, an et ass net eppes, wat e Full-Tunnel-VPN op en ewechgeleeënen Ausgang sollte droen. Dofir kann en Tunnel, deen gesond ausgesäit, den Agent nach ëmmer hungereg loossen.

D'Dokumentatioun vun der Plattformadress seet och, datt dës Adress net ënner benotzerdefinéierte Route steet, wat eng Eegeschaft vun der Azure-Fabric ass an net e Verspriechen iwwer Äre Gast. Eng lokal Firewallregel oder dem VPN-Client seng eege Routingpolitik kënnen de Wee nach ëmmer briechen, an keng vun deenen zwee lieft an der Routentabelle vum VNet.

Wann den Agent d'Probleem mellt, kontrolléiert de Servicestatus an de Wee op déi Adress, ier Dir eppes nei installéiert.

169.254.169.254 huet seng eege Reegelen

169.254.169.254 ass d'link-local Adress vum Azure Instance Metadata Service. Ufroe fir si hunn hir eege Bedingungen: de primären NIC an déi primär IP, eng DHCP-Konfiguratioun, déi d'Adress ënnerstëtzt, an d'Ëmgoe vun engem HTTP-Proxy. Si duerch en ewechgeleeënen VPN-Ausgang oder en arbiträren Internetgateway ze schécken ass net de Modell vum Zougang, deen Microsoft beschreift.

Déi Proxyklausel fänkt Leit, déi d'Route reparéiert hunn an nach ëmmer Feeler gesinn. En HTTP-Proxy am Gast ka IMDS briechen, während ip route get genee dech erwaarten Interface zréckgëtt, dofir kontrolléiert d'Proxyausnamen souwéi d'Routen.

Kleeft keng Metadaten-Antworte an en Supportticket, während Dir dat debuggt. Si kënnen Umeldungsinformatiounen an Instanzdetailer droen, déi den Tëschefall iwwerliewe.

Liest dem Gast seng Policy-Routing, net just d'Haapttabelle

Op engem Linux-Gast trennen dräi nëmme-Lie-Befehler d'Schichten: ip -4 rule show fir d'Politiksregelen, duerno ip -4 route get 168.63.129.16 an ip -4 route get 169.254.169.254 fir d'Entscheedungen, déi de Kernel tatsächlech hëlt. Fuert se virun an no der VPN-Verbindung aus. Den Ënnerscheed tëscht dësen zwee Ausgäng ass Ären Ännerungsset, an en ass nëtzlecher wéi all Vermutung doriwwer, wat de Client gemaach huet.

En VPN-Client, deen Politikregelen installéiert, kann d'Haapttabelle onberéiert loossen an dës Nokucken nach ëmmer ëmleeden. Dofir schéngt eng Léisung, déi just d'Haapttabelle verbessert, op engem Host ze funktionéieren an op deem nächsten näischt ze maachen. Gäscht mat multiple NICs fügen déiselwecht Probleem aus der anerer Richtung bäi, well d'Äntwert dovun ofhängt, wéi eng NIC an Quelladress d'Regel auswielt.

Widdersteht dem Rezept, dat béid /32-Routen duerch den ale Gateway bäisetzt. En link-local Plattformwee an en allgemengen WAN-Nächsten-Hop sinn verschidden Objeten, an eng global Ausnam verstoppt de richtege Politikkonflikt.

Haalt Administratioun an Erhuelung getrennt

Är SSH- oder RDP-Äntwert kann och vun engem Full-Tunnel-Default gefaange ginn, awer si zielt op d'observéiert Adress vum Administrateur an net op en Ennpunkt vun der Plattform. Diagnostizéiert se aus hirem eegene Request-Response-Puer, an haalt en onofhängege Erhuelungskanal wéi d'Seriekonsole, ier Dir d'VPN-Politik ännert. Wann eng Deployment d'VM nei start an den Agent en ongesonde Zoustand mellt, iwwerpréift déi opgehuewen Aktioun an de verantwortlechen Service amplaz unzehuelen, datt d'Routenännerung de Neistart verursaacht huet.

Da verifizéiert déi dräi Flëss getrennt: de private Ressource, deen Dir wierklech wollt, déi ënnerstëtzt Agent- a Plattformkommunikatioun, an den Administratiounswee. Een dovun z'erhuelen ass kee Beweis, datt déi aner zwee iwwerlieft hunn.

Schreift déi genehmegt Ausnam beim Proprietär vum Gastnetzwierk an der VPN-Konfiguratioun, inklusiv wat beim Neiverbannen an Neistart geschitt. Azure UDRs sinn net dem Gast seng Routentabelle, an se z'änneren reparéiert keng lokal Politikregel.