Virtuální počítač Azure se po spuštění VPN nedostane na IMDS ani WireServer

VM běží, klient VPN hlásí připojení a o pár minut později agent Azure začne hlásit, že není v pořádku. Někdy SSH přežije a Run Command z portálu ne, což lidi pošle k agentovi místo k routovací tabulce. Rozhodování hosta o předávání se změnilo, když se tunel zvedl, a dvě adresy platformy jsou obvykle první obětí. Beru to jako symptom routování, dříve než jako poruchu agenta.

Symptom vypadá jako rozbitý agent

Obě adresy níže se navrhují jako oprava, ale nejsou to stejné služby. Kopírování /32 pro jednu proto, že to fungovalo pro druhou, je přesně to, jak se dočasný obchvat stane trvalou konfigurací, kterou si nikdo netroufne odstranit.

Fungující pořadí je nejprve potvrdit, na kterou adresu selhávající volání skutečně míří, a pak přečíst, jak ji host překládá. Všechno ostatní je hádání s kroky navíc a delším oknem změn.

168.63.129.16 není veřejný cíl

168.63.129.16 je speciální virtuální adresa platformy Azure a jednou z jejích rolí je WireServer, který agent VM používá ke komunikaci s fabric. Microsoft dokumentuje, že provoz agenta na TCP porty 80 a 32526 musí zůstat dostupný. Není to běžný internetový hostitel a není to něco, co by VPN s plným tunelem měla nést na vzdálený výstup. Proto tunel, který vypadá zdravě, může agenta stále vyhladovět.

Dokumentace adresy platformy také uvádí, že tato adresa nepodléhá uživatelsky definovaným trasám, což je vlastnost fabric Azure, ne slib o vašem hostu. Místní pravidlo firewallu nebo vlastní routovací politika klienta VPN může cestu stále přerušit a ani jedno z toho nežije v routovací tabulce VNetu.

Pokud problém hlásí agent, zkontrolujte stav služby a cestu k této adrese, než cokoli přeinstalujete.

169.254.169.254 má svá vlastní pravidla

169.254.169.254 je link-local adresa služby Azure Instance Metadata Service. Požadavky na ni mají vlastní nároky: primární NIC a primární IP, konfiguraci DHCP, která adresu podporuje, a obejití jakéhokoli HTTP proxy. Posílat je přes vzdálený výstup VPN nebo libovolnou internetovou bránu není model přístupu, který Microsoft popisuje.

Tato klauzule o proxy chytá lidi, kteří trasu opravili a stále vidí selhání. HTTP proxy v hostu může rozbít IMDS, zatímco ip route get vrací přesně to rozhraní, které čekáte, takže kromě tras zkontrolujte i výjimky pro proxy.

Nevkládejte odpovědi metadat do tiketu podpory, když to ladíte. Mohou nést přihlašovací údaje a podrobnosti instance, které incident přežijí.

Čtěte policy routing hosta, ne jen hlavní tabulku

Na linuxovém hostu oddělují vrstvy tři příkazy jen pro čtení: ip -4 rule show pro pravidla politiky, pak ip -4 route get 168.63.129.16 a ip -4 route get 169.254.169.254 pro rozhodnutí, která jádro skutečně dělá. Spusťte je před připojením VPN a po něm. Rozdíl mezi těmito výstupy je váš soubor změn a je užitečnější než jakýkoli odhad, co klient udělal.

Klient VPN, který instaluje pravidla politiky, může nechat hlavní tabulku nedotčenou a přesto tato hledání přesměrovávat. Proto oprava jen hlavní tabulky vypadá, že na jednom hostiteli funguje, a na dalším nedělá nic. Hostitelé s více NIC přidávají stejný problém z druhé strany, protože odpověď závisí na tom, kterou NIC a zdrojovou adresu pravidlo vybere.

Vzepřete se receptu, který přidá obě trasy /32 přes starou bránu. Link-local cesta platformy a obecný další skok do WAN jsou různé objekty a plošná výjimka skrývá skutečný konflikt politik.

Držte administraci a obnovu odděleně

Vaši odpověď SSH nebo RDP může zachytit i default plného tunelu, ale míří na pozorovanou adresu správce, ne na kterýkoli koncový bod platformy. Diagnostikujte ji z její vlastní dvojice požadavek-odpověď a před změnou politiky VPN si držte nezávislý kanál obnovy, například sériovou konzoli. Pokud nasazení restartuje VM a agent hlásí, že není v pořádku, prozkoumejte zaznamenanou akci a odpovědnou službu, místo abyste předpokládali, že restart způsobil změna trasy.

Pak ověřte tři toky odděleně: soukromý prostředek, který jste skutečně chtěli, podporovanou komunikaci agenta a platformy a administrativní cestu. Obnova jednoho z nich není důkazem, že ostatní dva přežily.

Zapište schválenou výjimku pod vlastníka sítě hosta a konfigurace VPN, včetně toho, co se stane při opětovném připojení a restartu. UDR v Azure nejsou routovací tabulkou hosta a jejich úprava neopraví místní pravidlo politiky.