Зміна загальнодоступної 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 змінено, попереднє значення зафіксовано

Схожі статті