ВМ Azure не достигает IMDS или WireServer после запуска VPN

ВМ работает, клиент VPN сообщает о подключении, а через несколько минут агент Azure начинает сообщать о нездоровом состоянии. Иногда SSH выживает, а Run Command из портала нет, и это уводит людей к агенту вместо таблицы маршрутизации. Решения о пересылке внутри гостя изменились, когда поднялся туннель, и два адреса платформы обычно становятся первыми жертвами. Я рассматриваю это как симптом маршрутизации, а не как отказ агента.

Симптом выглядит как сломанный агент

Оба адреса ниже предлагаются как исправление, хотя это не одна и та же служба. Копирование /32 для одного, потому что оно сработало для другого, — именно так временный обход превращается в постоянную конфигурацию, которую никто не решается удалить.

Работающий порядок: сначала подтвердить, на какой адрес на самом деле направлен неудачный вызов, затем прочитать, как гость его разрешает. Всё остальное — догадки с лишними шагами и более длинным окном изменений.

168.63.129.16 — не публичный адрес назначения

168.63.129.16 — специальный виртуальный адрес платформы Azure, и одна из его ролей — WireServer, который агент ВМ использует для связи с фабрикой. 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 возвращает ровно тот интерфейс, который вы ожидаете, поэтому проверяйте исключения прокси вместе с маршрутами.

Не вставляйте ответы метаданных в заявку в поддержку, пока разбираетесь с этим. Они могут содержать учётные данные и сведения об экземпляре, которые переживут инцидент.

Читайте политику маршрутизации гостя, а не только основную таблицу

На госте 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, включая то, что происходит при переподключении и перезапуске. UDR Azure — не таблица маршрутизации гостя, и их правка не исправит локальное правило политики.