Azure GatewaySubnet सेटअप: गेटवे से पहले जगह आरक्षित करें

पोर्टल में वर्चुअल नेटवर्क खोलें और सबनेट ब्लेड छूने से पहले एड्रेस स्पेस देखें। अगर वह /24 पहले से वर्कलोड सबनेट में बँटा है और कुछ खाली नहीं है, तो /27 आरक्षण के लिए जगह नहीं है, और अंत में आपको या तो फिर से बाँटना होगा या VNet बढ़ाना होगा, जो दूसरी समीक्षा वाला दूसरा बदलाव है। पहले जगह तय करें, फिर सबनेट बनाएँ।

यह क्रम मायने रखता है क्योंकि गेटवे सबनेट कोई विशेष नाम वाला वर्कलोड सबनेट नहीं है। यह प्रबंधित गेटवे इंस्टेंस के लिए एड्रेस आरक्षण है, और आरक्षण गलत होने पर Azure गेटवे को अस्वीकार कर देगा।

एड्रेस स्पेस से शुरू करें

कुछ भी टाइप करने से पहले VNet प्रीफ़िक्स, वर्कलोड सबनेट और गेटवे आरक्षण एक पंक्ति में लिखें। 10.60.0.0/16 पर VNet में जगह है; अंत में एक रेंज चुनें ताकि वर्कलोड की वृद्धि सटी रहे।

उदाहरण के लिए, 10.60.255.192/26 गेटवे के लिए 64 एड्रेस छोड़ता है जबकि वर्कलोड 10.60.0.0/20 में रहते हैं। यह एड्रेस नियोजन का उदाहरण है, आकार का वादा नहीं। Microsoft वर्तमान में गैर-Basic VPN गेटवे के लिए /27 या बड़ा मांगता है, जहाँ बड़ा का अर्थ अधिक एड्रेस है: /26 64 देता है, जबकि /28 16 देता है। ऊपर की ओर पूर्णांकित करें, कभी नीचे नहीं, जब तक एड्रेस योजना चलायमान है।

सटीक नाम के साथ सबनेट बनाएँ

पोर्टल में सबनेट जोड़ें और नाम GatewaySubnet बिल्कुल वैसा लिखें, बड़ा G और बड़ा S, बिना स्पेस या प्रत्यय। Azure उस स्ट्रिंग से मिलान करता है, इसलिए Gateway-Subnet या gateway ऐसा सबनेट बनाता है जिसे गेटवे सेवा इस्तेमाल नहीं करेगी।

CLI से वही चरण, जिसे समीक्षा में लिखना आसान है:

az network vnet subnet create --resource-group rg-hub --vnet-name vnet-hub --name GatewaySubnet --address-prefixes 10.60.255.192/26

सबनेट खाली छोड़ें। कोई VM नहीं, कोई निजी endpoint नहीं, कोई सेवा प्रत्यायोजन नहीं। अगर वहाँ पहले से कुछ रहता है, तो परिनियोजन विफल हो जाता है और त्रुटि शायद ही रास्ते में आने वाले संसाधन का नाम लेती है, इसलिए शुरू करने से पहले सबनेट की संसाधन सूची देखें।

प्रबंधित सबनेट को वर्कलोड नियमों से मुक्त रखें

इस सबनेट से नेटवर्क सुरक्षा समूह न जोड़ें; Microsoft इसे असमर्थित बताता है। ऐसी रूट तालिका न जोड़ें जिसका डिफ़ॉल्ट रूट 0.0.0.0/0 कहीं भेजता हो, क्योंकि इससे गेटवे का संचालन टूट सकता है, और गेटवे रूट प्रसार चालू रखें।

जो एक्सेस प्रतिबंध आप वास्तव में चाहते थे, उन्हें वर्कलोड सबनेट पर या निरीक्षण सीमा पर रखें। GatewaySubnet को सामान्य सबनेट की तरह मानना वह गलती है जो ऐसा गेटवे बनाती है जो साफ़ तैनात होता है और फिर कोई ट्रैफ़िक पार नहीं करता।

फ़ोर्स्ड टनलिंग का अपना प्रलेखित डिज़ाइन है। गेटवे सबनेट पर तत्काल बनाया गया डिफ़ॉल्ट रूट वह नहीं है।

उन निर्भरताओं की जाँच करें जो पोर्टल नहीं दिखाता

बनाएँ दबाने से पहले सूची पर जाएँ: सटीक नाम, VNet स्पेस के भीतर प्रीफ़िक्स, ऑन-प्रिमाइसिस रेंज से कोई अतिव्याप्ति नहीं, भीतर कोई वर्कलोड संसाधन नहीं, कोई NSG नहीं, और डिफ़ॉल्ट रूट वाली कोई रूट तालिका नहीं। इनमें से हर एक ने वास्तविक परिनियोजन तोड़ा है। फिर व्यापक डिज़ाइन की पुष्टि करें: ऑन-प्रिमाइसिस पक्ष के लिए स्थानीय नेटवर्क गेटवे, वे एड्रेस स्पेस जिन्हें रूट करने की अपेक्षा है, और क्या सक्रिय-सक्रिय या सहअस्तित्व की योजना है। ये चुनाव आकार की बातचीत बदल देते हैं, और इन्हें अभी तय करना कहीं सस्ता है।

जब कोई पूछे कि सबनेट VM क्यों नहीं रख सकता, तो उद्धृत करने वाला पृष्ठ Azure गेटवे सेटिंग्स संदर्भ है।

अगर गेटवे पहले से मौजूद है

गेटवे सबनेट का आकार बदलना या उसे बदलना मास्क संपादन नहीं है। पहले गेटवे के SKU और पीढ़ी के लिए समर्थित परिवर्तन प्रक्रिया देखें, और आश्रित ऑब्जेक्ट सूचीबद्ध करें: कनेक्शन, सार्वजनिक IP, रूटिंग और कोई भी पुनर्प्राप्ति आवश्यकता।

अगर प्रक्रिया के लिए गेटवे को फिर से बनाना ज़रूरी है, तो इसे विंडो और रोलबैक के साथ सेवा स्थानांतरण के रूप में योजनाबद्ध करें। आपने जो आरक्षण चुना, आकार का कारण और जो नियम जानबूझकर नहीं जोड़े, उन्हें दर्ज करें, ताकि अगला समीक्षक NSG जोड़कर खाली सबनेट को ठीक न करे।