Azure-VM bereikt IMDS of WireServer niet meer na het starten van de VPN

De VM draait, de VPN-client zegt dat hij verbonden is, en een paar minuten later begint de Azure-agent een ongezonde status te melden. Soms overleeft SSH terwijl Run Command vanuit de portal niet werkt, waardoor mensen naar de agent kijken in plaats van naar de routetabel. De eigen doorschakelbeslissingen van de gast veranderden toen de tunnel omhoog kwam, en twee platformadressen zijn meestal de eerste slachtoffers. Ik behandel dat als een routing-symptoom voordat ik het als een agentstoring behandel.

Het symptoom lijkt op een kapotte agent

Beide adressen hieronder worden als oplossing aangedragen, en het zijn niet dezelfde dienst. Een /32 kopiëren voor de ene omdat het voor de andere werkte, is precies hoe een tijdelijke workaround een permanente configuratie wordt die niemand durft te verwijderen.

De volgorde die werkt is eerst vaststellen welk adres de mislukte aanroep echt raakt, en dan lezen hoe de gast het oplost. Al het andere is gissen met extra stappen en een langer wijzigingsvenster.

168.63.129.16 is geen publieke bestemming

168.63.129.16 is het speciale virtuele platformadres van Azure, en een van de rollen is WireServer, dat de VM-agent gebruikt om met de fabric te praten. Microsoft documenteert dat agentverkeer naar TCP-poorten 80 en 32526 beschikbaar moet blijven. Het is geen gewone internethost, en het is niet iets wat een full-tunnel-VPN naar een externe uitgang zou moeten dragen. Daarom kan een tunnel die er gezond uitziet de agent alsnog uithongeren.

De documentatie over het platformadres zegt ook dat dit adres niet onderhevig is aan door de gebruiker gedefinieerde routes, wat een eigenschap van de Azure-fabric is en geen belofte over je gast. Een lokale firewallregel of het eigen routingbeleid van de VPN-client kan het pad alsnog breken, en geen van beide leeft in de routetabel van het VNet.

Als de agent het probleem meldt, controleer dan de servicestatus en het pad naar dat adres voordat je iets opnieuw installeert.

169.254.169.254 heeft zijn eigen regels

169.254.169.254 is het link-local adres voor de Azure Instance Metadata Service. Verzoeken daarnaartoe hebben eigen eisen: de primaire NIC en het primaire IP, een DHCP-configuratie die het adres ondersteunt, en het omzeilen van elke HTTP-proxy. Ze via een externe VPN-uitgang of een willekeurige internetgateway versturen is niet het toegangsmodel dat Microsoft beschrijft.

Die proxyclausule vangt mensen die de route hebben gerepareerd en nog steeds fouten zien. Een HTTP-proxy in de gast kan IMDS breken terwijl ip route get precies de interface teruggeeft die je verwacht, dus controleer de proxy-uitsluitingen net zo goed als de routes.

Plak geen metadata-antwoorden in een supportticket terwijl je dit debugt. Ze kunnen inloggegevens en instantiedetails bevatten die het incident overleven.

Lees de policy routing van de gast, niet alleen de hoofdtabel

Op een Linux-gast scheiden drie alleen-lezen-opdrachten de lagen: ip -4 rule show voor de beleidsregels, dan ip -4 route get 168.63.129.16 en ip -4 route get 169.254.169.254 voor de beslissingen die de kernel echt neemt. Voer ze uit voor en nadat de VPN verbindt. Het verschil tussen die twee uitvoer is je wijzigingsset, en het is nuttiger dan welke gok dan ook over wat de client deed.

Een VPN-client die beleidsregels installeert kan de hoofdtabel ongemoeid laten en die opzoekingen alsnog omleiden. Daarom lijkt een oplossing die alleen de hoofdtabel aanpast op de ene host te werken en op de volgende niets te doen. Gasten met meerdere NIC's voegen hetzelfde probleem van de andere kant toe, omdat het antwoord afhangt van welke NIC en welk bronadres de regel kiest.

Weersta het recept dat beide /32-routes via de oude gateway toevoegt. Een link-local platformpad en een algemene WAN-next-hop zijn verschillende objecten, en een algemene uitzondering verbergt het echte beleidsconflict.

Houd beheer en herstel gescheiden

Je SSH- of RDP-antwoord kan ook worden gevangen door een full-tunnel-standaard, maar het richt zich op het waargenomen adres van de beheerder en niet op een platformeindpunt. Diagnosticeer het vanuit zijn eigen paar van verzoek en antwoord, en houd een onafhankelijk herstelkanaal zoals de seriële console achter de hand voordat je het VPN-beleid wijzigt. Als een uitrol de VM herstart en de agent een ongezonde status meldt, inspecteer dan de vastgelegde actie en de verantwoordelijke dienst in plaats van aan te nemen dat de routewijziging de herstart veroorzaakte.

Verifieer daarna de drie stromen apart: de private resource die je echt wilde, de ondersteunde agent- en platformcommunicatie, en het beheerpad. Het herstellen van één daarvan is geen bewijs dat de andere twee het hebben overleefd.

Schrijf de goedgekeurde uitzondering op naam van de eigenaar van het gastnetwerk en de VPN-configuratie, inclusief wat er gebeurt bij opnieuw verbinden en herstarten. Azure-UDR's zijn niet de routetabel van de gast, en ze bewerken lost geen lokale beleidsregel op.