ВМ 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 — не таблиця маршрутизації гостя, і їх редагування не виправить локальне правило політики.