Maszyna wirtualna Azure nie dociera do IMDS ani WireServer po uruchomieniu VPN

Maszyna działa, klient VPN zgłasza połączenie, a kilka minut później agent Azure zaczyna raportować zły stan. Czasem SSH przeżywa, a Run Command z portalu nie, co kieruje ludzi do agenta zamiast do tablicy tras. Decyzje o przekazywaniu gościa zmieniły się, gdy tunel się podniósł, a dwa adresy platformy są zwykle pierwszymi ofiarami. Traktuję to jako objaw rutingu, zanim potraktuję jako awarię agenta.

Objaw wygląda jak zepsuty agent

Oba adresy poniżej są proponowane jako poprawka, a to nie ta sama usługa. Kopiowanie /32 dla jednego, bo zadziałało dla drugiego, to właśnie sposób, w jaki tymczasowe obejście staje się stałą konfiguracją, której nikt nie odważy się usunąć.

Działająca kolejność to najpierw potwierdzić, który adres faktycznie jest celem nieudanego wywołania, a potem przeczytać, jak gość go rozwiązuje. Wszystko inne to zgadywanie z dodatkowymi krokami i dłuższym oknem zmian.

168.63.129.16 nie jest celem publicznym

168.63.129.16 to specjalny wirtualny adres platformy Azure, a jedna z jego ról to WireServer, którego agent VM używa do rozmowy z fabric. Microsoft dokumentuje, że ruch agenta do portów TCP 80 i 32526 musi pozostać dostępny. To nie zwykły host internetowy i nie coś, co VPN z pełnym tunelem powinien przenosić do zdalnego wyjścia. Dlatego tunel, który wygląda zdrowo, wciąż może zagłodzić agenta.

Dokumentacja adresu platformy mówi też, że ten adres nie podlega trasom zdefiniowanym przez użytkownika, co jest właściwością fabric Azure, a nie obietnicą dotyczącą gościa. Lokalna reguła firewalla lub własna polityka rutingu klienta VPN nadal mogą zepsuć ścieżkę, a żadna z nich nie mieszka w tablicy tras VNet.

Jeśli problem zgłasza agent, sprawdź stan usługi i ścieżkę do tego adresu, zanim cokolwiek przeinstalujesz.

169.254.169.254 ma własne reguły

169.254.169.254 to adres link-local usługi Azure Instance Metadata Service. Żądania do niego mają własne wymagania: podstawowa karta NIC i podstawowy adres IP, konfiguracja DHCP obsługująca ten adres oraz pomijanie dowolnego proxy HTTP. Wysyłanie ich przez zdalne wyjście VPN lub dowolną bramę internetową nie jest modelem dostępu, który opisuje Microsoft.

Ta klauzula o proxy łapie tych, którzy naprawili trasę i nadal widzą błędy. Proxy HTTP w gościu może zepsuć IMDS, podczas gdy ip route get zwraca dokładnie oczekiwany interfejs, więc sprawdź wyjątki proxy obok tras.

Nie wklejaj odpowiedzi metadanych do zgłoszenia do pomocy technicznej, gdy to debugujesz. Mogą zawierać poświadczenia i szczegóły instancji, które przeżyją incydent.

Czytaj routing polityk gościa, nie tylko główną tablicę

Na gościu Linux trzy polecenia tylko do odczytu rozdzielają warstwy: ip -4 rule show dla reguł polityki, potem ip -4 route get 168.63.129.16 i ip -4 route get 169.254.169.254 dla decyzji, które jądro naprawdę podejmuje. Uruchom je przed i po połączeniu VPN. Różnica między tymi wynikami to twój zestaw zmian i jest użyteczniejsza niż jakiekolwiek domysły o tym, co zrobił klient.

Klient VPN, który instaluje reguły polityki, może pozostawić główną tablicę nietkniętą i nadal przekierowywać te wyszukiwania. Dlatego poprawka tylko w głównej tablicy wygląda na działającą na jednym hoście i nic nie robi na następnym. Goście z wieloma kartami NIC dokładają ten sam problem z drugiej strony, bo odpowiedź zależy od tego, którą kartę i adres źródłowy wybierze reguła.

Oprzyj się receptcie dodającej obie trasy /32 przez starą bramę. Ścieżka platformy link-local i ogólny następny skok WAN to różne obiekty, a ogólny wyjątek ukrywa prawdziwy konflikt polityk.

Trzymaj administrację i odzyskiwanie osobno

Twoja odpowiedź SSH lub RDP też może zostać przechwycona przez domyślną trasę pełnego tunelu, ale celuje w obserwowany adres administratora, a nie w punkt końcowy platformy. Diagnozuj ją po własnej parze żądanie-odpowiedź i miej niezależny kanał odzyskiwania, taki jak konsola szeregowa, zanim zmienisz politykę VPN. Jeśli wdrożenie restartuje maszynę i agent zgłasza zły stan, sprawdź zapisaną akcję i odpowiedzialną usługę, zamiast zakładać, że restart spowodowała zmiana trasy.

Potem zweryfikuj trzy przepływy osobno: prywatny zasób, którego naprawdę chciałeś, obsługiwaną komunikację agenta i platformy oraz ścieżkę administracyjną. Przywrócenie jednego nie dowodzi, że pozostałe dwa przetrwały.

Zapisz zatwierdzony wyjątek u właściciela sieci gościa i konfiguracji VPN, wraz z tym, co dzieje się przy ponownym połączeniu i restarcie. UDR Azure nie są tablicą tras gościa, a ich edycja nie naprawi lokalnej reguły polityki.