Azure VM neaizsniedz IMDS vai WireServer pēc VPN palaišanas

VM darbojas, VPN klients saka, ka ir savienots, un pēc dažām minūtēm Azure aģents sāk ziņot par neveselu stāvokli. Dažkārt SSH izdzīvo, bet portāla Run Command ne, un tas cilvēkus virza pie aģenta, nevis maršrutu tabulas. Viesa paša pārsūtīšanas lēmumi mainījās, kad tunelis pacēlās, un divas platformas adreses parasti ir pirmās upurus. Es to uztveru kā maršrutēšanas simptomu, pirms uztvert kā aģenta kļūmi.

Simptoms izskatās kā salauzts aģents

Abas zemāk minētās adreses tiek piedāvātas kā risinājums, taču tās nav viens un tas pats pakalpojums. /32 kopēšana vienai, jo tā nostrādāja otrai, ir tieši tas ceļš, kā pagaidu apvedceļš kļūst par pastāvīgu konfigurāciju, ko neviens neuzdrošinās noņemt.

Strādājošā secība: vispirms apstiprināt, uz kuru adresi neveiksmīgais izsaukums patiešām mērķē, pēc tam izlasīt, kā viesis to atrisina. Viss pārējais ir minēšana ar papildu soļiem un garāku izmaiņu logu.

168.63.129.16 nav publisks galamērķis

168.63.129.16 ir Azure īpašā virtuālā platformas adrese, un viena no tās lomām ir WireServer, ko VM aģents izmanto, lai runātu ar audumu. Microsoft dokumentē, ka aģenta trafikam uz TCP portiem 80 un 32526 jāpaliek pieejamam. Tas nav parasts interneta resursdators, un tas nav kaut kas, ko pilna tuneļa VPN būtu jānes uz attālu izeju. Tāpēc tunelis, kas izskatās vesels, joprojām var izbadzināt aģentu.

Platformas adreses dokumentācija arī norāda, ka šī adrese nav pakļauta lietotāja definētiem maršrutiem, kas ir Azure auduma īpašība, nevis solījums par jūsu viesi. Vietējs ugunsmūra noteikums vai paša VPN klienta maršrutēšanas politika joprojām var salauzt ceļu, un neviens no tiem nedzīvo VNet maršrutu tabulā.

Ja problēmu ziņo aģents, pirms kaut ko pārinstalēt pārbaudiet pakalpojuma stāvokli un ceļu uz šo adresi.

169.254.169.254 ir savi noteikumi

169.254.169.254 ir Azure Instance Metadata Service link-local adrese. Pieprasījumiem uz to ir savas prasības: primārais NIC un primārā IP, adresi atbalstoša DHCP konfigurācija un jebkura HTTP starpniekservera apiešana. To sūtīšana caur attālu VPN izeju vai patvaļīgu interneta vārteju nav piekļuves modelis, ko apraksta Microsoft.

Šī starpniekservera klauzula noķer tos, kuri izlaboja maršrutu un joprojām redz kļūmes. Viesa HTTP starpniekserveris var salauzt IMDS, kamēr ip route get atgriež tieši to saskarni, kuru gaidāt, tāpēc pārbaudiet gan starpniekservera izņēmumus, gan maršrutus.

Neielīmējiet metadatu atbildes atbalsta pieteikumā, kamēr to atkļūdojat. Tajās var būt akreditācijas dati un instanca informācija, kas pārdzīvo incidentu.

Lasiet viesa politikas maršrutēšanu, ne tikai galveno tabulu

Linux viesī trīs tikai lasīšanas komandas atdala slāņus: ip -4 rule show politikas noteikumiem, pēc tam ip -4 route get 168.63.129.16 un ip -4 route get 169.254.169.254 lēmumiem, ko kodols patiešām pieņem. Palaidiet tās pirms VPN savienojuma un pēc tā. Atšķirība starp šīm izvadēm ir jūsu izmaiņu kopa, un tā ir noderīgāka par jebkuru minējumu, ko klients izdarīja.

VPN klients, kas instalē politikas noteikumus, var atstāt galveno tabulu neskartu un tomēr novirzīt šos meklējumus. Tāpēc labojums tikai galvenajā tabulā šķiet strādājam vienā resursdatorā un neko nedara nākamajā. Viesi ar vairākiem NIC pievieno to pašu problēmu no otras puses, jo atbilde ir atkarīga no tā, kuru NIC un avota adresi noteikums izvēlas.

Pretojieties receptei, kas pievieno abus /32 maršrutus caur veco vārteju. Link-local platformas ceļš un vispārējs WAN nākamais lēciens ir dažādi objekti, un vispārējs izņēmums slēpj īsto politikas konfliktu.

Turiet administrēšanu un atjaunošanu atsevišķi

Jūsu SSH vai RDP atbildi var uztvert arī pilna tuneļa noklusējums, taču tā mērķē uz administratora novēroto adresi, nevis kādu platformas galapunktu. Diagnosticējiet to pēc tā paša pieprasījuma-atbildes pāra un pirms VPN politikas maiņas turiet neatkarīgu atjaunošanas kanālu, piemēram, seriālo konsoli. Ja izvietošana restartē VM un aģents ziņo par neveselu stāvokli, pārbaudiet reģistrēto darbību un atbildīgo pakalpojumu, nevis pieņemiet, ka restartu izraisīja maršruta maiņa.

Pēc tam pārbaudiet trīs plūsmas atsevišķi: privāto resursu, kuru patiešām vēlējāties, atbalstīto aģenta un platformas saziņu un administrēšanas ceļu. Vienas atjaunošana nav pierādījums, ka pārējās divas izdzīvoja.

Ierakstiet apstiprināto izņēmumu pie viesa tīkla un VPN konfigurācijas īpašnieka, tostarp to, kas notiek atkārtoti pieslēdzoties un restartējot. Azure UDR nav viesa maršrutu tabula, un to rediģēšana neizlabos vietēju politikas noteikumu.