Смена общедоступного IP шлюза VPN Azure и перенос подписки

Регламент замены общедоступного IP шлюза VPN и его переноса между подписками: инвентаризация, откат и проверки контекста, которые держат туннели в работе.

В Azure адресом шлюза называют три разных объекта. Частный адрес выделяется из GatewaySubnet. Общедоступный адрес — это отдельный ресурс публичного IP, на который указывает конфигурация IP шлюза. Подписка и облачная среда — это контекст, с помощью которого оболочка находит тот или иной объект. Измените один, и два других останутся на месте — поэтому работа с адресами так часто останавливается на полпути.

Я выполняю эти изменения в четыре этапа: инвентаризация объектов, решение, переезжает ли публичный IP на существующем шлюзе или шлюз пересобирается, применение изменения, пока старый адрес ещё под рукой, и затем проверка каждого туннеля с обеих сторон до удаления чего-либо. Этап, который пропускают, — инвентаризация.

Какой из трёх объектов вы действительно меняете

Назовите объект, прежде чем открывать портал. Шлюз VPN берёт частный адрес из подсети, которая должна называться ровно GatewaySubnet, и Azure выделяет его из этого префикса; общего поля для его закрепления нет. Адрес выглядит стабильным только потому, что стабильна подсеть. Смените адресацию подсети или пересоберите шлюз — и он переедет вместе с ними.

Публичный адрес можно изменить, но правила SKU решают, законно ли это. Шлюз Basic сочетается с динамическим публичным IP Basic, SKU VpnGw требуют статического Standard, а зонорезервный шлюз требует публичного IP Standard с теми же зонами. Неверный SKU отклоняется раньше, чем упадёт туннель.

ObjectWhere it livesWhat a change forces
Private addressGatewaySubnet prefix, assigned at deploymentSubnet resize or rebuild, then routes, NSGs and peer review
Public addressPublic IP resource referenced by the IP configurationGateway reprovision, peer and allowlist edits, new client profiles
Subscription contextYour PowerShell or CLI sessionNothing in Azure, and it clears most not-found errors

Инвентаризация до любого движения

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

Get-AzContext | Select-Object Subscription, Tenant, Environment
Get-AzVirtualNetworkGateway -ResourceGroupName rg-hub -Name gw-hub |
  Select-Object Name, Sku, EnableActiveActive, IpConfigurations
Get-AzVirtualNetworkGatewayConnection -ResourceGroupName rg-hub |
  Select-Object Name, ConnectionStatus, ConnectionType

ID ресурсов важнее имён. Подключение хранит ссылки на шлюз и на локальный сетевой шлюз, и эти ID всплывают в скриптах, оповещениях и назначениях политик, которые никто не помнит. Перечислите и то, что находится вне Azure: DNS-имя, ведущее на адрес, список разрешений партнёра, филиальный межсетевой экран, который удерживает старый IP.

Замена публичного IP на работающем шлюзе

Сначала создайте заменяющий адрес в том же регионе и с набором зон, подходящим шлюзу, а старый ресурс оставьте на месте. Затем пересоберите конфигурацию IP и отправьте обновление одним вызовом. Этот вызов заменяет всю коллекцию конфигураций, поэтому активно-активному шлюзу нужны обе, иначе вы сохраните один туннель и потеряете другой.

$gw = Get-AzVirtualNetworkGateway -ResourceGroupName rg-hub -Name gw-hub
$pip = New-AzPublicIpAddress -Name pip-gw-hub-2 -ResourceGroupName rg-hub `
  -Location westeurope -AllocationMethod Static -Sku Standard
$conf = New-AzVirtualNetworkGatewayIpConfig -Name gwipconfig1 `
  -SubnetId $gw.IpConfigurations[0].Subnet.Id -PublicIpAddressId $pip.Id
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw -IpConfigurations $conf

Туннели падают, пока шлюз переподготавливается. Удалённой стороне нужен план: межсетевой экран партнёра продолжает предлагать старый адрес, пока кто-то его не изменит, а подключение, чей удалённый конец ждёт прежний IP, остаётся лежать, как бы здраво ни выглядел Azure. Понизьте TTL DNS до окна.

Клиентам «точка — сайт» нужен новый профиль, потому что скачанный пакет несёт конечную точку. Собственное DNS-имя перед шлюзом избавляет от повторной раздачи: сохраните имя, измените запись.

Перенос шлюза в другую подписку

Перенос ресурсов перемещает набор, и шлюз в одиночку — его наименее полезный участник. Виртуальная сеть, ресурсы публичного IP, локальные сетевые шлюзы и подключения едут вместе, потому что каждый содержит ссылку на другого. Целевая подписка должна быть в том же клиенте, Microsoft.Network должен быть там зарегистрирован, и нужны права на запись с обеих сторон.

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

az resource move --destination-group rg-hub `
  --destination-subscription-id 00000000-0000-0000-0000-000000000000 `
  --ids /subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/rg-hub/providers/Microsoft.Network/virtualNetworkGateways/gw-hub

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

Когда шлюз выглядит отсутствующим, проверьте контекст

Ошибка «не найдено» обычно является ошибкой области. Учётная запись с несколькими подписками направляет командлет в неверную, и сообщение обвиняет ресурс. Ищите объект по полному ID ресурса: ID несёт свою подписку, поэтому если он разрешается, ничего не пропало, а ваш контекст по умолчанию неверен.

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

Set-AzContext -SubscriptionId 11111111-1111-1111-1111-111111111111
Get-AzResource -ResourceId /subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/rg-hub/providers/Microsoft.Network/virtualNetworkGateways/gw-hub

Проверьте с обеих сторон до уборки

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

Get-AzVirtualNetworkGatewayBGPPeerStatus -VirtualNetworkGatewayName gw-hub -ResourceGroupName rg-hub
Get-AzEffectiveRouteTable -NetworkInterfaceName nic-app -ResourceGroupName rg-app

Держите старый публичный IP отсоединённым, а не удалённым, пока окно отката не закроется, и запишите правки у партнёра и на межсетевом экране, чтобы их можно было отменить по порядку.

  • Контекст закреплён за подпиской, которой принадлежит шлюз
  • Старый публичный IP сохранён, его зависимости записаны
  • Каждое подключение зелёное и один настоящий запрос через него
  • Пользователи «точка — сайт» переведены на обновлённый профиль
  • Запись DNS изменена, прежнее значение зафиксировано

Похожие статьи