VM-ja e Azure nuk arrin IMDS ose WireServer pasi nis VPN-ja

VM-ja është ndezur, klienti VPN thotë se është lidhur, dhe disa minuta më vonë agjenti Azure fillon të raportojë gjendje jo të shëndetshme. Ndonjëherë SSH mbijeton dhe Run Command nga portali jo, gjë që i drejton njerëzit te agjenti në vend të tabelës së rrugëve. Vendimet e përcilljes së mysafirit ndryshuan kur u ngrit tuneli, dhe dy adresa të platformës janë zakonisht viktimat e para. E trajtoj si simptom rrugëtimi përpara se ta trajtoj si dështim të agjentit.

Simptoma duket si agjent i prishur

Të dy adresat më poshtë propozohen si rregullim, dhe nuk janë i njëjti shërbim. Kopjimi i një /32 për njërën sepse funksionoi për tjetrën është pikërisht mënyra se si një zgjidhje e përkohshme bëhet konfigurim i përhershëm që askush nuk guxon ta heqë.

Rendi që funksionon është të konfirmohet se cila adresë është në të vërtetë objektivi i thirrjes që dështon, dhe pastaj të lexohet se si mysafiri e zgjidh atë. Çdo gjë tjetër është hamendësim me hapa shtesë dhe një dritare ndryshimi më e gjatë.

168.63.129.16 nuk është destinacion publik

168.63.129.16 është adresa virtuale speciale e platformës Azure, dhe një nga rolet e saj është WireServer, të cilin agjenti i VM-së e përdor për të folur me fabric. Microsoft dokumenton se trafiku i agjentit drejt porteve TCP 80 dhe 32526 duhet të mbetet i disponueshëm. Nuk është një host normal interneti dhe nuk është diçka që një VPN me tunel të plotë duhet ta çojë në një dalje të largët. Kjo është arsyeja pse një tunel që duket i shëndetshëm mund ta lërë agjentin të uritur.

Dokumentacioni i adresës së platformës thotë gjithashtu se kjo adresë nuk i nënshtrohet rrugëve të përcaktuara nga përdoruesi, që është një veti e fabric-it të Azure dhe jo një premtim për mysafirin tuaj. Një rregull lokal i firewall-it ose politika e rrugëtimit të vetë klientit VPN mund ta thyejnë ende rrugën, dhe asnjëra nuk jeton në tabelën e rrugëve të VNet-it.

Nëse agjenti është ai që raporton problemin, kontrolloni gjendjen e shërbimit dhe rrugën drejt asaj adrese përpara se të riinstaloni ndonjë gjë.

169.254.169.254 ka rregullat e veta

169.254.169.254 është adresa link-local e Azure Instance Metadata Service. Kërkesat drejt saj kanë kërkesat e tyre: NIC primar dhe IP primar, një konfigurim DHCP që e mbështet adresën, dhe kalimi përtej çdo proxy HTTP. Dërgimi i tyre përmes një daljeje të largët VPN ose një gateway interneti arbitrar nuk është modeli i aksesit që përshkruan Microsoft.

Ajo klauzolë për proxy kap ata që e rregulluan rrugën dhe ende shohin dështime. Një proxy HTTP në mysafir mund të prishë IMDS ndërsa ip route get kthen pikërisht ndërfaqen që prisni, prandaj kontrolloni përjashtimet e proxy-t si dhe rrugët.

Mos ngjitni përgjigje metadata në një biletë mbështetjeje ndërsa e korrigjoni këtë. Ato mund të mbajnë kredenciale dhe detaje instancë që jetojnë më gjatë se incidenti.

Lexoni rrugëtimin e politikës së mysafirit, jo vetëm tabelën kryesore

Në një mysafir Linux, tre komanda vetëm-lexim ndajnë shtresat: ip -4 rule show për rregullat e politikës, pastaj ip -4 route get 168.63.129.16 dhe ip -4 route get 169.254.169.254 për vendimet që kernel-i merr në të vërtetë. Ekzekutoni ato përpara dhe pasi VPN të lidhet. Diferenca midis këtyre dy daljeve është grupi juaj i ndryshimeve, dhe është më i dobishëm se çdo hamendësim për atë që bëri klienti.

Një klient VPN që instalon rregulla politike mund ta lërë tabelën kryesore të paprekur dhe ende t'i ridrejtojë ato kërkime. Kjo është arsyeja pse një rregullim vetëm i tabelës kryesore duket se funksionon në një host dhe nuk bën asgjë në tjetrin. Mysafirët me shumë NIC shtojnë të njëjtin problem nga ana tjetër, sepse përgjigja varet nga ajo se cila NIC dhe adresë burimore zgjedh rregulli.

Rezistoni recetës që shton të dyja rrugët /32 përmes gateway-it të vjetër. Një rrugë platforme link-local dhe një hop i radhës WAN i përgjithshëm janë objekte të ndryshme, dhe një përjashtim i përgjithshëm fsheh konfliktin e vërtetë të politikës.

Mbani administrimin dhe rikuperimin të ndara

Përgjigja juaj SSH ose RDP mund të kapet gjithashtu nga një default i tunelit të plotë, por ajo synon adresën e vëzhguar të administratorit dhe jo një pikë fundore të platformës. Diagnostikojeni nga çifti i vet i kërkesë-përgjigjes, dhe mbani një kanal rikuperimi të pavarur si tastiera serike përpara se të ndryshoni politikën e VPN-së. Nëse një vendosje rinis VM-në dhe agjenti raporton gjendje jo të shëndetshme, inspektoni veprimin e regjistruar dhe shërbimin përgjegjës në vend që të supozoni se ndryshimi i rrugës shkaktoi rinisjen.

Pastaj verifikoni tre flukset veçmas: burimin privat që vërtet e dëshironit, komunikimin e mbështetur të agjentit dhe platformës, dhe rrugën administrative. Rikthimi i njërit prej tyre nuk është provë se dy të tjerët mbijetuan.

Shkruani përjashtimin e miratuar nën pronarin e rrjetit të mysafirit dhe konfigurimit të VPN-së, duke përfshirë çfarë ndodh në rilidhje dhe rinisje. UDR-të e Azure nuk janë tabela e rrugëve e mysafirit, dhe redaktimi i tyre nuk do të rregullojë një rregull lokal politike.