Почему добавление префикса Azure VPN разрывает подключение

Префикс, добавленный к неправильному объекту Azure, даёт подключение, которое сообщает Connected и ничего не передаёт, и это самый дорогой вид ошибки в этом стеке. Задействованы три ресурса, и только один из них владеет удалённым адресным пространством: шлюз виртуальной сети, локальный сетевой шлюз, описывающий удалённую сторону, и подключение, которое их соединяет. Префикс принадлежит локальному сетевому шлюзу, подключение нужно перестроить, чтобы изменение вступило в силу, а сам шлюз обычно остаётся нетронутым. Порядок не обсуждается, и портал показывает лишь часть его.

Три объекта, один из которых хранит префикс

Адресное пространство виртуальной сети отвечает на другой вопрос: что живёт внутри Azure. Добавление удалённого префикса там не направляет трафик туда, оно лишь расширяет пространство, которое платформа считает своим, а это может конфликтовать с реальным удалённым диапазоном. Локальный сетевой шлюз — это объект, который хранит удалённые префиксы, а подключение ссылается на оба шлюза плюс заранее общий ключ.

Есть и третья оговорка, которую стоит держать в голове. GatewaySubnet размещает управляемые экземпляры шлюза, должен носить именно это имя, и для SKU, не являющихся Basic, ожидается, что он будет не меньше /27.

Ничто другое не относится к этой подсети, и изменение префикса не имеет причин её трогать. Префикс, отсутствующий в локальном сетевом шлюзе, недостижим, что бы ни говорило состояние подключения, потому что шлюз предлагает только те префиксы, о которых его уведомили при согласовании туннеля. Поэтому симптом асимметричен: туннель поднят, ассоциация безопасности в порядке, и одна подсеть никогда не появляется в селекторах трафика. Если одного удалённого диапазона не хватает, пока соседние работают, перестаньте смотреть на туннель и прочитайте локальный сетевой шлюз.

Почему удаляется именно подключение

Объект подключения фиксирует согласованную конфигурацию на весь срок своей жизни. Поэтому документированная процедура сначала удаляет подключение, обновляет локальный сетевой шлюз, а затем создаёт подключение заново с тем же общим ключом. Экземпляры шлюза не пересоздаются ради изменения только префикса, что ограничивает простой разборкой подключения, а не повторным развёртыванием шлюза.

Это удаление и есть простой, поэтому относитесь к нему как к плановому изменению с началом и ожидаемым концом, а не как к быстрой правке. В PowerShell последовательность короткая: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, затем Set-AzLocalNetworkGateway с новым -AddressPrefix массивом, затем New-AzVirtualNetworkGatewayConnection с тем же -SharedKey и теми же шлюзами. Повторное использование ключа важно, потому что удалённая сторона не перенастраивается, и новый ключ означает согласование с тем, кто владеет удалённым устройством. Если это устройство обслуживает другая команда, согласуйте с ней окно, прежде чем что-либо удалять.

Когда нужно пересоздавать сам шлюз

Второй ответ, который ходит вокруг этой проблемы, говорит, что шлюз нужно создать заново и ключ снова обменять. Это верно для другого набора операций: смены типа шлюза или SKU, перехода между «точка — сайт» и «сайт — сайт» или ремонта шлюза, чья собственная конфигурация неверна. Такие изменения действительно меняют ресурс шлюза, поэтому пересоздание действительно необходимо.

Шлюзу, созданному для «точка — сайт», нельзя просто назначить подключение «сайт — сайт». Конфигурацию «точка — сайт» нужно удалить, а шлюз создать заново, что также даёт новый общий ключ и новый клиентский пакет.

Пакет «точка — сайт» заслуживает отдельного примечания, потому что он истекает. Портал создаёт файл с коротким сроком жизни, поэтому практический подход — скачать его один раз и распространить вместе с клиентским сертификатом, а не отправлять пользователям ссылку на портал, которая умрёт к моменту клика. К вопросу о префиксе ничего из этого не относится. Держать две процедуры раздельно — вся дисциплина: префиксы — это изменение на уровне подключения, а свойства шлюза — изменение на уровне шлюза.

Читайте состояние, а не значок портала

Читайте состояние из ресурса, а не из значка на портале. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 возвращает ConnectionStatus вместе со счётчиками входящих и исходящих байт, и именно счётчики отличают подключённый туннель, который ничего не несёт, от того, который так и не установился.

Счётчики, которые перестают расти в середине передачи, указывают на путь, а не на аутентификацию. Счётчики, которые вообще не двигаются, указывают на набор префиксов или общий ключ.

Таймеры объясняют класс отключений, которые ошибочно приписывают VPN. Балансировщик нагрузки Azure закрывает неактивные потоки после настроенного тайм-аута, по умолчанию четыре минуты на момент написания этих заметок, и его можно увеличить, поэтому сервер OpenVPN на виртуальной машине без keepalive может падать каждые несколько минут, пока всё остальное выглядит здоровым. Шлюз, который платформа перезапускает циклически, тоже может прервать подключение VNet к Web App, и этот сбой находится на стороне платформы, а не в клиентской конфигурации. Признак — следует ли отключение фиксированному интервалу или изменению, которое сделали вы.

Держите три объекта и их значения в одной записи: адресное пространство виртуальной сети, список префиксов локального сетевого шлюза и ссылку на общий ключ подключения. статья PowerShell про «сайт — сайт» документирует команды локального сетевого шлюза и порядок, к которому они относятся. Сравнение изменения префикса с памятью — это способ дважды пересобрать работающий туннель.

Затем проверьте в том порядке, в котором меняли: локальный сетевой шлюз показывает новый список префиксов, подключение снова Connected, а счётчики двигаются, когда вы отправляете трафик на хост в новом диапазоне. Если третий шаг не удался, пока первые два проходят, удалённая сторона не приняла новый селектор трафика, и удалённому устройству нужна соответствующая запись фазы 2. Это разговор с другим концом туннеля, а не ещё одно изменение в Azure.