Azure P2S VPN मा स्थिर IP: क्लाइन्टको ठेगाना किन बदलिन्छ
Azure point-to-site ले प्रत्येक जडानमा पूलबाट अर्को खाली ठेगाना दिन्छ, त्यसैले स्थिर क्लाइन्ट IP हुँदैन। यसको सट्टा दायरा वा पहिचानमा पहुँच आधारित गर्नुहोस्।
प्रत्येक Azure point-to-site क्लाइन्टले प्रमाणीकरणको समयमा पूलबाट ठेगाना पाउँछ र त्यो जडान चलिरहेको अवधिभर मात्र राख्छ। कुनै आरक्षण तालिका छैन, प्रयोगकर्ता-अनुसार म्यापिङ छैन, र “यो व्यक्तिलाई सधैं 172.16.0.10 देऊ” भन्ने अर्थको गेटवे सेटिङ छैन। यही एउटा संयन्त्रले मानिसहरूले पछि भेट्ने दुवै लक्षण व्याख्या गर्छ: पहिले मिल्ने प्रयोगकर्तासँग अब नमिल्ने NSG नियम, र कसैले जानाजानी नथपेको मेसिन चुपचाप भित्र पसाउने अनुमति सूची। नियमलाई अझ चलाख IP नियमले बदल्नाले दुवैमध्ये केही सुधार्दैन, किनकि नियमले नाम लिने कुरा तपाईंले नियन्त्रण नगरेको तालिकाअनुसार फेरि बाँडिन्छ।
पूल क्षमता हो, पहिचान होइन। एकै समयका टनेलहरूले अद्वितीय ठेगाना पाउन् भनेर यो छ, र लिज सकिने क्षणमै यसले तिनलाई पुनः प्रयोग गर्छ। यो स्पष्ट भएपछि, उपयोगी प्रश्न “यो क्लाइन्टलाई कसरी पिन गर्ने” रहँदैन र “गेटवेले पुनः प्रयोग नगर्ने कुन कुराविरुद्ध मैले नियम लेख्न सक्छु” बन्छ।
क्लाइन्ट जडान हुँदा गेटवेले वास्तवमा के गर्छ
गेटवेले कन्फिगर गरिएको क्लाइन्ट ठेगाना पूल राख्छ र त्यसलाई लिज तालिकाको रूपमा लिन्छ। जडान गर्दा यसले अर्को खाली ठेगाना, व्यवहारमा उपलब्ध सबैभन्दा कम, लिन्छ र क्लाइन्ट विच्छेद नगरेसम्म वा लिज नसकिएसम्म त्यो टनेल एडाप्टरलाई तोक्छ। निर्णय क्रमले गर्छ, पहिचानले होइन: शान्त अवधिपछि पहिलो पुनः जडान गर्नेले त्यो क्षणमा संयोगवश खाली रहेको सबैभन्दा कम ठेगाना पाउँछ।
पूलको आकारले व्यवहार लुकाउँछ। परीक्षकको संख्याभन्दा एक-दुई ठेगाना ठूलो प्रयोगशाला पूल निर्धारक देखिन्छ, किनकि त्यही ल्यापटप हरेक बिहान उही क्रममा पुनः जडान हुन्छ। तेस्रो मेसिन थप्नुहोस्, पूलको आकार बदल्नुहोस्, वा खाजाको समयमा सत्र जोडिएको राख्नुहोस् — ढाँचा भाँचिन्छ। ठेगाना कहिल्यै स्थिर थिएन; लाइन स्थिर थियो।
point-to-site कन्फिगरेसनको कुनै पनि परिवर्तनले लिज ठाउँ पनि रिसेट गर्छ। फरक प्रमाणीकरण प्रकार, आकार बदलिएको पूल, नयाँ पूल दायरा, वा भत्काएर फेरि बनाइएको गेटवे — सबैले क्लाइन्टहरूलाई उनीहरूको पुरानो ठेगानासँग अब नमिल्ने पूलमा फर्काउँछन्। त्यो परिवर्तनमा केहीले पनि तपाईंको NSG लाई छुँदैन, त्यसैले बिग्रन स्वतः भएको जस्तो देखिन्छ।
यो करिब एक मिनेटमा देख्न सकिन्छ। जडान गर्नुहोस्, क्लाइन्टको जडान विवरणमा टनेल ठेगाना टिप्नुहोस्, विच्छेद गर्नुहोस्, दोस्रो मेसिन जडान गर्नुहोस्, त्यसपछि पहिलो फेरि जडान गर्नुहोस्। फर्किएर पाइने ठेगाना दोस्रो मेसिनले के राखेको छ भन्नेमा निर्भर छ, र कुनै पनि पोर्टल सेटिङले मागअनुसार अघिल्लो ठेगाना पुनर्स्थापित गर्दैन।
क्लाइन्ट IP मा आधारित NSG वास्तवमा जडान क्रमको बारेमा एउटा नियम हो
मानिसहरूले पहिलो लेख्ने नियम स्पष्ट छ: व्यवस्थापन VM को NIC वा त्यसको सबनेटमा इनबाउन्ड नियम, स्रोतको रूपमा VPN क्लाइन्टको आन्तरिक ठेगाना। यो छोटो छ, लेखिएको दिन परीक्षण पास गर्छ, र पूलमा एकभन्दा बढी खाली ठेगाना हुनासाथ असफल हुन्छ।
यसबाट असफलताका दुई तरिका आउँछन्, र तीमध्ये एउटा मात्र बगजस्तो देखिन्छ। वैध प्रयोगकर्तालाई अस्वीकार गरिन्छ किनकि नियमले नाम लिने ठेगाना त्यतिबेला अरू कसैसँग छ, र त्यो झन्झटिलो सहयोग टिकटको रूपमा आउँछ। वा अनपेक्षित प्रयोगकर्तालाई अनुमति दिइन्छ किनकि उसले नियमले अझै विश्वास गर्ने ठेगाना उत्तराधिकारमा पाएको छ, र कसैले पहुँचको अडिट नगरेसम्म त्यो केही पनि भएर आउँदैन।
नियम लिजलाई पछ्याउने भएकाले प्रभावी नीति “पहिलो जडान गर्नेले व्यवस्थापन पहुँच पाउँछ” भनेर पढिन्छ। यो मनसायको पोशाक लगाएको जडान क्रमको वर्णन हो, र कुनै नियम सफाईले त्यसलाई मनसायको अभिव्यक्ति बनाउँदैन।
क्लाइन्ट लिज र गेटवे ठेगाना फरक वस्तु हुन्
धेरैजसो भ्रम एउटा शब्दबाट आउँछ। गेटवेसँग तुलनात्मक रूपमा स्थिर सार्वजनिक IP छ; क्लाइन्टसँग पूलबाट आउने निजी ठेगाना छन्, जो स्थिर छैनन्। जोन-अनावश्यक नभएको VPN गेटवेका लागि सार्वजनिक IP गतिशील रूपमा बाँडिन्छ, तर यो आकार परिवर्तन, रिसेट र नियमित मर्मत पार गर्छ — गेटवे आफै मेटिएर फेरि बनाइँदा मात्र बदलिन्छ। जोन-अनावश्यक र जोनल गेटवे SKU हरूले Standard SKU को सार्वजनिक IP प्रयोग गर्छन्, र त्यो बाँडफाँट स्थिर हुनुपर्छ।
त्यही स्थिरता ऑन-प्रिमाइसेस साझेदारलाई आफ्नो कन्फिगरेसनमा चाहिन्छ, र यसले व्यक्तिगत क्लाइन्ट पहिचान गर्नेबारे केही भन्दैन। साझेदारले कुन ठेगाना देख्ने भनी सोध्दा उत्तर site-to-site अन्तर्गत गेटवेको सार्वजनिक IP, वा साझा NAT दायरा हो — कहिल्यै ल्यापटपको टनेल लिज होइन।
समूह पूलले तपाईंलाई नियम लेख्न लायक दायरा दिन्छ
Virtual WAN point-to-site ले प्रयोगकर्ता समूहलाई समर्थन गर्छ, र हरेक समूहलाई आफ्नै क्लाइन्ट ठेगाना पूल तोक्न सकिन्छ। सदस्यता पहिचानले निर्धारण गर्छ, त्यसैले क्लाइन्ट पर्ने दायरा अनुमानयोग्य हुन्छ: सञ्चालन एउटा दायरामा, ठेकेदार अर्कोमा, र दायरा त्यस्तो कुरा हो जसको नाम फायरवाल वा NSG नियमले अनुमान नगरी लिन सक्छ।
नतिजाको नियम समूहको आकार यस्तो छ जुन तपाईंले समीक्षा गर्न सक्नुहुन्छ:
- हरेक दर्शकका लागि एउटा पूल, टाउकोको गणनाभन्दा एकै समयका सत्रको शिखरका लागि नापिएको;
- समूह सदस्यता पहिचानमार्फत हेरिन्छ, कोही सामेल हुनासाथ नियम सम्पादन गरेर होइन;
- NSG वा Azure Firewall नियम पूल दायराविरुद्ध लेखिन्छन्, कहिल्यै व्यक्तिगत लिजविरुद्ध होइन;
- कहिल्यै दायरा साझा गर्न नहुने दर्शकका लागि छुट्टै हब वा गेटवे।
| Rule target | Survives a reconnect | What it still cannot express |
|---|---|---|
| Client tunnel address | No | Follows connection order and admits whoever holds the address next |
| Whole client pool | Yes | Grants every connected client identical access |
| Virtual WAN group pool | Yes | Only as reliable as group membership |
| Gateway public IP | Until the gateway is recreated | Identifies the site, not the person |
पूरै पूल अनुमति सूचीमा राख्नु इमानदार तर मोटो हुन्छ: त्यो दायराको हरेक जोडिएको क्लाइन्टले समान पहुँच पाउँछ। यो त्यस्तो नीति निर्णय हो जो समीक्षामा पत्ता लगाउनुभन्दा ठूलो स्वरले भन्न लायक छ। अझै हरेक व्यक्तिका लागि उत्तर चाहिने कुरा भूमिका तोकाइमार्फत स्रोतकहाँ पर्छ, प्याकेट फिल्टरकहाँ होइन।
जब परिनियोजन Virtual WAN मा जान सक्दैन
धेरै गेटवे सामान्य VPN गेटवे नै रहन्छन्, र Virtual WAN मा जानु सामान्य परिवर्तन होइन। व्यावहारिक उत्तर यो हो कि प्रति-प्रयोगकर्ता निर्णय प्याकेट फिल्टरबाट प्रयोगकर्ता को हो भन्ने पहिलेै थाहा हुने कुरामा सार्नु।
स्रोत-स्तरको पहिचान सबैभन्दा सस्तो संस्करण हो। Storage, SQL र Key Vault सबैले प्रति-प्रयोगकर्ता वा प्रति-समूह भूमिका तोकाइसँग Entra ID प्रमाणीकरण समर्थन गर्छन्, त्यसैले VPN ले पूर्वाधार पहुँच मात्र प्रमाणित गर्नुपर्छ। नाम भएका खातासहितको जम्प होस्टले प्रशासनिक कामका लागि उही काम गर्छ, किनकि होस्टले व्यक्ति अभिलेख गर्छ र टनेलले प्याकेट मात्र बोक्छ। क्लाइन्टहरूलाई DNS मा दर्ता गर्नु र संख्याको सट्टा नामलाई अनुमति दिनु नियमलाई एक तह माथि उठाउँछ। एप्लिकेसन-स्तरको पहिचान — प्रमाणपत्र विषय, टोकन दाबी, समूह सदस्यता — निर्णय गर्न नेटवर्कलाई होइन, एप्लिकेसनलाई भनिएको खण्डमा काम गर्छ।
स्थिर स्रोत ठेगानामा जोड दिने साझेदारका लागि उत्तर निर्धारित पियर प्रिफिक्ससहित site-to-site वा ExpressRoute हो। उनीहरूले पियर प्रिफिक्सलाई अनुमति दिन्छन्, उनीहरूको तर्फ देखिने ठेगाना गेटवेको हुन्छ, र कसैले ल्यापटप रिबुट गर्दा त्यो बदलिँदैन।
अर्को अनुमति सूची सम्पादन गर्नुअघि पूल जाँच्नुहोस्
पूलका दुई गुणले मानिसहरूले क्लाइन्टमाथि लगाउने अधिकांश व्यवहार निम्त्याउँछन्। धेरै सानो पूलले लिज छिटो पुनः प्रयोग गर्छ, त्यसैले ठेगाना निरन्तर सर्दै देखिन्छन् र ठेगानामा आधारित कुनै पनि नियम डिजाइनदेखि नै अस्थिर देखिन्छ। ऑन-प्रिमाइसेस दायरा वा भर्चुअल नेटवर्क ठाउँसँग ओभरल्याप हुने पूलले कुनै फायरवाल नियमले नसुधार्ने राउटिङ अस्पष्टता सिर्जना गर्छ।
नियम छुनुअघि तीन कुरा एउटै पृष्ठमा राख्नुहोस्: point-to-site पूल, भर्चुअल नेटवर्क ठेगाना ठाउँ र ऑन-प्रिमाइसेस दायरा। ती ओभरल्याप हुनु हुँदैन, र पूललाई हरेक एकै समयको क्लाइन्टका लागि ठाउँ तथा पुनः जडानका लागि मार्जिन चाहिन्छ।
त्यसपछि यो क्रममा चक्र बन्द गर्नुहोस्:
- दुई मेसिनबाट दुवै क्रममा जडान गरी ठेगाना तुलना गर्नुहोस्; यदि ती अदलबदल हुन सक्छन् भने ठेगानामा आधारित कुनै नियम सुरक्षित छैन।
- गेटवे Virtual WAN हो कि जाँच्नुहोस्; यदि हो भने, प्रति-ठेगाना नियमको सट्टा समूह पूल प्रयोग गर्नुहोस्।
- नियम गलत व्यक्तिसँग मिल्दा के हुन्छ सोध्नुहोस्; उत्तर पहुँच घटना भए, नियन्त्रण पहिचानतर्फ सार्नुहोस्।
- कुन दायरा कुन समूहको हो, NSG परिभाषासँगै त्यही भण्डारमा लेख्नुहोस्।
- पूल, प्रमाणीकरण वा गेटवे परिवर्तनपछि फेरि परीक्षण गर्नुहोस्, किनकि ती परिवर्तनले घोषणा नगरी म्यापिङ फेरि लेख्छन्।