Смяна на публичен 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

Четете неуспеха на валидацията, вместо да го повтаряте. Обичайните причини са изоставена зависимост, тип ресурс, който не може да се мести, или заключване на някоя от групите ресурси. Ако преместването е невъзможно, пресъздайте в целта и превключете: потвърдете маршрутизацията и удостоверяването от тестова подмрежа, спрете старите връзки, вместо да ги изтривате, после премахнете стария път в следващ прозорец.

Когато шлюзът изглежда изчезнал, проверете контекста

Грешката „не е намерено“ обикновено е грешка в обхвата. Акаунт с няколко абонамента насочва cmdlet към грешния и съобщението обвинява ресурса. Търсете обекта по пълния му 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 записът е сменен и предишната му стойност е записана

Подобни статии