Azure-VM når ikke IMDS eller WireServer etter at VPN-en starter

VM-en er oppe, VPN-klienten sier den er tilkoblet, og noen minutter senere begynner Azure-agenten å rapportere dårlig tilstand. Noen ganger overlever SSH mens Run Command fra portalen ikke gjør det, noe som sender folk til agenten i stedet for rutetabellen. Gjestens egne videresendingsbeslutninger endret seg da tunnelen kom opp, og to plattformadresser er vanligvis de første ofrene. Jeg behandler det som et rutingsymptom før jeg behandler det som en agentfeil.

Symptomet ser ut som en ødelagt agent

Begge adressene nedenfor foreslås som en løsning, og de er ikke samme tjeneste. Å kopiere en /32 for den ene fordi det virket for den andre er nettopp hvordan en midlertidig omvei blir en permanent konfigurasjon ingen tør fjerne.

Rekkefølgen som virker er å bekrefte hvilken adresse det feilende kallet faktisk treffer, og deretter lese hvordan gjesten løser den. Alt annet er gjetting med ekstra trinn og et lengre endringsvindu.

168.63.129.16 er ikke en offentlig destinasjon

168.63.129.16 er Azures spesielle virtuelle plattformadresse, og en av rollene er WireServer, som VM-agenten bruker for å snakke med fabric. Microsoft dokumenterer at agenttrafikk til TCP-portene 80 og 32526 må forbli tilgjengelig. Det er ikke en vanlig internettvert, og det er ikke noe en fulltunnel-VPN bør bære til en ekstern utgang. Derfor kan en tunnel som ser sunn ut fortsatt sulte agenten.

Dokumentasjonen for plattformadressen sier også at denne adressen ikke er underlagt brukerdefinerte ruter, noe som er en egenskap ved Azure-fabric og ikke et løfte om gjesten din. En lokal brannmurregel eller VPN-klientens egen ruteringspolicy kan fortsatt bryte stien, og ingen av dem bor i VNet-ets rutetabell.

Hvis det er agenten som melder problemet, sjekk tjenestetilstanden og stien til den adressen før du installerer noe på nytt.

169.254.169.254 har sine egne regler

169.254.169.254 er link-local-adressen for Azure Instance Metadata Service. Forespørsler dit har egne krav: primær NIC og primær IP, en DHCP-konfigurasjon som støtter adressen, og omgåelse av enhver HTTP-proxy. Å sende dem gjennom en ekstern VPN-utgang eller en vilkårlig internettgateway er ikke tilgangsmodellen Microsoft beskriver.

Den proxy-klausulen fanger folk som har fikset ruten og fortsatt ser feil. En HTTP-proxy i gjesten kan bryte IMDS mens ip route get returnerer nøyaktig grensesnittet du forventer, så sjekk proxy-unntakene like godt som rutene.

Ikke lim inn metadata-svar i en støttebillett mens du feilsøker dette. De kan bære legitimasjon og instansdetaljer som overlever hendelsen.

Les gjestens policy routing, ikke bare hovedtabellen

På en Linux-gjest skiller tre skrivebeskyttede kommandoer lagene: ip -4 rule show for policy-reglene, deretter ip -4 route get 168.63.129.16 og ip -4 route get 169.254.169.254 for beslutningene kjernen faktisk tar. Kjør dem før og etter at VPN-en kobler til. Forskjellen mellom de to utdataene er endringssettet ditt, og det er nyttigere enn noen gjetning om hva klienten gjorde.

En VPN-klient som installerer policy-regler kan la hovedtabellen være urørt og fortsatt omdirigere disse oppslagene. Derfor ser en løsning som bare rører hovedtabellen ut til å virke på én vert og gjør ingenting på den neste. Gjester med flere NIC legger til samme problem fra den andre siden, fordi svaret avhenger av hvilken NIC og kildeadresse regelen velger.

Motstå oppskriften som legger til begge /32-rutene gjennom den gamle gatewayen. En link-local plattformsti og et generelt WAN-neste hopp er forskjellige objekter, og et blanket-unntak skjuler den virkelige policykonflikten.

Hold administrasjon og gjenoppretting adskilt

SSH- eller RDP-svaret ditt kan også fanges av en fulltunnel-standard, men det retter seg mot administratorens observerte adresse og ikke en av plattformendepunktene. Diagnostiser det fra sitt eget par av forespørsel og svar, og hold en uavhengig gjenopprettingskanal som seriekonsollen før du endrer VPN-policyen. Hvis en utrulling restarter VM-en og agenten rapporterer dårlig tilstand, undersøk den registrerte handlingen og den ansvarlige tjenesten i stedet for å anta at ruteendringen forårsaket omstarten.

Bekreft deretter de tre strømmene hver for seg: den private ressursen du faktisk ønsket, den støttede agent- og plattformkommunikasjonen, og administrasjonsstien. Å gjenopprette en av dem er ikke bevis for at de to andre overlevde.

Skriv den godkjente unntaket hos eieren av gjestenettverket og VPN-konfigurasjonen, inkludert hva som skjer ved gjenoppkobling og omstart. Azure UDR-er er ikke gjestens rutetabell, og å redigere dem vil ikke fikse en lokal policy-regel.