Azure VPN კარიბჭის საჯარო IP-ის შეცვლა და გამოწერის გადატანა

სახელმძღვანელო VPN კარიბჭის საჯარო IP-ის შეცვლისა და გამოწერებს შორის გადატანისთვის, ინვენტარით, უკუქცევით და კონტექსტის შემოწმებებით, რომლებიც გვირაბებს მუშაობაში ინარჩუნებს.

Azure-ში სამ სხვადასხვა ობიექტს კარიბჭის მისამართი ჰქვია. კერძო მისამართი GatewaySubnet-იდან გამოიყოფა. საჯარო მისამართი ცალკე საჯარო IP რესურსია, რომელზეც კარიბჭის IP კონფიგურაცია მიუთითებს. გამოწერა და ღრუბლოვანი გარემო ის კონტექსტია, რომლითაც თქვენი shell პოულობს ერთ-ერთს. შეცვალეთ ერთი და დანარჩენი ორი ადგილზე რჩება, ამიტომ მისამართებზე მუშაობა ხშირად შუაში ჩერდება.

ამ ცვლილებებს ოთხ ეტაპად ვაკეთებ: ობიექტების ინვენტარი, გადაწყვეტილება, გადადის თუ არა საჯარო IP არსებულ კარიბჭეზე თუ კარიბჭე ახლიდან აშენდება, ცვლილების გამოყენება სანამ ძველი მისამართი ხელშია, და შემდეგ თითოეული გვირაბის შემოწმება ორივე მხრიდან სანამ რამეს წაშლით. ეტაპი, რომელსაც ხალხი გამოტოვებს, ინვენტარია.

სამი ობიექტიდან რომელს ცვლით სინამდვილეში

დაასახელეთ ობიექტი პორტალის გახსნამდე. VPN კარიბჭე კერძო მისამართს იღებს ქვექსელიდან, რომელსაც ზუსტად GatewaySubnet უნდა ერქვას, და Azure მას ამ პრეფიქსიდან ანიჭებს; მის დასამაგრებლად ზოგადი ველი არ არსებობს. მისამართი სტაბილურად მხოლოდ იმიტომ გამოიყურება, რომ ქვექსელი სტაბილურია. გადაამისამართეთ ქვექსელი ან ახლიდან ააშენეთ კარიბჭე და ის მათთან ერთად გადაინაცვლებს.

საჯარო მისამართი რედაქტირებადია, მაგრამ SKU წესები წყვეტს, ლეგალურია თუ არა რედაქტირება. Basic კარიბჭე Basic დინამიკურ საჯარო IP-ს ერწყმის, VpnGw SKU-ებს Standard სტატიკური სჭირდება, ხოლო ზონა-ჭარბი კარიბჭეს იმავე ზონების მქონე Standard საჯარო IP. არასწორი 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 სახელი, პარტნიორის ნებართვების სია, ფილიალის firewall, რომელიც ძველ 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

გვირაბები ცვივა სანამ კარიბჭე ხელახლა მზადდება. შორეულ მხარეს განრიგი სჭირდება: პარტნიორის firewall ძველ მისამართს სთავაზობს სანამ ვინმე შეასწორებს, და კავშირი, რომლის შორეული ბოლო წინა IP-ს მოელის, ქვემოთ რჩება რაც არ უნდა ჯანსაღად გამოიყურებოდეს Azure. ფანჯრამდე DNS TTL შეამცირეთ.

Point-to-site კლიენტებს ახალი პროფილი სჭირდებათ, რადგან ჩამოტვირთული პაკეტი ბოლო წერტილს ატარებს. კარიბჭის წინ საკუთარი DNS სახელი გათავისუფლებთ გადანაწილებისგან: სახელი შეინარჩუნეთ, ჩანაწერი შეცვალეთ.

კარიბჭის სხვა გამოწერაზე გადატანა

რესურსების გადატანა კრებულს გადააადგილებს და კარიბჭე მარტო მისი ყველაზე ნაკლებად სასარგებლო წევრია. ვირტუალური ქსელი, საჯარო IP რესურსები, ლოკალური ქსელური კარიბჭეები და კავშირები ერთად მოგზაურობენ, რადგან თითოეული მეორეზე მიუთითებს. სამიზნე გამოწერა იმავე tenant-ში უნდა იყოს, 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 წაშლის ნაცვლად გათიშული შეინახეთ სანამ დაბრუნების ფანჯარა დაიხურება, და პარტნიორისა და firewall-ის ცვლილებები ჩაწერეთ თანმიმდევრობით შესაბრუნებლად.

  • კონტექსტი მიმაგრებულია გამოწერაზე, რომელიც კარიბჭეს ფლობს
  • ძველი საჯარო IP შენახულია, მისი დამოკიდებულებები ჩაწერილი
  • ყოველი კავშირი მწვანე და ერთი რეალური მოთხოვნა მის გავლით
  • Point-to-site მომხმარებლები გადატანილი არიან განახლებულ პროფილზე
  • DNS ჩანაწერი შეცვლილია და წინა მნიშვნელობა ჩაწერილი

დაკავშირებული სტატიები