Virtuálny počítač Azure sa po spustení VPN nedostane na IMDS ani WireServer

VM beží, klient VPN hlási pripojenie a o pár minút neskôr agent Azure začne hlásiť, že nie je v poriadku. Niekedy SSH prežije a Run Command z portálu nie, čo ľudí pošle k agentovi namiesto k smerovacej tabuľke. Rozhodovanie hosťa o preposielaní sa zmenilo, keď sa tunel zdvihol, a dve adresy platformy sú zvyčajne prvými obeťami. Beriem to ako príznak smerovania, skôr než ako poruchu agenta.

Príznak vyzerá ako pokazený agent

Obe adresy nižšie sa navrhujú ako oprava, ale nie sú to rovnaké služby. Kopírovanie /32 pre jednu preto, že to fungovalo pre druhú, je presne to, ako sa dočasný obchvat stane trvalou konfiguráciou, ktorú si nikto netrúfne odstrániť.

Fungujúce poradie je najprv potvrdiť, na ktorú adresu zlyhávajúce volanie skutočne mieri, a potom prečítať, ako ju hosť prekladá. Všetko ostatné je hádanie s krokmi navyše a dlhším oknom zmien.

168.63.129.16 nie je verejný cieľ

168.63.129.16 je špeciálna virtuálna adresa platformy Azure a jednou z jej rolí je WireServer, ktorý agent VM používa na komunikáciu s fabric. Microsoft dokumentuje, že prevádzka agenta na TCP porty 80 a 32526 musí zostať dostupná. Nie je to bežný internetový hostiteľ a nie je to niečo, čo by VPN s plným tunelom mala niesť na vzdialený výstup. Preto tunel, ktorý vyzerá zdravo, môže agenta stále vyhladovať.

Dokumentácia adresy platformy tiež uvádza, že táto adresa nepodlieha používateľsky definovaným trasám, čo je vlastnosť fabric Azure, nie sľub o vašom hosťovi. Lokálne pravidlo firewallu alebo vlastná smerovacia politika klienta VPN môžu cestu stále prerušiť a ani jedno z toho nežije v smerovacej tabuľke VNetu.

Ak problém hlási agent, skontrolujte stav služby a cestu k tejto adrese, než čokoľvek preinštalujete.

169.254.169.254 má svoje vlastné pravidlá

169.254.169.254 je link-local adresa služby Azure Instance Metadata Service. Požiadavky na ňu majú vlastné nároky: primárna NIC a primárna IP, konfigurácia DHCP, ktorá adresu podporuje, a obídenie akéhokoľvek HTTP proxy. Posielať ich cez vzdialený výstup VPN alebo ľubovoľnú internetovú bránu nie je model prístupu, ktorý Microsoft opisuje.

Tá klauzula o proxy chytá ľudí, ktorí trasu opravili a stále vidia zlyhania. HTTP proxy v hosťovi môže rozbiť IMDS, zatiaľ čo ip route get vracia presne to rozhranie, ktoré očakávate, takže okrem trás skontrolujte aj výnimky pre proxy.

Nevkladajte odpovede metadát do tiketu podpory, keď to ladíte. Môžu niesť prihlasovacie údaje a podrobnosti inštancie, ktoré incident prežijú.

Čítajte policy routing hosťa, nielen hlavnú tabuľku

Na linuxovom hosťovi oddeľujú vrstvy tri príkazy iba na čítanie: ip -4 rule show pre pravidlá politiky, potom ip -4 route get 168.63.129.16 a ip -4 route get 169.254.169.254 pre rozhodnutia, ktoré jadro skutočne robí. Spustite ich pred pripojením VPN a po ňom. Rozdiel medzi týmito výstupmi je váš súbor zmien a je užitočnejší než akýkoľvek odhad, čo klient urobil.

Klient VPN, ktorý inštaluje pravidlá politiky, môže nechať hlavnú tabuľku nedotknutú a napriek tomu tieto vyhľadávania presmerovávať. Preto oprava len hlavnej tabuľky vyzerá, že na jednom hostiteľovi funguje, a na ďalšom nerobí nič. Hostitelia s viacerými NIC pridávajú rovnaký problém z druhej strany, pretože odpoveď závisí od toho, ktorú NIC a zdrojovú adresu pravidlo vyberie.

Vzoprite sa receptu, ktorý pridá obe trasy /32 cez starú bránu. Link-local cesta platformy a všeobecný ďalší skok do WAN sú rôzne objekty a plošná výnimka skrýva skutočný konflikt politík.

Držte administráciu a obnovu oddelene

Vašu odpoveď SSH alebo RDP môže zachytiť aj default plného tunela, ale mieri na pozorovanú adresu správcu, nie na koncový bod platformy. Diagnostikujte ju z jej vlastnej dvojice požiadavka-odpoveď a pred zmenou politiky VPN si držte nezávislý kanál obnovy, napríklad sériovú konzolu. Ak nasadenie reštartuje VM a agent hlási, že nie je v poriadku, preskúmajte zaznamenanú akciu a zodpovednú službu, namiesto toho, aby ste predpokladali, že reštart spôsobila zmena trasy.

Potom overte tri toky oddelene: súkromný prostriedok, ktorý ste skutočne chceli, podporovanú komunikáciu agenta a platformy a administratívnu cestu. Obnova jedného z nich nie je dôkazom, že ostatné dva prežili.

Zapíšte schválenú výnimku pod vlastníka siete hosťa a konfigurácie VPN, vrátane toho, čo sa stane pri opätovnom pripojení a reštarte. UDR v Azure nie sú smerovacou tabuľkou hosťa a ich úprava neopraví lokálne pravidlo politiky.