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 परिभाषाओं वाले उसी भंडार में दर्ज करें।
- पूल, प्रमाणीकरण या गेटवे में किसी भी बदलाव के बाद फिर से परीक्षण करें, क्योंकि वे बदलाव बिना घोषणा किए मैपिंग फिर से लिख देते हैं।