Az Azure VM nem éri el az IMDS-t vagy a WireServert a VPN indulása után

A VM fut, a VPN-kliens kapcsolódottnak jelenti magát, és néhány perccel később az Azure-ügynök elkezd nem megfelelő állapotot jelenteni. Néha az SSH túlél, míg a portál Run Command nem, ami az embereket az ügynökhöz küldi az útválasztási tábla helyett. A vendég saját továbbítási döntései megváltoztak, amikor az alagút felállt, és általában két platformcím az első áldozat. Ezt útválasztási tünetként kezelem, mielőtt ügynökhibának tekinteném.

A tünet törött ügynöknek látszik

Az alábbi két cím javításként javasolt, pedig nem ugyanaz a szolgáltatás. A /32 másolása az egyikhez, mert a másiknál működött, pontosan így válik egy ideiglenes kerülőút olyan állandó konfigurációvá, amelyet senki nem mer eltávolítani.

A működő sorrend: először erősítse meg, melyik címet célozza valójában a sikertelen hívás, majd olvassa el, hogyan oldja fel a vendég. Minden más találgatás extra lépésekkel és hosszabb változási ablakkal.

A 168.63.129.16 nem nyilvános cél

A 168.63.129.16 az Azure speciális virtuális platformcíme, és az egyik szerepe a WireServer, amelyet a VM-ügynök a fabric-kal való kommunikációhoz használ. A Microsoft dokumentálja, hogy az ügynök TCP 80 és 32526 port felé irányuló forgalmának elérhetőnek kell maradnia. Ez nem közönséges internethoszt, és nem olyasmi, amit egy teljes alagutas VPN-nek távoli kijáratra kellene vinnie. Ezért egy egészségesnek látszó alagút is éheztetheti az ügynököt.

A platformcím dokumentációja azt is mondja, hogy ez a cím nem esik felhasználó által meghatározott útvonalak alá, ami az Azure fabric tulajdonsága, nem pedig ígéret a vendégéről. Egy helyi tűzfal-szabály vagy a VPN-kliens saját útválasztási szabályzata továbbra is megtörheti az utat, és egyik sem él a VNet útválasztási táblájában.

Ha az ügynök jelenti a problémát, ellenőrizze a szolgáltatás állapotát és az ahhoz a címhez vezető utat, mielőtt bármit újratelepít.

A 169.254.169.254-nek saját szabályai vannak

A 169.254.169.254 az Azure Instance Metadata Service link-local címe. A hozzá intézett kéréseknek saját követelményeik vannak: az elsődleges NIC és elsődleges IP, a címet támogató DHCP-konfiguráció, valamint bármely HTTP-proxy megkerülése. Távoli VPN-kijáraton vagy önkényes internetátjárón át küldeni őket nem az a hozzáférési modell, amelyet a Microsoft leír.

Ez a proxyfeltétel azokat kapja el, akik megjavították az útvonalat és mégis hibákat látnak. A vendég HTTP-proxyja megtörheti az IMDS-t, miközben a ip route get pontosan a várt interfészt adja vissza, ezért az útvonalak mellett a proxykivételeket is ellenőrizze.

Ne illesszen metaadat-válaszokat támogatási jegybe, miközben ezt hibakeresi. Azok olyan hitelesítő adatokat és példányrészleteket hordozhatnak, amelyek túlélik az incidenst.

A vendég szabályalapú útválasztását olvassa, ne csak a fő táblát

Linux-vendégen három csak olvasható parancs választja el a rétegeket: a ip -4 rule show a szabályzati szabályokhoz, majd a ip -4 route get 168.63.129.16 és a ip -4 route get 169.254.169.254 azokhoz a döntésekhez, amelyeket a kernel valóban meghoz. Futtassa őket a VPN csatlakozása előtt és után. A két kimenet közötti különbség a változási készlete, és hasznosabb minden találgatásnál arról, mit tett a kliens.

A szabályzati szabályokat telepítő VPN-kliens érintetlenül hagyhatja a fő táblát, miközben továbbra is átirányítja ezeket a kereséseket. Ezért tűnik úgy, hogy a csak fő táblát javító megoldás működik az egyik hoszton, a következőn pedig semmit sem tesz. A több NIC-s vendégek ugyanezt a problémát hozzák a másik irányból, mert a válasz attól függ, melyik NIC-t és forráscímet választja a szabály.

Ellenálljon a receptnek, amely mindkét /32 útvonalat a régi átjárón keresztül adja hozzá. A link-local platformút és az általános WAN-következő ugrás különböző objektumok, és az általános kivétel elrejti a valódi szabályzatkonfliktust.

Tartsa külön az adminisztrációt és a helyreállítást

Az SSH- vagy RDP-válaszát is elkaphatja egy teljes alagutas alapértelmezés, de az a rendszergazda megfigyelt címét célozza, nem valamelyik platformvégpontot. Diagnosztizálja a saját kérés-válasz párjából, és a VPN-szabályzat módosítása előtt tartson fenn független helyreállítási csatornát, például a soros konzolt. Ha egy telepítés újraindítja a VM-et, és az ügynök nem megfelelő állapotot jelent, vizsgálja meg a rögzített műveletet és a felelős szolgáltatást, ahelyett hogy feltételezné, hogy az útvonalváltozás okozta az újraindítást.

Ezután ellenőrizze külön a három folyamot: a ténylegesen kívánt privát erőforrást, a támogatott ügynök- és platformkommunikációt, valamint az adminisztrációs utat. Az egyik helyreállítása nem bizonyítja, hogy a másik kettő túlélte.

A jóváhagyott kivételt a vendéghálózat és a VPN-konfiguráció tulajdonosánál rögzítse, beleértve azt is, mi történik újracsatlakozáskor és újraindításkor. Az Azure UDR-ek nem a vendég útválasztási táblája, és szerkesztésük nem javít meg egy helyi szabályzati szabályt.