एका Azure VPN VM वर दोन सार्वजनिक IP: कोण काय करते

एका 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 क्लायंटची नवीन परवानगी दिलेली विनंती दस्तऐवजीत इंटरनेट निर्गमातून बाहेर पडते. तिसरे, अनिच्छित श्रोता आणि फॉरवर्डिंग मार्ग नाकारलेलेच राहतात. सार्वजनिक-ते-खाजगी मॅपिंग आणि प्रत्येक निर्णयाचे गेस्ट व क्लाउड जबाबदार एकाच ठिकाणी नोंदवा.

यशस्वी टनेल फक्त पहिला भाग सिद्ध करते. नव्या प्रवाहाने निर्गम तपासा, कारण कॅशे केलेले कनेक्शन मार्ग बदलल्यानंतरही बराच काळ जुना स्रोत वापरू शकते.