Змена публічнага 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-запіс зменены, і яго папярэдняе значэнне запісана

Падобныя артыкулы