एक 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 अनुवाद को नहीं हरा सकता। SNAT चुनें जब आपको VM के अंदर प्रति-क्लाइंट जवाबदेही चाहिए; उसे छोड़ दें जब सबनेट का आउटबाउंड डिज़ाइन पहले से स्थिर सार्वजनिक स्रोत देता है और दूसरा अनुवाद केवल स्थिति जोड़ेगा।

निर्णय 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 क्लाइंट का नया अनुमत अनुरोध दस्तावेज़ित इंटरनेट निर्गम से बाहर जाता है। तीसरा, अनिच्छित श्रोता और अग्रेषण पथ अस्वीकृत रहते हैं। सार्वजनिक-से-निजी मैपिंग और हर निर्णय के गेस्ट व क्लाउड स्वामी एक ही जगह दर्ज करें।

सफल टनल केवल पहला हिस्सा सिद्ध करता है। नए प्रवाह से निर्गम का परीक्षण करें, क्योंकि कैश किया गया कनेक्शन मार्ग बदलने के बहुत बाद भी पुराना स्रोत उपयोग कर सकता है।

संबंधित लेख