Azure पॉइंट-टू-साइट VPN आपका सार्वजनिक IP क्यों नहीं बदलता
पॉइंट-टू-साइट टनल केवल वर्चुअल नेटवर्क के रूट ले जाती है, इसलिए जब तक फ़ोर्स्ड टनलिंग और फ़ायरवॉल SNAT एग्रेस को Azure में नहीं ले जाते, आपका सार्वजनिक IP स्थानीय ही रहता है।
मैं Windows लैपटॉप पर Azure VPN क्लाइंट जोड़ता हूँ, पता-प्रतिध्वनि पृष्ठ खोलता हूँ और वही सार्वजनिक पता देखता हूँ जो मेरे घरेलू राउटर ने दिया था। इस बीच 10.20.0.4 पर जंप बॉक्स जवाब देता है और एक निजी एंडपॉइंट नाम हल होता है, इसलिए टनल टूटी नहीं है। पॉइंट-टू-साइट गेटवे ठीक वही कर रहा है जो उसका डिफ़ॉल्ट कॉन्फ़िगरेशन कहता है: निजी प्रीफ़िक्स ले जाना और बाकी सब स्थानीय लिंक पर छोड़ देना। Azure के स्वामित्व वाला एग्रेस पता पाना रूटिंग डिज़ाइन का बदलाव है, मरम्मत नहीं।
गेटवे डिफ़ॉल्ट रूप से क्या घोषित करता है
गेटवे वर्चुअल नेटवर्क के पता स्थान के लिए रूट पुश करता है, साथ ही उन पीयर नेटवर्क के लिए जहाँ गेटवे ट्रांज़िट की अनुमति है और साइट-टू-साइट कनेक्शन या BGP से सीखे गए स्थानीय प्रीफ़िक्स के लिए। उस सेट में कोई 0.0.0.0/0 नहीं है। आपका ऑपरेटिंग सिस्टम अपना डिफ़ॉल्ट रूट Wi-Fi या Ethernet पर रखता है, इसलिए किसी सार्वजनिक API की ओर जाने वाला पैकेट टनल में कभी प्रवेश ही नहीं करता।
टनल के अंदर क्लाइंट को जो पता मिलता है वह पॉइंट-टू-साइट पूल से एक निजी लीज़ है। यह VNet के संसाधनों के सामने क्लाइंट की पहचान करता है; यह इंटरनेट को दिखने वाला पता नहीं है, और किसी SaaS API के लिए बाहर जाने वाले अनुरोध के स्रोत के रूप में यह कभी नहीं दिखेगा। उस लीज़ के इर्द-गिर्द बनी allowlist प्रविष्टि काम नहीं कर सकती, चाहे आप कितनी भी देर प्रतीक्षा करें कि वह विक्रेता के लॉग में दिखे।
स्प्लिट टनल और फ़ोर्स्ड टनलिंग साथ-साथ
| Split tunnel, the default | Forced tunneling | |
|---|---|---|
| Internet traffic exits through | local ISP or office router | firewall or appliance inside Azure |
| Source address the API sees | your home or office IP | the firewall public IP |
| Inspection and logging in Azure | none | policy rules plus flow logs |
| Ongoing cost | gateway only | gateway, firewall hours, data processing |
| What usually breaks | nothing on the egress path | DNS, on-premises routes, overlapping local ranges |
केवल दूसरी पंक्ति वह पता बदलती है जो कोई दूरस्थ सेवा देखती है। उस तालिका में बाकी सब लागत और परिचालन सतह है जिसे आप तब स्वीकार करते हैं जब एग्रेस को Azure के अंदर जाँचना या अनुवाद करना होता है। अगर कोई आपसे सार्वजनिक IP बदलवाने को कहे, तो वह पूरा दायाँ कॉलम माँग रहा है, क्लाइंट में कोई छोटा सुधार नहीं।
कुछ भी दोबारा बनाने से पहले एक बीच का विकल्प नाम लेने योग्य है। VNet के अंदर एक प्रॉक्सी या गेटवे VM आपको उन अनुप्रयोगों के लिए नियंत्रित स्रोत पता देता है जिन्हें उसकी ओर इंगित किया जा सकता है, बिना क्लाइंट का डिफ़ॉल्ट रूट हटाए। यह सामान्य ब्राउज़िंग को स्थानीय रखता है और फिर भी ऐसे साझेदार को संतुष्ट करता है जिसे केवल एक API कॉल Azure से आने की ज़रूरत है। यह तब विफल होता है जब आवश्यकता वास्तव में सारे ट्रैफ़िक की हो, क्योंकि प्रॉक्सी सेटिंग को अनदेखा करने वाला हर कुछ फिर भी स्थानीय रूप से बाहर जाता है।
टनल को डिफ़ॉल्ट रूट ले जाने दें
वर्चुअल नेटवर्क गेटवे पर, क्लाइंट के सारे इंटरनेट ट्रैफ़िक को टनल में ले जाने का समर्थित तरीका पॉइंट-टू-साइट कॉन्फ़िगरेशन में कस्टम रूट जोड़ना है। दो आधे पूरे IPv4 स्थान को कवर करते हैं, और हर एक स्थानीय डिफ़ॉल्ट रूट से अधिक विशिष्ट है, इसलिए क्लाइंट बिना कुछ हटाए उन्हें प्राथमिकता देता है:
Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1वह पंक्ति उदाहरण है, कॉपी-पेस्ट के लिए पूरी नहीं: पहले Get-AzVirtualNetworkGateway से गेटवे ऑब्जेक्ट लें और उसे GWOBJ की जगह रखें, और चलाने से पहले पुष्टि करें कि SKU और परिनियोजन मॉडल कस्टम रूट स्वीकार करते हैं। वही प्रीफ़िक्स पोर्टल में पॉइंट-टू-साइट कॉन्फ़िगरेशन पृष्ठ पर दिखते हैं, और अगर आप पहले से गेटवे को स्क्रिप्ट नहीं कर रहे तो उन्हें सेट करने की अधिक सुरक्षित जगह वही है।
उन प्रीफ़िक्स को बदलने से क्लाइंट पैकेज अमान्य हो जाता है। VPN क्लाइंट पैकेज फिर से डाउनलोड करें और दोबारा इंस्टॉल करें, क्योंकि रूट प्रोफ़ाइल के अंदर यात्रा करते हैं। पुरानी प्रोफ़ाइल के साथ फिर से जुड़ने वाला क्लाइंट पुराना रूट सेट रखता है, और आप ऐसे बदलाव को डीबग करने में एक घंटा गँवा सकते हैं जो उस तक कभी पहुँचा ही नहीं।
सुरक्षित वर्चुअल WAN हब में समकक्ष है पॉइंट-टू-साइट गेटवे से जुड़ी हब रूट तालिका में डिफ़ॉल्ट रूट, जिसमें हब का Azure Firewall ट्रैफ़िक लेता है। फ़ायरवॉल इंटरनेट की ओर जाने वाले कनेक्शनों का अनुवाद अपने सार्वजनिक IP पतों में करता है, और नया एग्रेस पता उसी अनुवाद से आता है। जब फ़ायरवॉल के पास कई सार्वजनिक IP हों, उनमें से कोई भी स्रोत के रूप में दिख सकता है, इसलिए allowlist में सभी होने चाहिए।
ऊपर के दोनों डिज़ाइन IPv4 हैं। दोनों /1 प्रीफ़िक्स IPv6 के लिए कुछ नहीं करते, और पॉइंट-टू-साइट का IPv6 समर्थन इतना सीमित है कि समानता का वादा करने से पहले संयोजन का परीक्षण करना चाहिए।
पहले रूट जाँचें, फिर एग्ज़िट
पैकेज दोबारा इंस्टॉल करने और फिर से जुड़ने के बाद पुष्टि करें कि क्लाइंट ने वाकई दोनों आधे इंस्टॉल किए। Windows पर Get-NetRoute -DestinationPrefix 0.0.0.0/1 और 128.0.0.0/1 के लिए वही क्वेरी टनल इंटरफ़ेस का नाम बतानी चाहिए, और route print आपके मूल डिफ़ॉल्ट के साथ दोनों दिखाता है। Linux पर ip route show को दोनों प्रीफ़िक्स सूचीबद्ध करने चाहिए; अगर नहीं करता, तो प्रोफ़ाइल ने उन्हें कभी नहीं ले जाया।
फिर क्लाइंट से सार्वजनिक पता दोबारा जाँचें और उसी कनेक्शन के लिए फ़ायरवॉल लॉग पढ़ें। स्रोत अनुवादित पोर्ट के साथ फ़ायरवॉल का सार्वजनिक IP होना चाहिए। दोनों रूट होने पर भी स्थानीय रूप से बाहर जाने वाला क्लाइंट मतलब पैकेट Azure तक पहुँचे और किसी दूसरे रास्ते से निकले: गेटवे सबनेट पर उपयोगकर्ता-परिभाषित रूट, ऐसा फ़ायरवॉल जो खुद स्थानीय नेटवर्क की ओर फ़ोर्स्ड-टनल हो, या ऐसी नीति जो अनुवाद से पहले फ़्लो गिरा देती है।
उसी सत्र में एक निजी गंतव्य फिर से परखें। बदलाव के बाद जवाब देना बंद कर देने वाला जंप होस्ट आम संकेत है कि नए प्रीफ़िक्स ने कुछ हटा दिया है, या तो पहले घोषित कोई अधिक संकीर्ण स्थानीय रूट, या नाम विश्लेषण जो अब आपके निजी ज़ोन के लिए फ़ॉरवर्डर रहित रिज़ॉल्वर की ओर जाता है।
कब स्प्लिट टनल को अकेला छोड़ें
अगर लक्ष्य केवल किसी निजी API, निजी एंडपॉइंट या आंतरिक एडमिन पृष्ठ तक पहुँचना है, तो डिफ़ॉल्ट व्यवहार सस्ता और शांत है। फ़ोर्स्ड टनलिंग फ़ायरवॉल के घंटे और डेटा-प्रोसेसिंग शुल्क, लंबा रास्ता, और एक और जगह जोड़ती है जहाँ हर क्लाइंट फ़्लो विफल हो सकता है। यह उस एक गंतव्य से कहीं अधिक ट्रैफ़िक भी पकड़ती है जिसकी आपको चिंता थी।
इसका सहारा तब लें जब आवश्यकता एग्रेस के रूप में कही गई हो: साझेदार को एक निश्चित Azure पता दिखना चाहिए, सुरक्षा चाहती है कि कनेक्शन लॉग हों और जाँचे जाएँ, या डेटा को एक नियंत्रित बिंदु से बाहर जाना है। तब भी डिज़ाइन हर उपयोगकर्ता को साझा एग्ज़िट देता है, इसलिए प्रति-उपयोगकर्ता जवाबदेही स्रोत पते से नहीं, बल्कि एप्लिकेशन में पहचान से आनी चाहिए।
बदलाव बंद करने से पहले चार बातें पुष्टि करें: इंस्टॉल किया गया क्लाइंट पैकेज नया है, दोनों /1 रूट टनल इंटरफ़ेस पर हैं, एक निजी गंतव्य अब भी जवाब देता है, और दूरस्थ सेवा का लॉग फ़ायरवॉल पता दिखाता है।