Azure VM не може да дође до IMDS-а или WireServer-а након покретања VPN-а

ВМ ради, VPN клијент јавља да је повезан, а неколико минута касније Azure агент почиње да пријављује нездраво стање. Понекад SSH преживи, а Run Command са портала не, што људе усмерава ка агенту уместо ка табели рута. Одлуке о прослеђивању унутар госта промениле су се када се тунел подигао, а две адресе платформе обично су прве жртве. То третирам као симптом рутирања пре него као квар агента.

Симптом изгледа као покварен агент

Обе адресе испод предлажу се као решење, а нису иста услуга. Копирање /32 за једну јер је радило за другу управо је начин на који привремено обилажење постаје трајна конфигурација коју се нико не усуђује да уклони.

Редослед који функционише јесте да прво потврдите коју адресу неуспели позив заиста циља, а затим прочитате како је гост разрешава. Све друго је нагађање са додатним корацима и дужим прозором измена.

168.63.129.16 није јавно одредиште

168.63.129.16 је посебна виртуелна адреса платформе Azure, а једна од њених улога је WireServer, који VM агент користи за разговор са тканином. Microsoft документује да саобраћај агента ка TCP портовима 80 и 32526 мора остати доступан. То није обичан интернет домаћин и није нешто што VPN са пуним тунелом треба да носи до удаљеног излаза. Зато тунел који изгледа здраво ипак може изгладнети агента.

Документација о адреси платформе такође каже да ова адреса није подложна кориснички дефинисаним рутама, што је својство Azure тканине, а не обећање о вашем госту. Локално правило заштитног зида или сопствена политика рутирања VPN клијента и даље могу прекинути пут, и ни једно од тога не живи у табели рута VNet-а.

Ако агент пријављује проблем, проверите стање услуге и пут до те адресе пре него што било шта поново инсталирате.

169.254.169.254 има своја правила

169.254.169.254 је link-local адреса за Azure Instance Metadata Service. Захтеви ка њој имају сопствене услове: примарни NIC и примарни IP, DHCP конфигурацију која подржава адресу и заобилажење сваког HTTP проксија. Слање кроз удаљени VPN излаз или произвољни интернет гејтвеј није модел приступа који Microsoft описује.

Та клаузула о проксију хвата оне који су поправили руту и још виде неуспехе. HTTP прокси у госту може сломити IMDS док ip route get враћа тачно интерфејс који очекујете, зато проверите изузетке за прокси као и руте.

Не лепите одговоре метаподатака у тикет подршке док ово отклањате. Они могу носити акредитиве и детаље инстанце који надживе инцидент.

Читајте policy routing госта, не само главну табелу

На Linux госту три наредбе само за читање раздвајају слојеве: ip -4 rule show за правила политике, затим ip -4 route get 168.63.129.16 и ip -4 route get 169.254.169.254 за одлуке које кернел заиста доноси. Покрените их пре и после повезивања VPN-а. Разлика између тих излаза је ваш скуп измена и кориснија је од било које претпоставке о томе шта је клијент урадио.

VPN клијент који инсталира правила политике може оставити главну табелу нетакнутом и ипак преусмеравати те претраге. Зато решење само главне табеле изгледа да ради на једном домаћину, а на следећем не ради ништа. Гостови са више NIC-ова додају исти проблем са друге стране, јер одговор зависи од тога који NIC и изворну адресу правило одабере.

Одуприте се рецепту који додаје обе /32 руте кроз стари гејтвеј. Link-local пут платформе и општи WAN следећи хоп различити су објекти, а свеобухватни изузетак скрива стварни сукоб политика.

Држите администрацију и опоравак одвојено

Ваш SSH или RDP одговор такође може бити ухваћен подразумеваним путем пуног тунела, али он циља запажену адресу администратора, а не крајњу тачку платформе. Дијагностикујте га из његовог сопственог пара захтев-одговор и држите независан канал за опоравак, попут серијске конзоле, пре него што промените VPN политику. Ако примена рестартује ВМ и агент пријави нездраво стање, прегледајте забележену радњу и одговорну услугу уместо да претпоставите да је промена руте изазвала рестарт.

Затим проверите три тока одвојено: приватни ресурс који сте заиста желели, подржану комуникацију агента и платформе и административни пут. Враћање једног од њих није доказ да су друга два преживела.

Запишите одобрени изузетак код власника мреже госта и VPN конфигурације, укључујући шта се дешава при поновном повезивању и рестарту. Azure UDR-ови нису табела рута госта, а њихово уређивање неће поправити локално правило политике.