План эскалации для Azure VPN Gateway, когда ICMP достигает назначения, а ответы DNS или TCP не возвращаются: синхронные контрольные потоки, двусторонний захват, Route и Tunnel diagnostics без публикации адресов.
Не превращайте ping в доказательство всей связности
Зафиксируйте источник, назначение, время UTC и три разрешённых проверки: ICMP, один DNS-запрос к ожидаемому серверу и подключение к одному TCP-порту служебного приложения. Используйте одинаковую пару узлов и не запускайте сканирование диапазона. Если ping успешен, это подтверждает только прохождение конкретного ICMP-обмена в данный момент. DNS может использовать UDP или TCP и отдельный порт, а прикладное соединение имеет собственные правила и состояние. Запишите направление каждого запроса и наличие ответа. Не меняйте NSG, firewall и маршруты до первой временной шкалы: иначе невозможно понять, какой слой изменил результат.
Проведите синхронный двусторонний контроль
Согласуйте короткое окно и запустите захват на разрешённых точках с обеих сторон соединения. По очереди отправьте один ICMP, один DNS и одно TCP-соединение, оставляя между ними заметный интервал. Для каждого потока ответьте на четыре вопроса: запрос вышел с клиента, дошёл до назначения, ответ вышел обратно, появился на клиентской стороне. Такая таблица отделяет проблему прямого пути от обратного. Microsoft Azure VPN Gateway поддерживает packet capture на шлюзе и соединении с фильтрами по пятиэлементному кортежу и TCP-флагам. Фильтруйте только нужные адреса и порты, чтобы не собирать чужой трафик и не создавать большой чувствительный архив.
Сопоставьте Route, Tunnel и Gateway diagnostics
Запустите официальную диагностику для узкого временного окна и сохраните результаты Gateway, Tunnel, Route и соответствующие журналы. Сверьте их по UTC с тремя контрольными потоками. Route diagnostics нужны, чтобы проверить ожидаемый путь, Tunnel — состояние соединения, а Gateway — события самого шлюза; ни один файл по отдельности не доказывает причину потери. Если запрос и ответ видны на удалённой стороне, но ответ отсутствует у шлюза, исследуйте обратный маршрут и промежуточные правила. Если ответ проходит шлюз, но не достигает клиента, область сужается к клиентской стороне. Не публикуйте полный архив диагностики в форуме.
Передайте минимальный пакет без секретов
В обращение включите схему из двух обезличенных узлов, тип VPN, регион, время UTC, три строки протокольной матрицы, версии клиента и результат каждого диагностического слоя. Реальные IP замените устойчивыми обозначениями, но сохраните маски префиксов отдельно в защищённом канале поддержки. Не прикладывайте shared keys, сертификаты, идентификаторы подписки, полный конфиг и незамаскированный packet capture. Эскалация готова, когда инженер может увидеть точку исчезновения ответа и сопоставить её с логами. Остановитесь до изменения production-маршрутов, если проблема касается нескольких сетей или критичной службы: без окна и плана отката такой эксперимент расширяет инцидент.
Материал подготовлен самостоятельно с автоматизацией и редакционно проверен 30 июля 2026 года по публичному сигналу и официальной документации Azure; реальные адреса, ключи и конфигурации не использовались.
Источники и проверка
- Microsoft Learn — VPN Gateway packet capture проверено 2026-07-30
- Microsoft Learn — Troubleshoot VPN Gateway using Azure diagnostics проверено 2026-07-30
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.