Azure-VM kan ikke nå IMDS eller WireServer, efter at VPN'en starter

VM'en kører, VPN-klienten siger, at den er forbundet, og få minutter senere begynder Azure-agenten at rapportere, at den ikke er sund. Nogle gange overlever SSH, mens Run Command fra portalen ikke gør, hvilket får folk til at kigge på agenten i stedet for rutetabellen. Gæstens egne videresendelsesbeslutninger ændrede sig, da tunnelen kom op, og to platformadresser er normalt de første ofre. Jeg behandler det som et routing-symptom, før jeg behandler det som en agentfejl.

Symptomet ligner en ødelagt agent

Begge adresser nedenfor foreslås som en løsning, og de er ikke den samme tjeneste. At kopiere en /32 for den ene, fordi det virkede for den anden, er præcis, hvordan en midlertidig omvej bliver en permanent konfiguration, som ingen tør fjerne.

Den rækkefølge, der virker, er at bekræfte, hvilken adresse det fejlende kald faktisk rammer, og derefter læse, hvordan gæsten slår den op. Alt andet er gætteri med ekstra trin og et længere ændringsvindue.

168.63.129.16 er ikke en offentlig destination

168.63.129.16 er Azures særlige virtuelle platformadresse, og en af dens roller er WireServer, som VM-agenten bruger til at tale med fabric'et. Microsoft dokumenterer, at agenttrafik til TCP-portene 80 og 32526 skal forblive tilgængelig. Det er ikke en almindelig internetvært, og det er ikke noget, en full-tunnel VPN bør bære til en fjernudgang. Derfor kan en tunnel, der ser sund ud, stadig sulte agenten.

Dokumentationen for platformsadressen siger også, at denne adresse ikke er underlagt brugerdefinerede ruter, hvilket er en egenskab ved Azures fabric og ikke et løfte om din gæst. En lokal firewallregel eller VPN-klientens egen routingpolitik kan stadig bryde stien, og ingen af dem bor i VNet'ets rutetabell.

Hvis det er agenten, der rapporterer problemer, skal du kontrollere tjenestetilstanden og stien til den adresse, før du geninstallerer noget.

169.254.169.254 har sine egne regler

169.254.169.254 er link-local-adressen for Azure Instance Metadata Service. Anmodninger til den har deres egne krav: den primære NIC og primære IP, en DHCP-konfiguration, der understøtter adressen, og omgåelse af enhver HTTP-proxy. At sende dem gennem en fjern VPN-udgang eller en vilkårlig internetgateway er ikke den adgangsmodel, Microsoft beskriver.

Den proxyklausul fanger folk, der har rettet ruten og stadig ser fejl. En gæste-HTTP-proxy kan bryde IMDS, mens ip route get returnerer præcis det interface, du forventer, så tjek proxyundtagelser såvel som ruter.

Indsæt ikke metadata-svar i en supportbillet, mens du fejlfinder. De kan bære legitimationsoplysninger og instansdetaljer, der overlever hændelsen.

Læs gæstens policy routing, ikke kun hovedtabellen

På en Linux-gæst adskiller tre skrivebeskyttede kommandoer lagene: ip -4 rule show for politikreglerne, derefter ip -4 route get 168.63.129.16 og ip -4 route get 169.254.169.254 for de beslutninger, kernen faktisk træffer. Kør dem før og efter, at VPN'en forbinder. Forskellen mellem de to output er dit ændringssæt, og det er mere nyttigt end nogen gætte om, hvad klienten gjorde.

En VPN-klient, der installerer politikregler, kan lade hovedtabellen være urørt og stadig omdirigere de opslag. Derfor ser en løsning, der kun ændrer hovedtabellen, ud til at virke på én vært og gør intet på den næste. Værter med flere NIC'er tilføjer det samme problem fra den anden side, fordi svaret afhænger af, hvilken NIC og kildeadresse reglen vælger.

Modstå opskriften, der tilføjer begge /32-ruter gennem den gamle gateway. En link-local platformsti og et generelt WAN-next hop er forskellige objekter, og en blanket undtagelse skjuler den reelle politikkonflikt.

Hold administration og gendannelse adskilt

Dit SSH- eller RDP-svar kan også blive opfanget af et full-tunnel default, men det rammer administratorernes observerede adresse i stedet for en af platformsendepunkterne. Diagnosticér det ud fra dets eget anmodning-svar-par, og hold en uafhængig gendannelseskanal såsom serielkonsollen, før du ændrer VPN-politik. Hvis en udrulning genstarter VM'en, og agenten rapporterer, at den ikke er sund, skal du undersøge den registrerede handling og den ansvarlige tjeneste i stedet for at antage, at ruteændringen forårsagede genstarten.

Bekræft derefter de tre strømme separat: den private ressource, du faktisk ønskede, den understøttede agent- og platformkommunikation og administrationsstien. At gendanne en af dem er ikke bevis for, at de to andre overlevede.

Skriv den godkendte undtagelse hos ejeren af gæstenettet og VPN-konfigurationen, inklusive hvad der sker ved genopkobling og genstart. Azure UDR'er er ikke gæstens rutetabell, og redigering af dem retter ikke en lokal politikregel.