VM ya Azure haiwezi kufikia IMDS au WireServer baada ya VPN kuanza

VM inaendesha, mteja wa VPN anasema imeunganishwa, na dakika chache baadaye wakala wa Azure anaanza kuripoti hali mbaya. Wakati mwingine SSH inaendelea kuishi lakini Run Command kutoka portal haifanyi, jambo linalowafanya watu waangalie wakala badala ya jedwali la njia. Maamuzi ya uwasilishaji ya mgeni yenyewe yalibadilika wakati handaki ilipopanda, na anwani mbili za jukwaa huwa wahanga wa kwanza. Naichukulia kama dalili ya uelekezaji kabla ya kuichukulia kama hitilafu ya wakala.

Dalili inaonekana kama wakala aliyevunjika

Anwani zote mbili hapa chini zinapendekezwa kama suluhisho, na si huduma moja. Kunakili /32 kwa moja kwa sababu ilifanya kazi kwa nyingine ndiyo njia ambayo suluhisho la muda linakuwa usanidi wa kudumu ambao hakuna anayethubutu kuuondoa.

Mpangilio unaofanya kazi ni kwanza kuthibitisha ni anwani gani simu iliyoshindwa inalenga kweli, kisha kusoma jinsi mgeni anaisuluhisha. Kila kitu kingine ni kukisia kwa hatua za ziada na dirisha refu la mabadiliko.

168.63.129.16 si marudio ya umma

168.63.129.16 ni anwani maalum ya jukwaa pepe la Azure, na moja ya majukumu yake ni WireServer, ambayo wakala wa VM hutumia kuzungumza na fabric. Microsoft inaandika kwamba trafiki ya wakala kwenda bandari za TCP 80 na 32526 lazima ibaki inapatikana. Si mwenyeji wa kawaida wa intaneti, na si kitu ambacho VPN ya handaki kamili inapaswa kubeba hadi kwenye njia ya kutoka ya mbali. Ndiyo sababu handaki inayoonekana nzuri bado inaweza kumfanya wakala afa kwa njaa.

Nyaraka za anwani ya jukwaa pia zinasema anwani hii haiko chini ya njia zilizofafanuliwa na mtumiaji, ambayo ni sifa ya fabric ya Azure na si ahadi kuhusu mgeni wako. Sheria ya firewall ya ndani au sera ya uelekezaji ya mteja wa VPN yenyewe bado inaweza kuvunja njia, na hakuna kati yao inayoishi katika jedwali la njia la VNet.

Ikiwa wakala ndiye anayeripoti tatizo, angalia hali ya huduma na njia kuelekea anwani hiyo kabla ya kusakinisha upya kitu chochote.

169.254.169.254 ina sheria zake

169.254.169.254 ni anwani ya link-local ya Azure Instance Metadata Service. Maombi kwake yana mahitaji yake: NIC ya msingi na IP ya msingi, usanidi wa DHCP unaoauni anwani, na kupitisha proksi yoyote ya HTTP. Kuyatuma kupitia njia ya kutoka ya VPN ya mbali au lango la intaneti holela si mtindo wa ufikiaji unaoelezwa na Microsoft.

Kifungu hicho cha proksi kinawakamata wale waliotengeneza njia na bado wanaona kushindwa. Proksi ya HTTP ndani ya mgeni inaweza kuvunja IMDS wakati ip route get inarudisha kiolesura hasa unachotarajia, kwa hiyo angalia vighairi vya proksi pamoja na njia.

Usibandike majibu ya metadata kwenye tiketi ya usaidizi unapotatua hili. Yanaweza kubeba vitambulisho na maelezo ya instance yanayoishi zaidi ya tukio.

Soma uelekezaji wa sera wa mgeni, si jedwali kuu pekee

Kwenye mgeni wa Linux, amri tatu za kusoma tu hutenganisha tabaka: ip -4 rule show kwa sheria za sera, kisha ip -4 route get 168.63.129.16 na ip -4 route get 169.254.169.254 kwa maamuzi ambayo kernel hufanya kweli. Zikimbie kabla na baada ya VPN kuunganishwa. Tofauti kati ya matokeo hayo mawili ni seti yako ya mabadiliko, na ni muhimu zaidi kuliko dhana yoyote kuhusu kile mteja alifanya.

Mteja wa VPN anayesakinisha sheria za sera anaweza kuacha jedwali kuu bila kuguswa na bado kuelekeza utafutaji huo. Ndiyo sababu suluhisho la jedwali kuu pekee linaonekana kufanya kazi kwenye mwenyeji mmoja na haifanyi chochote kwa ujao. Wageni wenye NIC nyingi huongeza tatizo hilo hilo kutoka upande mwingine, kwa sababu jibu hutegemea ni NIC gani na anwani ya chanzo ambayo sheria huchagua.

Pinga kichocheo kinachoongeza njia zote mbili za /32 kupitia lango la zamani. Njia ya jukwaa la link-local na hop inayofuata ya WAN ya jumla ni vitu tofauti, na kighairi cha jumla kinaficha mgongano halisi wa sera.

Tenga utawala na urejeshaji

Jibu lako la SSH au RDP linaweza pia kunaswa na default ya handaki kamili, lakini linalenga anwani iliyozingatiwa ya msimamizi na si sehemu ya mwisho ya jukwaa. Itambue kutoka jozi yake ya ombi na jibu, na weka njia huru ya urejeshaji kama konsoli ya mfululizo kabla ya kubadilisha sera ya VPN. Ikiwa usambazaji unaanzisha upya VM na wakala anaripoti hali mbaya, chunguza kitendo kilichorekodiwa na huduma inayohusika badala ya kudhani mabadiliko ya njia yalisababisha kuanzisha upya.

Kisha thibitisha mitiririko mitatu kando: rasilimali ya kibinafsi uliyokuwa ukitaka kweli, mawasiliano yanayoauniwa ya wakala na jukwaa, na njia ya utawala. Kurejesha moja si uthibitisho kwamba mingine miwili ilinusurika.

Andika kighairi kilichoidhinishwa chini ya mmiliki wa mtandao wa mgeni na usanidi wa VPN, ikiwa ni pamoja na kile kinachotokea unapounganisha tena na kuanzisha upya. UDR za Azure si jedwali la njia la mgeni, na kuzihariri hakutatengeneza sheria ya sera ya ndani.