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 रुट टनेल इन्टरफेसमा छन्, एउटा निजी गन्तव्य अझै जवाफ दिन्छ, र टाढाको सेवाको लगले फायरवाल ठेगाना देखाउँछ।