Azure VPN गेटवे का सार्वजनिक IP बदलना और सदस्यता स्थानांतरित करना

VPN गेटवे का सार्वजनिक IP बदलने और उसे सदस्यताओं के बीच ले जाने की रनबुक, इन्वेंटरी, रोलबैक और संदर्भ जाँच के साथ जो सुरंगें चालू रखती है।

Azure में तीन अलग-अलग ऑब्जेक्ट को गेटवे पता कहा जाता है। निजी पता GatewaySubnet से आवंटित होता है। सार्वजनिक पता एक अलग सार्वजनिक IP संसाधन है जिसकी ओर गेटवे का IP कॉन्फ़िगरेशन इशारा करता है। सदस्यता और क्लाउड वातावरण वह संदर्भ हैं जिनसे आपका शेल एक या दूसरा ढूंढता है। एक बदलिए और बाकी दो जहाँ थे वहीं रहते हैं, इसलिए पता का काम इतनी बार आधे में रुक जाता है।

मैं ये बदलाव चार चरणों में करता हूँ: ऑब्जेक्ट की इन्वेंटरी, यह तय करना कि सार्वजनिक 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 नाम, साथी की अनुमति सूची, और पुराने 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 कितना भी स्वस्थ दिखे नीचे रहता है। खिड़की से पहले DNS TTL घटाइए।

पॉइंट-टू-साइट क्लाइंट को नई प्रोफ़ाइल चाहिए, क्योंकि डाउनलोड किया गया पैकेज एंडपॉइंट रखता है। गेटवे के आगे कस्टम 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 रिकॉर्ड बदला गया और उसका पिछला मान दर्ज हुआ

संबंधित लेख