Vm Azure ne doseže IMDS ali WireServer po zagonu VPN

VM teče, odjemalec VPN pravi, da je povezan, in nekaj minut pozneje agent Azure začne poročati o nezdravem stanju. Včasih SSH preživi, Run Command iz portala pa ne, kar ljudi usmeri k agentu namesto k usmerjevalni tabeli. Odločitve gostujočega sistema o posredovanju so se spremenile, ko se je tunel dvignil, in dva naslova platforme sta običajno prvi žrtvi. To obravnavam kot simptom usmerjanja, preden to obravnavam kot okvaro agenta.

Simptom je videti kot pokvarjen agent

Oba spodnja naslova sta predlagana kot popravek, pa nista ista storitev. Kopiranje /32 za enega, ker je delovalo za drugega, je natanko način, kako začasna rešitev postane trajna konfiguracija, ki si je nihče ne upa odstraniti.

Delujoč vrstni red je najprej potrditi, kateri naslov neuspešni klic zares cilja, nato prebrati, kako ga gost razreši. Vse drugo je ugibanje z dodatnimi koraki in daljšim oknom sprememb.

168.63.129.16 ni javni cilj

168.63.129.16 je poseben virtualni naslov platforme Azure, ena od njegovih vlog pa je WireServer, ki ga agent VM uporablja za pogovor s fabric. Microsoft dokumentira, da mora promet agenta na TCP vrata 80 in 32526 ostati na voljo. To ni običajen internetni gostitelj in ni nekaj, kar bi VPN s polnim tunelom moral nositi na oddaljeni izhod. Zato lahko tunel, ki je videti zdrav, agenta še vedno strada.

Dokumentacija naslova platforme tudi pravi, da ta naslov ni podvržen uporabniško določenim potem, kar je lastnost fabric Azure in ne obljuba o vašem gostu. Lokalno pravilo požarnega zidu ali lastna usmerjevalna politika odjemalca VPN lahko pot še vedno prekineta, in nobeno od tega ne živi v usmerjevalni tabeli VNeta.

Če težavo sporoča agent, preverite stanje storitve in pot do tega naslova, preden karkoli znova namestite.

169.254.169.254 ima svoja pravila

169.254.169.254 je link-local naslov storitve Azure Instance Metadata Service. Zahteve nanj imajo svoje pogoje: primarni NIC in primarni IP, konfiguracija DHCP, ki podpira naslov, in obhod kakršnega koli proxyja HTTP. Pošiljanje skozi oddaljeni izhod VPN ali poljubno internetno prehodnico ni model dostopa, ki ga opisuje Microsoft.

Ta klavzula o proxyju ujame ljudi, ki so pot popravili in še vedno vidijo napake. Proxy HTTP v gostu lahko pokvari IMDS, medtem ko ip route get vrne natanko vmesnik, ki ga pričakujete, zato poleg poti preverite tudi izjeme za proxy.

Ne lepite odgovorov metapodatkov v zahtevek za podporo, medtem ko to razhroščujete. Lahko nosijo poverilnice in podrobnosti instance, ki preživijo incident.

Berite usmerjanje politike gosta, ne le glavne tabele

Na gostu Linux trije ukazi samo za branje ločijo plasti: ip -4 rule show za pravila politike, nato ip -4 route get 168.63.129.16 in ip -4 route get 169.254.169.254 za odločitve, ki jih jedro zares sprejme. Zaženite jih pred povezavo VPN in po njej. Razlika med tema izpisoma je vaš nabor sprememb in je bolj uporabna od vsakega ugibanja, kaj je odjemalec naredil.

Odjemalec VPN, ki namešča pravila politike, lahko pusti glavno tabelo nedotaknjeno in še vedno preusmerja te poizvedbe. Zato se popravek samo glavne tabele zdi, da deluje na enem gostitelju, na naslednjem pa ne naredi ničesar. Gostje z več NIC dodajo isto težavo z druge strani, ker je odgovor odvisen od tega, kateri NIC in izvorni naslov izbere pravilo.

Uprite se receptu, ki doda obe poti /32 skozi stari prehod. Link-local pot platforme in splošni naslednji skok v WAN sta različna objekta, splošna izjema pa skriva resnični konflikt politik.

Upravljanje in obnovo imejte ločeno

Vaš odgovor SSH ali RDP lahko ujame tudi privzeta pot polnega tunela, vendar cilja na opaženi naslov skrbnika in ne na končno točko platforme. Diagnosticirajte ga iz njegovega lastnega para zahteva-odgovor in pred spremembo politike VPN imejte neodvisen kanal za obnovitev, na primer serijsko konzolo. Če namestitev znova zažene VM in agent sporoči nezdravo stanje, preglejte zabeleženo dejanje in odgovorno storitev, namesto da bi domnevali, da je ponovni zagon povzročila sprememba poti.

Nato preverite tri tokove ločeno: zasebni vir, ki ste ga resnično želeli, podprto komunikacijo agenta in platforme ter upravljalno pot. Obnovitev enega ni dokaz, da sta druga dva preživela.

Odobreno izjemo zapišite pri lastniku gostujočega omrežja in konfiguracije VPN, vključno s tem, kaj se zgodi ob ponovni povezavi in ponovnem zagonu. UDR v Azure niso usmerjevalna tabela gosta in njihovo urejanje ne bo popravilo lokalnega pravila politike.