Azure-VM når inte IMDS eller WireServer efter att VPN startar

VM:en är uppe, VPN-klienten säger att den är ansluten, och några minuter senare börjar Azure-agenten rapportera ohälsosamt tillstånd. Ibland överlever SSH medan Run Command från portalen inte gör det, vilket får folk att titta på agenten i stället för routningstabellen. Gästens egna vidarebefordringsbeslut ändrades när tunneln kom upp, och två plattformsadresser är vanligtvis de första offren. Jag behandlar det som ett routningssymtom innan jag behandlar det som ett agentfel.

Symtomet ser ut som en trasig agent

Båda adresserna nedan föreslås som en åtgärd, och de är inte samma tjänst. Att kopiera en /32 för den ena eftersom det fungerade för den andra är precis hur en tillfällig kringgång blir en permanent konfiguration som ingen vågar ta bort.

Ordningen som fungerar är att först bekräfta vilken adress det misslyckade anropet faktiskt riktar sig mot, och sedan läsa hur gästen löser upp den. Allt annat är gissningar med extra steg och ett längre ändringsfönster.

168.63.129.16 är inte en offentlig destination

168.63.129.16 är Azures särskilda virtuella plattformsadress, och en av rollerna är WireServer, som VM-agenten använder för att prata med fabric. Microsoft dokumenterar att agenttrafik till TCP-portarna 80 och 32526 måste förbli tillgänglig. Det är inte en vanlig internetvärd, och det är inte något som en fulltunnel-VPN bör bära till en fjärrutgång. Därför kan en tunnel som ser frisk ut ändå svälta agenten.

Dokumentationen för plattformsadressen säger också att denna adress inte omfattas av användardefinierade rutter, vilket är en egenskap hos Azure-fabric och inte ett löfte om din gäst. En lokal brandväggsregel eller VPN-klientens egen routningspolicy kan fortfarande bryta vägen, och ingen av dem bor i VNet:ets routningstabell.

Om det är agenten som rapporterar problemet, kontrollera tjänstens status och vägen till den adressen innan du installerar om något.

169.254.169.254 har sina egna regler

169.254.169.254 är link-local-adressen för Azure Instance Metadata Service. Förfrågningar dit har egna krav: den primära NIC:en och primära IP:n, en DHCP-konfiguration som stöder adressen och kringgående av alla HTTP-proxyer. Att skicka dem via en fjärr-VPN-utgång eller en godtycklig internetgateway är inte den åtkomstmodell Microsoft beskriver.

Den proxyklausulen fångar folk som har åtgärdat rutten och fortfarande ser fel. En HTTP-proxy i gästen kan bryta IMDS medan ip route get returnerar exakt det gränssnitt du förväntar dig, så kontrollera proxyundantagen liksom ruttarna.

Klistra inte in metadata-svar i ett supportärende medan du felsöker detta. De kan bära autentiseringsuppgifter och instansdetaljer som överlever incidenten.

Läs gästens policy routing, inte bara huvudtabellen

På en Linux-gäst skiljer tre skrivskyddade kommandon lagren: ip -4 rule show för policyreglerna, sedan ip -4 route get 168.63.129.16 och ip -4 route get 169.254.169.254 för de beslut som kärnan faktiskt fattar. Kör dem före och efter att VPN ansluter. Skillnaden mellan de två utdata är din ändringsuppsättning, och den är mer användbar än någon gissning om vad klienten gjorde.

En VPN-klient som installerar policyregler kan lämna huvudtabellen orörd och ändå omdirigera dessa uppslagningar. Det är därför en åtgärd som bara rör huvudtabellen verkar fungera på en värd och inte gör något på nästa. Gäster med flera NIC:ar lägger till samma problem från andra hållet, eftersom svaret beror på vilken NIC och källadress regeln väljer.

Motstå receptet som lägger till båda /32-rutterna via den gamla gatewayen. En link-local plattformsväg och ett allmänt WAN-nästa hopp är olika objekt, och ett blanket-undantag döljer den verkliga policykonflikten.

Håll administration och återställning åtskilda

Ditt SSH- eller RDP-svar kan också fångas av en fulltunnelstandard, men det riktar sig mot administratörens observerade adress och inte mot en plattformsändpunkt. Diagnostisera det från sitt eget par av begäran och svar, och håll en oberoende återställningskanal som seriekonsolen innan du ändrar VPN-policyn. Om en distribution startar om VM:en och agenten rapporterar ohälsosamt tillstånd, undersök den registrerade åtgärden och den ansvariga tjänsten i stället för att anta att ruttändringen orsakade omstarten.

Verifiera sedan de tre flödena separat: den privata resurs du faktiskt ville ha, den stödda agent- och plattformskommunikationen och administrationsvägen. Att återställa en av dem är inte bevis för att de andra två överlevde.

Skriv det godkända undantaget hos ägaren av gästnätverket och VPN-konfigurationen, inklusive vad som händer vid återanslutning och omstart. Azure UDR:er är inte gästens routningstabell, och att redigera dem åtgärdar inte en lokal policyregel.