Azure VM ne atingas IMDS aŭ WireServer post kiam la VPN ekfunkcias

La VM funkcias, la VPN-kliento diras ke ĝi estas konektita, kaj kelkajn minutojn poste la Azure-agento komencas raporti malsanon. Foje SSH pluvivas kaj Run Command el la portalo ne, kio sendas homojn al la agento anstataŭ al la enkursigada tabelo. La propraj plusendaj decidoj de la gasto ŝanĝiĝis kiam la tunelo leviĝis, kaj du platformaj adresoj kutime estas la unuaj viktimoj. Mi traktas tion kiel enkursigadan simptomon antaŭ ol trakti ĝin kiel agentan fiaskon.

La simptomo aspektas kiel rompita agento

Ambaŭ adresoj sube estas proponataj kiel solvo, kaj ili ne estas la sama servo. Kopii /32 por unu ĉar ĝi funkciis por la alia estas ĝuste kiel provizora solvo fariĝas konstanta agordo, kiun neniu kuraĝas forigi.

La ordo kiu funkcias estas unue konfirmi kiun adreson la malsukcesa alvoko vere celas, poste legi kiel la gasto solvas ĝin. Ĉio alia estas divenado kun pliaj paŝoj kaj pli longa ŝanĝa fenestro.

168.63.129.16 ne estas publika celo

168.63.129.16 estas la speciala virtuala platforma adreso de Azure, kaj unu el ĝiaj roloj estas WireServer, kiun la VM-agento uzas por paroli kun la fabriko. Microsoft dokumentas ke agenta trafiko al TCP-pordoj 80 kaj 32526 devas resti havebla. Ĝi ne estas ordinara interreta gastiganto, kaj ĝi ne estas io, kion plentunela VPN devus porti al fora eliro. Tial tunelo, kiu aspektas sana, ankoraŭ povas malsatigi la agenton.

La dokumentaro pri la platforma adreso ankaŭ diras ke ĉi tiu adreso ne submetiĝas al uzant-difinitaj itineroj, kio estas eco de la Azure-fabriko kaj ne promeso pri via gasto. Loka fajroŝirma regulo aŭ la propra enkursigada politiko de la VPN-kliento ankoraŭ povas rompi la vojon, kaj nek unu nek la alia loĝas en la enkursigada tabelo de la VNet.

Se la agento estas tiu, kiu raportas problemon, kontrolu la servan staton kaj la vojon al tiu adreso antaŭ ol reinstali ion ajn.

169.254.169.254 havas proprajn regulojn

169.254.169.254 estas la link-local adreso por la Azure Instance Metadata Service. Petoj al ĝi havas proprajn postulojn: la ĉefa NIC kaj ĉefa IP, DHCP-agordo kiu subtenas la adreson, kaj preterpaso de ajna HTTP-prokuro. Sendi ilin tra fora VPN-eliro aŭ arbitra interreta pordego ne estas la alirmodelo, kiun Microsoft priskribas.

Tiu prokura klaŭzo kaptas homojn, kiuj riparis la itineron kaj ankoraŭ vidas fiaskojn. Gasta HTTP-prokuro povas rompi IMDS dum ip route get redonas ĝuste la interfacon, kiun vi atendas, do kontrolu la prokurajn esceptojn same kiel la itinerojn.

Ne algluu metadatenajn respondojn en subtenan bileton dum vi sencimigas ĉi tion. Ili povas porti akreditaĵojn kaj instancajn detalojn, kiuj postvivos la incidenton.

Legu la politikan enkursigadon de la gasto, ne nur la ĉefan tabelon

Sur Linux-gasto tri nurlegaj komandoj apartigas la tavolojn: ip -4 rule show por la politikaj reguloj, poste ip -4 route get 168.63.129.16 kaj ip -4 route get 169.254.169.254 por la decidoj, kiujn la kerno vere faras. Rulu ilin antaŭ kaj post kiam la VPN konektiĝas. La diferenco inter tiuj du eligoj estas via ŝanĝaro, kaj ĝi estas pli utila ol ajna konjekto pri tio, kion faris la kliento.

VPN-kliento, kiu instalas politikajn regulojn, povas lasi la ĉefan tabelon netuŝita kaj ankoraŭ alidirekti tiujn serĉojn. Tial solvo nur por la ĉefa tabelo ŝajnas funkcii sur unu gastiganto kaj faras nenion sur la sekva. Gastoj kun pluraj NIC aldonas la saman problemon el la alia direkto, ĉar la respondo dependas de tio, kiun NIC kaj fontadreson la regulo elektas.

Rezistu la recepton, kiu aldonas ambaŭ /32-itinerojn tra la malnova pordego. Link-local platforma vojo kaj ĝenerala WAN-sekva salto estas malsamaj objektoj, kaj ĝenerala escepto kaŝas la realan politikan konflikton.

Tenu administradon kaj restaŭradon aparte

Via SSH- aŭ RDP-respondo ankaŭ povas esti kaptita de plentunela default, sed ĝi celas la observitan adreson de la administranto anstataŭ ajnan platforman finpunkton. Diagnozu ĝin el ĝia propra paro peto-respondo, kaj tenu sendependan restaŭran kanalon kiel la seria konzolo antaŭ ol ŝanĝi la VPN-politikon. Se deplojo restarigas la VM kaj la agento raportas malsanon, ekzamenu la registritan agon kaj la respondecan servon anstataŭ supozi, ke la itinera ŝanĝo kaŭzis la restarigon.

Poste kontrolu la tri fluojn aparte: la privatan rimedon, kiun vi vere volis, la subtenatan agentan kaj platforman komunikadon, kaj la administran vojon. Restaŭri unu el ili ne pruvas, ke la aliaj du pluvivis.

Skribu la aprobitan escepton ĉe la posedanto de la gasta reto kaj la VPN-agordo, inkluzive de tio, kio okazas ĉe rekonekto kaj restarigo. Azure UDR-oj ne estas la enkursigada tabelo de la gasto, kaj redakti ilin ne riparos lokan politikan regulon.