एउटै Azure VPN VM मा दुई सार्वजनिक IP हुँदा विरलै पूरा हुने अपेक्षा बन्छ: क्लाइन्टले जडान गर्ने ठेगाना नै वेबसाइटहरूले देख्ने ठेगाना हुनेछ। यो नतिजा तीन स्वतन्त्र निर्णयबाट आउँछ, र तीमध्ये पहिलो मात्र टनेल श्रोतासँग सम्बन्धित छ। दोस्रो अगाडि पठाइएको क्लाइन्ट ट्राफिकका लागि प्रयोग हुने गेस्ट स्रोत हो, र तेस्रो त्यो स्रोतमा लागू हुने Azure को निर्गम विधि हो। एउटा बदल्नुभयो भने अरू दुई जहाँ थिए त्यहीँ रहन्छन्, त्यसैले हरेकलाई स्पष्ट रूपमा तय गर्नुहोस्।

निर्णय 1: टनेल कहाँ अन्त्य हुन्छ

Azure को सार्वजनिक IP NIC मा भएको निजी IP कन्फिगरेसनसँग सम्बद्ध हुन्छ; यो गेस्ट अपरेटिङ सिस्टमभित्र थप्ने ठेगाना होइन। अनुमान गर्नुको सट्टा म्यापिङ पढ्नुहोस्: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. त्यो क्वेरीले जुन निजी ठेगाना फर्काए पनि, गेस्टले वास्तवमा त्यही राख्नुपर्छ।

एउटा NIC ले धेरै IP कन्फिगरेसन बोक्न सक्छ, त्यसैले दुई सार्वजनिक ठेगानाका लागि दुई NIC चाहिँदैन। यदि डिजाइनले साँच्चै दुई NIC प्रयोग गर्छ भने, हरेकले आफ्नै गेस्ट रुट र अर्को हप ल्याउँछ, र तपाईंले सरल बनाउनुको सट्टा एउटा राउटिङ निर्णय थप्नुभएको छ।

स्पष्ट स्थानीय बाइन्ड भएको सेवाका लागि गेस्टको वास्तविक निजी ठेगानामा बाइन्ड गर्नुहोस्, कहिल्यै सार्वजनिक प्लेसहोल्डरमा होइन। सबै ठेगाना स्वीकार गर्ने श्रोताले आफूसम्म पुग्ने हरेक IP कन्फिगरेसनबाट ट्राफिक लिन्छ, त्यसैले बाइन्ड क्रमले तय गर्छ भनी आशा गर्नुको सट्टा नेटवर्क सुरक्षा समूह र होस्ट फायरवालले प्रवेश सीमित गर्नुहोस्।

निर्णय 2: अगाडि पठाइएको क्लाइन्टले कुन स्रोत प्रयोग गर्छ

गेटवेले क्लाइन्ट अनुरोध डिक्रिप्ट गरेपछि, उसले अगाडि पठाउने प्याकेट VPN श्रोतासम्म पुगेको प्याकेटभन्दा फरक हुन्छ। गेस्टलाई फर्वार्डिङ सक्षम, प्रवाहलाई अनुमति दिने फायरवाल नीति र क्लाउड डिजाइनले अनुमति दिने स्रोत ठेगाना चाहिन्छ। यदि तपाईंले क्लाइन्टको आन्तरिक ठेगाना अनुवाद गर्नुभयो भने, Azure ले त्यही अनुवादित स्रोतको मूल्याङ्कन गर्छ, क्लाइन्टको आन्तरिक ठेगानाको होइन।

साँघुरो SNAT नियमले गेस्ट-निजी स्रोत छान्न सक्छ, तर पछिको Azure अनुवादलाई जित्न सक्दैन। VM भित्र हरेक क्लाइन्टको जवाफदेही चाहिए SNAT छान्नुहोस्; सबनेटको निर्गम डिजाइनले पहिले नै स्थिर सार्वजनिक स्रोत दिन्छ भने र दोस्रो अनुवादले अवस्था मात्र थप्ने हो भने यसलाई छोड्नुहोस्।

निर्णय 3: कुन Azure निर्गम विधि जित्छ

Microsoftनिर्गम प्राथमिकता क्रमदस्तावेज गर्छ: उपकरण वा गेटवेतर्फको लागू मार्गलाई प्राथमिकता हुन्छ, र सम्बन्धित मार्गमा सबनेट NAT Gateway जडानलाई इन्स्टेन्स-स्तरीय सार्वजनिक IP भन्दा प्राथमिकता हुन्छ। यही क्रमका कारण 10.20.0.5 मा अनुवाद गर्दा वेबसाइटले 198.51.100.20 देख्छ भन्ने प्रमाण हुँदैन। निर्गम डिजाइन स्वीकार गर्नुअघि प्रभावकारी रुट तालिका, NAT Gateway सम्बन्ध र NIC को सार्वजनिक IP सँगै पढ्नुहोस्।

राख्नुहोस्Azure NIC फर्वार्डिङ सेटिङलाई Linux फर्वार्डिङबाट अलग। क्लाउड झन्डाले स्रोत वा गन्तव्य NIC मा तोकिएको नभएका प्याकेटलाई अनुमति दिन्छ; यसले net.ipv4.ip_forward सक्षम गर्दैन, र गेस्ट सेटिङले क्लाउडको अनुमति दिँदैन।

टनेल सकेटको आफ्नै स्रोत निर्णय हुन्छ

wg-quick अन्तर्गत WireGuard को Address ले WireGuard इन्टरफेसमा ठेगाना तोक्छ; यो बाह्य UDP बाइन्डिङ निर्देश होइन। इन्क्रिप्टेड सकेटको स्रोत रुटिङ तालिका पछ्याउँछ, त्यसैले नीति मार्ग वा दोस्रो पूर्वनिर्धारित इन्टरफेसले ठेगानालाई नछोई यसलाई सार्न सक्छ।OpenVPNको local विकल्प र UDP multihome उही तरिकाले व्यवहार गर्छन्: ती श्रोता र उसका जवाफसँग सम्बन्धित छन्, हरेक अगाडि पठाइएको क्लाइन्टको इन्टरनेट स्रोतसँग होइन।

टनेल बोक्ने अन्डरले मार्ग जोगाउनुहोस् र क्लाइन्टले अझै अपेक्षित प्रवेश व्यवस्थाबाट प्रमाणित जवाफ पाइरहेको पुष्टि गर्नुहोस्। ठेगाना सूचीको क्रममा स्थायी स्रोत-चयन नीतिका रूपमा भर नपर्नुहोस्, किनकि NIC मा थपिने अर्को ठेगानाले कुन जित्छ भन्ने बदल्न सक्छ।

के स्वीकार गर्ने, र कुन क्रममा

तीन नतिजा अलग-अलग स्वीकार गर्नुहोस्। पहिलो, बाह्य क्लाइन्टले इच्छित VPN प्रवेशमा पुग्छ। दोस्रो, त्यो VPN क्लाइन्टको नयाँ अनुमत अनुरोध दस्तावेजी इन्टरनेट निर्गमबाट बाहिर जान्छ। तेस्रो, अनिच्छित श्रोता र फर्वार्डिङ मार्ग अस्वीकृत रहन्छन्। सार्वजनिक-देखि-निजी म्यापिङ र हरेक निर्णयका गेस्ट तथा क्लाउड जिम्मेवार एकै ठाउँमा लेख्नुहोस्।

सफल टनेलले पहिलो भाग मात्र प्रमाणित गर्छ। नयाँ प्रवाहसँग निर्गम परीक्षण गर्नुहोस्, किनकि क्यास गरिएको जडानले मार्ग बदलिएपछि पनि लामो समय पुरानो स्रोत प्रयोग गर्न सक्छ।

सम्बन्धित लेखहरू