Azure GatewaySubnet सेटअप: गेटवे अघि ठाउँ आरक्षित गर्नुहोस्
GatewaySubnet व्यवस्थापित गेटवे पूर्वाधार हो। पोर्टलले केही बनाउनु अघि ठ्याक्कै नाम, /27 वा ठूलो दायरा र राउटिङ नियमहरू निर्धारण गर्नुहोस्।
पोर्टलमा भर्चुअल नेटवर्क खोलेर सबनेट ब्लेड छुनु अघि ठेगाना ठाउँ हेर्नुहोस्। यदि त्यो /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 थपेर खाली सबनेट सुधार्न नपरोस्।