Azure VM nepasiekia IMDS ar WireServer po to, kai įsijungia VPN

VM veikia, VPN klientas teigia prisijungęs, o po kelių minučių Azure agentas pradeda pranešti apie netinkamą būseną. Kartais SSH išlieka, o portalo Run Command ne, todėl žmonės ima tikrinti agentą, o ne maršrutų lentelę. Svečio sprendimai dėl persiuntimo pasikeitė, kai pakilo tunelis, ir du platformos adresai paprastai tampa pirmosiomis aukomis. Aš tai traktuoju kaip maršrutizavimo simptomą, o ne kaip agento gedimą.

Simptomas atrodo kaip sugedęs agentas

Abu toliau nurodyti adresai siūlomi kaip sprendimas, tačiau tai ne ta pati paslauga. Kopijuoti /32 vienam, nes jis veikė kitam, yra būtent tas kelias, kuriuo laikinas apėjimas tampa nuolatine konfigūracija, kurios niekas nedrįsta pašalinti.

Veikianti tvarka: pirmiausia patvirtinti, kurį adresą iš tikrųjų pasiekia nepavykęs kvietimas, tada perskaityti, kaip svečias jį išsprendžia. Visa kita yra spėliojimas su papildomais žingsniais ir ilgesniu pakeitimų langu.

168.63.129.16 nėra viešoji paskirties vieta

168.63.129.16 yra specialus virtualus Azure platformos adresas, o vienas jo vaidmenų yra WireServer, kurį VM agentas naudoja kalbėdamas su fabriku. Microsoft dokumentuoja, kad agento srautas į TCP 80 ir 32526 prievadus turi likti prieinamas. Tai ne paprastas interneto hostas ir ne tai, ką viso tunelio VPN turėtų nešti į nuotolinę išėjimą. Štai kodėl sveikai atrodantis tunelis vis tiek gali numarinti agentą.

Platformos adreso dokumentacija taip pat teigia, kad šis adresas nepavaldus vartotojo apibrėžtiems maršrutams, o tai yra Azure fabriko savybė, o ne pažadas apie jūsų svečią. Vietinė ugniagesių sienos taisyklė ar paties VPN kliento maršrutizavimo politika vis dar gali nutraukti kelią, ir nė viena iš jų negyvena VNet maršrutų lentelėje.

Jei problemą praneša agentas, prieš ką nors iš naujo įdiegdami patikrinkite paslaugos būseną ir kelią į tą adresą.

169.254.169.254 turi savo taisykles

169.254.169.254 yra Azure Instance Metadata Service link-local adresas. Užklausoms į jį galioja savi reikalavimai: pirminis NIC ir pirminis IP, adresą palaikanti DHCP konfigūracija ir bet kurio HTTP proxy apėjimas. Siųsti jas per nuotolinę VPN išėjimą ar savavališką interneto šliuzą nėra tas prieigos modelis, kurį aprašo Microsoft.

Ta proxy sąlyga pagauna tuos, kurie sutvarkė maršrutą ir vis dar mato gedimus. Svečio HTTP proxy gali sugadinti IMDS, kol ip route get grąžina būtent tą sąsają, kurios tikitės, todėl tikrinkite ir proxy išimtis, ne tik maršrutus.

Neįklijuokite metaduomenų atsakymų į palaikymo bilietą, kol tai derinate. Juose gali būti kredencialų ir egzemplioriaus duomenų, kurie išlieka ilgiau nei incidentas.

Skaitykite svečio politikos maršrutizavimą, ne tik pagrindinę lentelę

Linux svečiame trys tik skaitymo komandos atskiria sluoksnius: ip -4 rule show politikos taisyklėms, tada ip -4 route get 168.63.129.16 ir ip -4 route get 169.254.169.254 sprendimams, kuriuos branduolys iš tikrųjų priima. Paleiskite jas prieš VPN prisijungimą ir po jo. Šių dviejų išvesčių skirtumas yra jūsų pakeitimų rinkinys, ir jis naudingesnis už bet kokį spėjimą, ką padarė klientas.

VPN klientas, įdiegiantis politikos taisykles, gali palikti pagrindinę lentelę nepaliestą ir vis tiek nukreipti tuos ieškojimus. Todėl tik pagrindinę lentelę taisantis sprendimas atrodo veikiantis viename hoste ir nieko nedaro kitame. Svečiai su keliais NIC prideda tą pačią problemą iš kitos pusės, nes atsakymas priklauso nuo to, kurį NIC ir šaltinio adresą pasirenka taisyklė.

Priešinkitės receptui, kuris prideda abu /32 maršrutus per seną šliuzą. Link-local platformos kelias ir bendras WAN kitas šuolis yra skirtingi objektai, o bendra išimtis paslepia tikrąjį politikos konfliktą.

Laikykite administravimą ir atkūrimą atskirai

Jūsų SSH ar RDP atsakymą taip pat gali pagauti viso tunelio numatytasis maršrutas, tačiau jis nukreiptas į stebimą administratoriaus adresą, o ne į kurį nors platformos galinį tašką. Diagnozuokite jį pagal jo paties užklausos-atsakymo porą ir prieš keisdami VPN politiką turėkite nepriklausomą atkūrimo kanalą, pavyzdžiui, serijinę konsolę. Jei diegimas paleidžia VM iš naujo ir agentas praneša apie netinkamą būseną, patikrinkite įrašytą veiksmą ir atsakingą paslaugą, o ne manykite, kad perkrovimą sukėlė maršruto pakeitimas.

Tada patikrinkite tris srautus atskirai: privatų išteklių, kurio iš tikrųjų norėjote, palaikomą agento ir platformos ryšį bei administravimo kelią. Vieno atkūrimas nėra įrodymas, kad kiti du išgyveno.

Užrašykite patvirtintą išimtį pas svečio tinklo ir VPN konfigūracijos savininką, įskaitant tai, kas nutinka jungiantis iš naujo ir paleidžiant iš naujo. Azure UDR nėra svečio maršrutų lentelė, o jų redagavimas nepataisys vietinės politikos taisyklės.