Azure-VM når ikkje IMDS eller WireServer etter at VPN-en startar

VM-en er oppe, VPN-klienten seier at han er tilkopla, og nokre minutt seinare byrjar Azure-agenten å rapportere dårleg tilstand. Nokre gonger overlever SSH medan Run Command frå portalen ikkje gjer det, noko som sender folk til agenten i staden for rutetabellen. Gjesten sine eigne vidaresendingsavgjerder endra seg då tunnelen kom opp, og to plattformadresser er vanlegvis dei første offera. Eg handsamar det som eit rutingsymptom før eg handsamar det som ein agentfeil.

Symptomet ser ut som ein øydelagd agent

Begge adressene nedanfor blir føreslått som ei løysing, og dei er ikkje same tenesta. Å kopiere ein /32 for den eine fordi det verka for den andre er nettopp korleis ei mellombels omveg blir ein permanent konfigurasjon ingen tør fjerne.

Rekkefølgja som verkar er å stadfeste kva adresse det feilande kallet faktisk treffer, og deretter lese korleis gjesten løyser ho. Alt anna er gissing med ekstra steg og eit lengre endringsvindauge.

168.63.129.16 er ikkje ein offentleg destinasjon

168.63.129.16 er den spesielle virtuelle plattformadressa til Azure, og ein av rollene er WireServer, som VM-agenten brukar for å snakke med fabric. Microsoft dokumenterer at agenttrafikk til TCP-portane 80 og 32526 må halde fram med å vere tilgjengeleg. Det er ikkje ein vanleg internettvert, og det er ikkje noko ein fulltunnel-VPN bør bera til ein ekstern utgang. Difor kan ein tunnel som ser sunn ut framleis svelte agenten.

Dokumentasjonen for plattformadressa seier òg at denne adressa ikkje er underlagd brukardefinerte ruter, noko som er ein eigenskap ved Azure-fabric og ikkje eit løfte om gjesten din. Ein lokal brannmurregel eller VPN-klienten si eiga ruteringspolitikk kan framleis bryte stien, og ingen av dei bur i rutetabellen til VNet-et.

Viss det er agenten som melder problemet, sjekk tenestetilstanden og stien til den adressa før du installerer noko på nytt.

169.254.169.254 har sine eigne reglar

169.254.169.254 er link-local-adressa for Azure Instance Metadata Service. Førespurnader dit har eigne krav: primær NIC og primær IP, ein DHCP-konfigurasjon som støttar adressa, og omgåing av kvar einaste HTTP-proxy. Å sende dei gjennom ein ekstern VPN-utgang eller ein vilkårleg internettgateway er ikkje tilgangsmodellen Microsoft skildrar.

Den proxy-klausulen fangar folk som har fiksa ruta og framleis ser feil. Ein HTTP-proxy i gjesten kan bryte IMDS medan ip route get returnerer nøyaktig grensesnittet du ventar, så sjekk proxy-unntaka like godt som rutene.

Ikkje lim inn metadata-svar i ein støttebillett medan du feilsøkjer dette. Dei kan bera legitimasjon og instansdetaljar som overlever hendinga.

Les policy routing til gjesten, ikkje berre hovudtabellen

På ein Linux-gjest skil tre skriveverna kommandoar laga: ip -4 rule show for policy-reglane, deretter ip -4 route get 168.63.129.16 og ip -4 route get 169.254.169.254 for avgjerdene kjernen faktisk tek. Køyr dei før og etter at VPN-en koplar til. Skilnaden mellom dei to utdata er endringssettet ditt, og det er nyttigare enn noka gissing om kva klienten gjorde.

Ein VPN-klient som installerer policy-reglar kan la hovudtabellen vere urørt og framleis omdirigere desse oppslaga. Difor ser ei løysing som berre rører hovudtabellen ut til å verke på ein vert og gjer ingenting på den neste. Gjester med fleire NIC legg til same problemet frå den andre sida, fordi svaret avheng av kva NIC og kjeldeadresse regelen vel.

Motstå oppskrifta som legg til begge /32-rutene gjennom den gamle gatewayen. Ein link-local plattformsti og eit allment WAN-neste hopp er ulike objekt, og eit blanket-unntak skjuler den verkelege policykonflikten.

Hald administrasjon og gjenoppretting åtskilde

SSH- eller RDP-svaret ditt kan òg bli fanga av ein fulltunnel-standard, men det rettar seg mot den observerte adressa til administratoren og ikkje eit plattformendepunkt. Diagnostiser det frå sitt eige par av førespurnad og svar, og hald ein uavhengig gjenopprettingskanal som seriekkonsollen før du endrar VPN-policyen. Viss ein utrulling startar VM-en på nytt og agenten rapporterer dårleg tilstand, undersøk den registrerte handlinga og den ansvarlege tenesta i staden for å anta at ruteendringa førte til omstarten.

Stadfest deretter dei tre straumane kvar for seg: den private ressursen du faktisk ville ha, den støtta agent- og plattformkommunikasjonen, og administrasjonsstien. Å gjenopprette ein av dei er ikkje prov på at dei to andre overlevde.

Skriv det godkjende unntaket hos eigaren av gjestenettverket og VPN-konfigurasjonen, inkludert kva som skjer ved gjenoppkopling og omstart. Azure UDR-ar er ikkje rutetabellen til gjesten, og å redigere dei vil ikkje fikse ein lokal policy-regel.