Разбор связи двух независимых Azure Virtual WAN через IPsec, когда BGP-соседство поднимается, но маршруты с одинаковым ASN 65515 не изучаются: что проверить в эффективных маршрутах и где не поможет смена локальной настройки.
Сначала отделите туннель от распространения маршрутов
Зафиксируйте состояние IPsec-соединения, время последнего изменения и перечень ожидаемых префиксов без публикации публичных адресов, PSK или resource ID. Поднятый туннель подтверждает только транспорт между концами; он не доказывает, что BGP принял маршруты. С другой стороны, отсутствие туннеля делает анализ AS Path преждевременным. Составьте таблицу для каждого направления: объявляемый префикс, ожидаемый next hop, наличие в эффективных маршрутах и видимый AS Path. Не меняйте одновременно PSK, BGP и таблицы маршрутов. Если BGP-соседство не установлено, сначала решайте его; если соседство есть, но пропадают именно маршруты с повторяющимся ASN, проверяйте документированное ограничение Virtual WAN.
Проверьте фиксированное значение ASN по документации
Microsoft прямо указывает, что ASN VPN-шлюза виртуального хаба Virtual WAN всегда равен 65515. Для BGP поверх IPsec между разными Virtual WAN маршруты с тем же ASN в AS Path отбрасываются как защита от петли. Следовательно, поиск скрытого поля для произвольной смены ASN хаба не является продуктивной веткой. Это ограничение не следует переносить на любой Azure VPN Gateway без проверки типа ресурса. Запишите тип каждого хаба и путь соединения. Если один конец не Virtual WAN, архитектура другая. Не пытайтесь маскировать AS Path неподтверждёнными настройками устройства: такая мера может повлиять на предотвращение петель и требует проектирования владельцем сети.
Используйте эффективные маршруты как наблюдаемое доказательство
Официальная страница Azure об effective routes показывает поля Prefix, Next hop, Origin и AS Path. Снимите данные с обоих виртуальных хабов и отметьте, на каком этапе ожидаемый префикс исчезает. Не прикладывайте полный экспорт публично: он раскрывает адресное пространство и архитектуру. Для внутренней эскалации достаточно обезличенного префикса, направления, Origin и AS Path. Если маршрут виден на входной стороне, но отсутствует после связи между WAN и его путь содержит 65515, это согласуется с документированным предотвращением AS-loop. Если маршрут не появляется уже у первого хаба, одинаковый ASN между WAN ещё не объясняет проблему — проверяйте объявление, соединение и связанную таблицу.
Выберите документированный архитектурный выход
Microsoft для этого сценария указывает статическую маршрутизацию вместо BGP через IPsec между независимыми Virtual WAN с одинаковым ASN. Это архитектурное изменение, а не команда для немедленного исполнения. Перед ним проверьте симметрию, перекрытие префиксов, таблицы маршрутов и план отката в тестовой среде. Не меняйте production-маршруты без окна и владельца сети: ошибка может разорвать доступ к нескольким площадкам. Для обращения в Microsoft подготовьте типы хабов, регионы, состояние туннеля, обезличенные effective routes и ожидаемую топологию. Критерий успеха — нужные префиксы появляются с корректным next hop в обоих направлениях и проходит разрешённый контрольный трафик, а не только статус Connected.
Материал подготовлен самостоятельно с автоматизацией и редакционно проверен 30 июля 2026 года по обезличенному вопросу и официальной документации Azure; секреты и конфигурации клиентов не использовались.
Источники и проверка
- Microsoft Learn — Global transit network architecture and Virtual WAN connectivity проверено 2026-07-30
- Microsoft Learn — View effective routes for a virtual hub проверено 2026-07-30
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.