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 व्याख्यांसह त्याच भांडारात नोंदवा.
- पूल, प्रमाणीकरण किंवा गेटवे बदलानंतर पुन्हा चाचणी करा, कारण ते बदल जाहीर न करता मॅपिंग पुन्हा लिहितात.