Azure-VM berikt IMDS of WireServer net mear nei't de VPN start

De VM draait, de VPN-klient seit dat er ferbûn is, en in pear minuten letter begjint de Azure-agent te melden dat er net sûn is. Soms oerlibbet SSH en Run Command fan it portaal net, wat minsken nei de agent stjoert ynstee fan nei de rûteskema. De eigen trochstjoerbesluten fan de gast feroaren doe't de tunnel omheech kaam, en twa platfoarmadressen binne meastentiids de earste slachtoffers. Ik behannelje dat as in routing-symptoom foardat ik it as in agentstoring behannelje.

It symptoom liket in stikken agent

Beide adressen hjirûnder wurde as oplossing foarsteld, en it binne net deselde tsjinst. In /32 kopiearje foar de iene om't it foar de oare wurke, is krekt hoe't in tydlike omwei in permaninte konfiguraasje wurdt dy't nimmen doar te ferwiderjen.

De folchoarder dy't wurket is earst befêstigje hokker adres de mislearre oprop eins rjochtet, en dan lêze hoe't de gast it oplost. Al it oare is rieden mei ekstra stappen en in langer feroaringsfinster.

168.63.129.16 is gjin iepenbier bestimming

168.63.129.16 is it spesjale firtuele platfoarmadres fan Azure, en ien fan syn rollen is WireServer, dat de VM-agent brûkt om mei it fabric te praten. Microsoft dokumintearret dat agentferkear nei TCP-poarten 80 en 32526 beskikber bliuwe moat. It is gjin gewoane ynternethost, en it is net eat dat in foltunnel-VPN nei in ôfstânútgong drage moat. Dêrom kin in tunnel dy't sûn liket de agent noch hieltyd úthongerje.

De dokumintaasje oer it platfoarmadres seit ek dat dit adres net ûnderwurpen is oan brûker-definieare rûtes, wat in eigenskip fan it Azure-fabric is en gjin belofte oer jo gast. In pleatslike firewallregel of it eigen routingbelied fan de VPN-klient kin it paad noch brekke, en gjin fan beide libbet yn 'e rûteskema fan it VNet.

As de agent it probleem meldt, kontrolearje dan de tsjinststatus en it paad nei dat adres foardat jo eat opnij ynstallearje.

169.254.169.254 hat syn eigen regels

169.254.169.254 is it link-local adres foar de Azure Instance Metadata Service. Oanfragen derhinne hawwe eigen easken: de primêre NIC en primêre IP, in DHCP-konfiguraasje dy't it adres stipet, en it omgean fan elke HTTP-proxy. Se troch in ôfstân VPN-útgong of in willekeurige ynternetgateway stjoere is net it tagongsmodel dat Microsoft beskriuwt.

Dy proxyklausule fangt minsken dy't de rûte reparearre hawwe en noch altyd flaters sjogge. In HTTP-proxy yn 'e gast kin IMDS brekke wylst ip route get krekt de interface weromjout dy't jo ferwachtsje, dus kontrolearje de proxy-útsûnderingen likegoed as de rûtes.

Plak gjin metadata-antwurden yn in stipekaartsje wylst jo dit debugge. Se kinne bewiisstikken en ynstansdetails drage dy't it ynsidint oerlibje.

Lês it policy routing fan de gast, net allinnich de haadtabel

Op in Linux-gast skiede trije lês-allinne-opdrachten de lagen: ip -4 rule show foar de beliedsregels, dan ip -4 route get 168.63.129.16 en ip -4 route get 169.254.169.254 foar de besluten dy't de kernel echt nimt. Rin se foar en nei't de VPN ferbynt. It ferskil tusken dy twa útfier is jo feroaringsset, en it is nuttiger as hokker ried dan ek oer wat de klient die.

In VPN-klient dy't beliedsregels ynstallearret kin de haadtabel ûnoantaaste litte en dy opsochten noch hieltyd omliede. Dêrom liket in oplossing dy't allinnich de haadtabel oanpast op ien host te wurkjen en docht se op 'e folgjende neat. Gasten mei meardere NIC's foegje itselde probleem fan 'e oare kant ta, om't it antwurd ôfhinget fan hokker NIC en boarneadres de regel kiest.

Wjerstean de resept dy't beide /32-rûtes troch de âlde gateway tafoeget. In link-local platfoarmpaad en in algemiene WAN-folgende hop binne ferskillende objekten, en in algemiene útsûndering ferberget it echte beliedskonflikt.

Hâld behear en herstel apart

Jo SSH- of RDP-antwurd kin ek troch in foltunnel-default fongen wurde, mar it rjochtet him op it waarnommen adres fan de behearder ynstee fan op in platfoarmeinpunt. Diagnostearje it út syn eigen oanfraach-en-antwurd-pear, en hâld in ûnôfhinklik herstelkanaal lykas de searjele konsole foardat jo it VPN-belied feroarje. As in útrulling de VM opnij start en de agent meldt dat er net sûn is, ûndersykje dan de registrearre aksje en de ferantwurdlike tsjinst ynstee fan oan te nimmen dat de rûteferoaring de werstart feroarsake.

Kontrolearje dan de trije streamen apart: de privee boarne dy't jo echt woene, de stipe agint- en platfoarmkommunikaasje, en it behearpaad. Ien fan harren werombringe is gjin bewiis dat de oare twa oerlibbe hawwe.

Skriuw de goedkarde útsûndering ûnder de eigner fan it gastnetwurk en de VPN-konfiguraasje, ynklusyf wat der bart by opnij ferbinen en werstart. Azure UDR's binne net it rûteskema fan 'e gast, en it bewurkjen dêrfan reparearret gjin pleatslike beliedsregel.