Диагностическое дерево для BGP-соседства Azure VPN Gateway с APIPA-адресами: как проверить IPsec-туннель, ASN, адреса соседей и сторону-инициатор без рискованной смены маршрутов.
Начните с границы IPsec, а не с таблицы маршрутов
Официальное руководство Azure ставит проверку IPsec-туннеля перед разбором BGP. Зафиксируйте состояние соединения, время последней смены и наличие двустороннего трафика через уже разрешённые тестовые адреса. Если туннель не установлен, BGP-сессия поверх него не станет полезным следующим объектом диагностики. Не меняйте одновременно политики IPsec, адреса соседей и ASN: остановитесь на нижнем слое и сначала восстановите подтверждённый транспорт. Успех шага — туннель стабилен, а симптом локализован именно до BGP.
Сопоставьте две стороны как пары, а не по отдельности
В выгрузке конфигурации Azure найдите ASN шлюза, BGP peer IP и адрес, который должен использовать локальный VPN-узел. На локальной стороне запишите настроенный remote ASN и remote peer IP, затем составьте две взаимные пары: адрес Azure должен быть соседом локального устройства, а локальный адрес — соседом Azure. Сравнивайте значения посимвольно в закрытом рабочем документе. Несовпадение ASN или перепутанные адреса достаточно объясняют отсутствие соседства; публикация реальных адресов для этого не нужна.
Проверьте ограничения APIPA и пересечения
Документация Azure разрешает пользовательские APIPA-адреса BGP из диапазона 169.254.21.0–169.254.22.255. Адреса Azure и локального BGP-соседа не должны совпадать или пересекаться с уже используемыми значениями других подключений. Отдельно отметьте, заданы ли пользовательские APIPA-адреса на обеих сторонах. Не выбирайте новый адрес наугад во время инцидента: сначала инвентаризируйте существующие подключения, чтобы исправление одной сессии не создало конфликт для другой.
Учитывайте сторону, которая должна начать сессию
В сценарии с пользовательскими APIPA-адресами Azure указывает, что BGP-соединение должен инициировать локальный VPN-узел. Поэтому отсутствие исходящей попытки с локальной стороны — отдельная ветвь, а не доказательство неисправности Azure Gateway. Снимите состояние BGP-соседа и временные отметки попыток на локальном устройстве без раскрытия полной конфигурации. Если попытки есть, сопоставьте их с журналами шлюза; если их нет, передавайте владельцу локального устройства точную пару адресов и ожидаемый инициатор.
Эскалируйте с минимальным воспроизводимым набором
Соберите тип и SKU шлюза, состояние IPsec, ASN обеих сторон, маскированные BGP-адреса с сохранёнными последними октетами для различения, время попытки и статус соседа. Добавьте, использованы ли APIPA и несколько подключений, а также какие значения подтверждены экспортом Azure. Не прикладывайте pre-shared key, ключи доступа, полные конфиги или публичные адреса в открытый форум. Любые изменения маршрутов и BGP выполняйте только по утверждённому плану отката после того, как найдено конкретное несоответствие.
Материал написан самостоятельно с автоматизацией и проверен 29 июля 2026 года по обезличенному сигналу Microsoft Q&A и официальной документации Azure; конфигурации и адреса участников не использовались.
Источники и проверка
- Microsoft Learn — устранение неполадок BGP в Azure VPN Gateway проверено 2026-07-29
- Microsoft Learn — настройка BGP для Azure VPN Gateway проверено 2026-07-29
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.