Azure VM ne može doći do IMDS-a ili WireServera nakon pokretanja VPN-a

VM radi, VPN klijent javlja da je povezan, a nekoliko minuta kasnije Azure agent počinje prijavljivati neispravnost. Ponekad SSH preživi, a Run Command iz portala ne, što ljude upućuje na agenta umjesto na tabelu ruta. Odluke o prosljeđivanju unutar gosta promijenile su se kad je tunel podignut, a dvije adrese platforme obično su prve žrtve. To tretiram kao simptom rutiranja prije nego kao kvar agenta.

Simptom izgleda kao pokvaren agent

Obje adrese ispod predlažu se kao rješenje, a nisu ista usluga. Kopiranje /32 za jednu jer je radilo za drugu upravo je način na koji privremeni obilazak postaje trajna konfiguracija koju se nitko ne usudi ukloniti.

Redoslijed koji funkcioniše jeste da prvo potvrdite koju adresu neuspjeli poziv zapravo cilja, a zatim pročitate kako je gost razrješava. Sve drugo je nagađanje s dodatnim koracima i dužim prozorom za promjene.

168.63.129.16 nije javno odredište

168.63.129.16 je posebna virtualna adresa platforme Azure, a jedna od njenih uloga je WireServer, koji VM agent koristi za razgovor s tkaninom. Microsoft dokumentuje da promet agenta prema TCP portovima 80 i 32526 mora ostati dostupan. To nije običan internetski host i nije nešto što bi VPN s punim tunelom trebao nositi do udaljenog izlaza. Zato tunel koji izgleda zdrav ipak može izgladnjeti agenta.

Dokumentacija o adresi platforme također kaže da ta adresa nije podložna korisnički definiranim rutama, što je svojstvo Azure tkanine, a ne obećanje o vašem gostu. Lokalno pravilo vatrozida ili vlastita politika rutiranja VPN klijenta i dalje mogu prekinuti put, a ni jedno od toga ne živi u tabeli ruta VNet-a.

Ako agent prijavljuje problem, provjerite stanje usluge i put do te adrese prije nego što bilo šta ponovo instalirate.

169.254.169.254 ima svoja pravila

169.254.169.254 je link-local adresa za Azure Instance Metadata Service. Zahtjevi prema njoj imaju vlastite uslove: primarni NIC i primarni IP, DHCP konfiguraciju koja podržava adresu i zaobilaženje svakog HTTP proxyja. Slanje kroz udaljeni VPN izlaz ili proizvoljni internetski gateway nije model pristupa koji Microsoft opisuje.

Ta klauzula o proxyju hvata ljude koji su popravili rutu i još uvijek vide neuspjehe. HTTP proxy u gostu može slomiti IMDS dok ip route get vraća upravo interfejs koji očekujete, zato provjerite izuzetke za proxy kao i rute.

Ne lijepite odgovore metapodataka u tiket podrške dok ovo otklanjate. Oni mogu nositi vjerodajnice i detalje instance koji nadžive incident.

Čitajte policy routing gosta, ne samo glavnu tabelu

Na Linux gostu tri naredbe samo za čitanje razdvajaju slojeve: ip -4 rule show za pravila politike, zatim ip -4 route get 168.63.129.16 i ip -4 route get 169.254.169.254 za odluke koje kernel zaista donosi. Pokrenite ih prije i poslije povezivanja VPN-a. Razlika između tih izlaza je vaš skup promjena i korisnija je od bilo koje pretpostavke o tome šta je klijent uradio.

VPN klijent koji instalira pravila politike može ostaviti glavnu tabelu netaknutom i dalje preusmjeravati te pretrage. Zato rješenje koje mijenja samo glavnu tabelu izgleda da radi na jednom hostu, a na sljedećem ne radi ništa. Gostovi s više NIC-ova dodaju isti problem iz drugog smjera, jer odgovor zavisi od toga koji NIC i izvornu adresu pravilo odabere.

Oduprite se receptu koji dodaje obje /32 rute kroz stari gateway. Link-local put platforme i opći WAN sljedeći hop različiti su objekti, a sveobuhvatni izuzetak skriva stvarni sukob politika.

Držite administraciju i oporavak odvojeno

Vaš SSH ili RDP odgovor također može uhvatiti default punog tunela, ali on cilja na administratorovu zapaženu adresu, a ne na bilo koju krajnju točku platforme. Dijagnostikujte ga iz njegovog para zahtjev-odgovor i držite neovisni kanal za oporavak, poput serijske konzole, prije nego promijenite VPN politiku. Ako implementacija restartuje VM i agent prijavi neispravnost, pregledajte zabilježenu radnju i odgovornu uslugu umjesto da pretpostavite da je promjena rute izazvala restart.

Zatim provjerite tri toka odvojeno: privatni resurs koji ste zaista htjeli, podržanu komunikaciju agenta i platforme, i administrativni put. Vraćanje jednog od njih nije dokaz da su druga dva preživjela.

Zapišite odobreni izuzetak kod vlasnika mreže gosta i VPN konfiguracije, uključujući šta se dešava pri ponovnom povezivanju i restartu. Azure UDR-ovi nisu tabela ruta gosta, a njihovo uređivanje neće popraviti lokalno pravilo politike.