Диагностическая матрица для Azure site-to-site VPN с двумя провайдерами: как не спутать резервирование экземпляров шлюза, состояние IPsec-туннелей и выбор маршрута BGP.
Сначала назовите три разных механизма
Зафиксируйте схему без секретов: сколько экземпляров Azure VPN Gateway участвует, сколько соединений S2S создано и к какому провайдеру относится каждое из них. Документация Microsoft разделяет active-standby самого шлюза и active-active, где оба экземпляра имеют туннели. Поэтому переход платформы со штатного экземпляра на резервный нельзя считать доказательством, что выбран нужный ISP. В рабочей заметке сделайте три строки: «экземпляр Azure», «IPsec-туннель ISP A или B», «BGP-маршрут до целевой сети». Если изменение в одной строке автоматически записывается как успех другой, диагноз ещё не сформирован. Не публикуйте адреса peer, shared key, ASN и экспорт конфигурации.
Постройте матрицу симптома, а не одну зелёную лампу
Для каждого провайдера отдельно запишите состояние соединения IPsec, состояние BGP peer и наличие нужного префикса среди learned routes. Microsoft в руководстве по BGP troubleshooting рассматривает эти проверки раздельно: поднятый туннель не заменяет установленную BGP-сессию, а установленная сессия не доказывает, что нужный маршрут принят и выбран. Снимок делайте в один момент и добавляйте локальное время. Если ISP A недоступен, но peer ISP B и его маршрут присутствуют, это другой класс события, чем автоматическая смена экземпляра Azure при двух исправных каналах. Не запускайте искусственный отказ, пока не зафиксировано исходное состояние и нет согласованного окна.
Сравните три сценария отказа
В строке «экземпляр Azure» ожидайте платформенное переключение active-standby, описанное Microsoft, и проверяйте, сохранились ли соединения. В строке «туннель ISP» отмечайте, какой конкретно IPsec-путь потерян и осталась ли BGP-достижимость через второй. В строке «выбор маршрута» оба туннеля и оба peer могут оставаться рабочими, но предпочтение определяется полученными маршрутами и политикой на вашей стороне. Такая матрица не выдаёт универсальную конфигурацию: она показывает, где именно должен находиться механизм решения. Не называйте BGP автоматическим лекарством от любого отказа; сначала подтвердите, что обе стороны действительно обмениваются нужными префиксами.
Определите безопасный критерий остановки
Остановите самостоятельные изменения, если нет актуальной схемы, второго подтверждённого пути управления или понимания, кто контролирует локальную BGP-политику. Не меняйте одновременно веса, объявления префиксов, параметры соединений и режим Azure gateway: после такого эксперимента невозможно связать результат с одной причиной. Для эскалации достаточно обезличенного набора: время события, какой ISP считался основным, состояния двух IPsec-соединений, состояния peer, присутствие целевого префикса и факт смены экземпляра Azure. Секреты, публичные адреса и полный export не нужны. Успех — заранее описанный путь переключается и возвращается при согласованном тесте, а не просто все индикаторы снова зелёные.
Материал подготовлен редакцией VOne с применением ИИ для структурирования; технические утверждения вручную сверены с указанной официальной документацией, а форумная ветка использована только как обезличенный сигнал боли.
Источники и проверка
- Microsoft Learn — About highly available gateway configurations проверено 2026-07-31
- Microsoft Learn — BGP overview for Azure VPN Gateway проверено 2026-07-31
- Microsoft Learn — Troubleshoot Azure VPN Gateway BGP проверено 2026-07-31
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.