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 तुम्हाला नियंत्रित स्रोत पत्ता देतो, ज्याकडे वळवता येतील अशा अनुप्रयोगांसाठी, क्लायंटचा डीफॉल्ट रूट न हलवता। यामुळे सामान्य ब्राउझिंग स्थानिक राहते आणि Azure कडून एकच API कॉल येणे पुरेसे असलेल्या भागीदाराचेही समाधान होते। आवश्यकता खरोखर सर्व रहदारीबद्दल असेल तेव्हा तो अपयशी ठरतो, कारण प्रॉक्सी सेटिंगकडे दुर्लक्ष करणारे काहीही तरीही स्थानिकच बाहेर पडते।
टनलला डीफॉल्ट रूट वाहू द्या
व्हर्च्युअल नेटवर्क गेटवेवर, क्लायंटची सर्व इंटरनेट रहदारी टनलमध्ये वळवण्याचा समर्थित मार्ग म्हणजे पॉइंट-टू-साइट कॉन्फिगरेशनमध्ये सानुकूल रूट्स जोडणे। दोन अर्धे भाग संपूर्ण 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 रूट्स टनल इंटरफेसवर आहेत, एक खाजगी गंतव्य अजूनही प्रतिसाद देते, आणि दूरस्थ सेवेचा लॉग फायरवॉलचा पत्ता दाखवतो।