Azure-VM bereik nie IMDS of WireServer nadat die VPN begin het nie

Die VM is op, die VPN-kliënt sê dit is gekonnekteer, en die Azure-agent begin 'n paar minute later ongesond rapporteer. Soms bly SSH werk terwyl Run Command vanaf die portaal nie werk nie, wat mense na die agent laat kyk in plaas van na die roetetabel. Die gas se eie aanstuur-besluite het verander toe die tonnel opgekom het, en twee platformadresse is gewoonlik die eerste slagoffers. Ek behandel dit as 'n roeteringsimptoom voordat ek dit as 'n agentfout behandel.

Die simptoom lyk soos 'n stukkende agent

Albei adresse hieronder word as 'n oplossing voorgestel, en hulle is nie dieselfde diens nie. Om 'n /32 vir een van hulle te kopieer omdat dit vir die ander gewerk het, is hoe 'n tydelike noodoplossing 'n permanente konfigurasie word wat niemand durf verwyder nie.

Die volgorde wat werk, is om eers vas te stel watter adres die mislukte oproep werklik teiken, en dan te lees hoe die gas dit oplos. Enigiets anders is raai met ekstra stappe en 'n langer veranderingsvenster.

168.63.129.16 is nie 'n publieke bestemming nie

168.63.129.16 is Azure se spesiale virtuele platformadres, en een van sy rolle is WireServer, wat die VM-agent gebruik om met die weefsel te praat. Microsoft dokumenteer dat agentverkeer na TCP-poorte 80 en 32526 beskikbaar moet bly. Dit is nie 'n gewone internetgasheer nie, en dit is nie iets wat 'n voltonnel-VPN na 'n afgeleë uitgang moet dra nie. Daarom kan 'n tonnel wat gesond lyk, die agent steeds uithonger.

Die platformadres-dokumentasie sê ook dat hierdie adres nie aan gebruiker-gedefinieerde roetes onderworpe is nie, wat 'n eienskap van die Azure-weefsel is eerder as 'n belofte oor jou gas. 'n Plaaslike firewallreël of die VPN-kliënt se eie roeteringsbeleid kan die pad steeds breek, en nie een van dié woon in die VNet se roetetabel nie.

As dit die agent is wat probleme rapporteer, kyk na die diensstatus en die pad na daardie adres voordat jy enigiets herinstalleer.

169.254.169.254 het sy eie reëls

169.254.169.254 is die skakel-lokale adres vir die Azure Instance Metadata Service. Versoeke daarheen het hul eie vereistes: die primêre NIC en primêre IP, 'n DHCP-konfigurasie wat die adres ondersteun, en omseiling van enige HTTP-proxy. Om hulle deur 'n afgeleë VPN-uitgang of 'n willekeurige internetpoort te stuur, is nie die toegangsmodel wat Microsoft beskryf nie.

Daardie proxy-klousule vang mense wat die roete reggemaak het en steeds foute sien. 'n Gas-HTTP-proxy kan IMDS breek terwyl ip route get presies die koppelvlak teruggee wat jy verwag, so kyk ook na die proxy-uitsonderings en nie net die roetes nie.

Moenie metadata-antwoorde in 'n ondersteuningskaartjie plak terwyl jy dit ontfout nie. Hulle kan geloofsbriewe en instansiedetails dra wat die voorval oorleef.

Lees die gas se beleidsroetering, nie net die hoofdabel nie

Op 'n Linux-gas skei drie lees-alleen-opdragte die lae: ip -4 rule show vir die beleidsreëls, dan ip -4 route get 168.63.129.16 en ip -4 route get 169.254.169.254 vir die besluite wat die kern werklik maak. Voer hulle uit voor en nadat die VPN koppel. Die verskil tussen daardie twee uitsette is jou veranderingsstel, en dit is nuttiger as enige raaiskoot oor wat die kliënt gedoen het.

'n VPN-kliënt wat beleidsreëls installeer, kan die hoofdabel onaangeraak laat terwyl dit daardie opsoekte steeds herlei. Daarom lyk 'n oplossing wat net die hoofdabel wysig, asof dit op een gasheer werk en op die volgende niks doen nie. Gashere met veelvuldige NIC's voeg dieselfde probleem uit die ander rigting by, want die antwoord hang daarvan af watter NIC en bronadres die reël kies.

Weerstaan die resep wat albei /32-roetes deur die ou poort voeg. 'n Skakel-lokale platformpad en 'n algemene WAN-volgende hop is verskillende objekte, en 'n algemene uitsondering verberg die werklike beleidskonflik.

Hou administrasie en herstel apart

Jou SSH- of RDP-antwoord kan ook deur 'n voltonnel-verstek vasgevang word, maar dit teiken die administrateur se waargenome adres eerder as een van die platformeindpunte. Diagnoseer dit uit sy eie versoek-en-antwoord-paar, en hou 'n onafhanklike herstelkanaal soos die serieë konsole gereed voordat jy VPN-beleid verander. As 'n ontplooiing die VM herbegin en die agent rapporteer ongesond, ondersoek die aangetekende aksie en die verantwoordelike diens in plaas daarvan om aan te neem die roeteverandering het die herbegin veroorsaak.

Verifieer dan die drie vloei afsonderlik: die private hulpbron wat jy eintlik wou hê, die ondersteunde agent- en platformkommunikasie, en die administrasiepad. Om een van hulle te herstel, is nie bewys dat die ander twee oorleef het nie.

Skryf die goedgekeurde uitsondering onder die eienaar van die gasnetwerk en VPN-konfigurasie, insluitend wat gebeur met herverbinding en herbegin. Azure UDR's is nie die gas se roetetabel nie, en om hulle te wysig sal nie 'n plaaslike beleidsreël regmaak nie.