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 връща точно интерфейса, който очаквате, затова проверявайте изключенията за прокси, както и маршрутите.

Не поставяйте отговори от metadata в тикет за поддръжка, докато отстранявате проблема. Те могат да носят идентификационни данни и подробности за инстанса, които надживяват инцидента.

Четете 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 отговор също може да бъде прихванат от default на пълен тунел, но той е насочен към наблюдавания адрес на администратора, а не към някоя от крайните точки на платформата. Диагностицирайте го по собствената му двойка заявка-отговор и дръжте независим канал за възстановяване, като серийната конзола, преди да промените VPN политиката. Ако разгръщане рестартира VM и агентът докладва неизправност, прегледайте записаното действие и отговорната услуга, вместо да предполагате, че промяната на маршрута е причинила рестарта.

След това проверете трите потока поотделно: частния ресурс, който наистина сте искали, поддържаната комуникация на агента и платформата, и административния път. Възстановяването на един от тях не е доказателство, че другите два са оцелели.

Запишете одобреното изключение при собственика на мрежата на госта и VPN конфигурацията, включително какво се случва при повторно свързване и рестарт. UDR на Azure не са таблицата за маршрутизация на госта и редактирането им няма да поправи локално правило на политиката.