VPN के समर्पित पते पर वास्तव में कौन उत्तर देता है?

संगठन के आवंटन में बिना उपयोग पड़ा कोई पता श्रोता नहीं है, और उसे फ़ायरवॉल में जोड़ने से कोई श्रोता बनता नहीं है। उस पते पर किसी को IKE समाप्त करना होगा, और तंत्र इस पर निर्भर करता है कि गेटवे स्वयं उस पते का स्वामी है या अपस्ट्रीम उपकरण उसका अनुवाद करता है। पैकेट का पथ ही दोनों को अलग करता है, और यही तय करता है कि कोई परिवर्तन अनुरोध खोलने से पहले आपको कौन-सी प्लेटफ़ॉर्म सुविधा चाहिए। पहले पथ का मॉडल बनाएँ, फिर चुनें।

पते के पीछे का पैकेट पथ

सहकर्मी उस पते पर IKE भेजता है जो उसे दिया गया था, UDP 500 पर या UDP 4500 पर जब NAT ट्रैवर्सल चल रहा हो। पथ में उस पते का स्वामी जो भी उपकरण है, वह या तो डेटाग्राम को स्थानीय रूप से प्राप्त करके उत्तर देता है, या उसे कहीं और अग्रेषित करता है। ये केवल दो संभावनाएँ हैं, और इस लेख में बाकी सब कुछ इससे निकलता है कि इनमें से कौन सत्य है।

स्थानीय रूप से प्राप्त करने का अर्थ है कि उस उपकरण पर उस पते से बँधा एक सॉकेट मौजूद है। अग्रेषित करने का अर्थ है कि डेटाग्राम को फिर से लिखकर किसी अन्य अंतिम बिंदु की ओर भेजा जाता है, जिसके पास तब सॉकेट होता है। UDP 500 की अनुमति देने वाला फ़ायरवॉल नियम आपको यह नहीं बताता कि इन दोनों में से क्या हो रहा है।

कुछ भी छूने से पहले रिकॉर्ड लिखें: वह पता जिससे सहकर्मी संपर्क करते हैं, अपस्ट्रीम नेटवर्क उसे कैसे पहुँचाता है, वह स्थानीय इंटरफ़ेस या तार्किक अंतिम बिंदु जो उसे प्राप्त करता है, और वह प्रक्रिया जो IKE का उत्तर देती है। चार पंक्तियाँ, और हर एक को जाँचा जा सकता है। जब इनमें से कोई अज्ञात हो, तो वह अज्ञात ही डिज़ाइन का काम है, बाद में तय की जाने वाली कार्यान्वयन बारीकी नहीं। परिवर्तन अनुरोध स्वीकृत होने के बाद उन्हें भरना ही वह तरीका है जिससे अनुवाद नियम गलत उपकरण में जुड़ जाता है।

मॉडल A: गेटवे पते का स्वामी है

पहले मॉडल में गेटवे स्वयं पता रखता है, या तो किसी मौजूदा इंटरफ़ेस पर द्वितीयक पते के रूप में, या समर्पित इंटरफ़ेस पर पते के रूप में, या ऐसे loopback के रूप में जिसे प्लेटफ़ॉर्म टनल अंतिम बिंदु के रूप में समर्थित करता है। ये तीन अलग-अलग सुविधाएँ हैं जिनके तीन अलग-अलग कॉन्फ़िगरेशन पथ हैं, और जो प्लेटफ़ॉर्म एक को समर्थित करता है वह बाकी को नहीं भी कर सकता है।

उसके इर्द-गिर्द डिज़ाइन करने से पहले पुष्टि करें कि प्लेटफ़ॉर्म और संस्करण ठीक इसी व्यवस्था को समर्थित करते हैं। रूट किया गया ब्लॉक, इंटरफ़ेस पर अतिरिक्त पता और loopback अंतिम बिंदु आपस में बदले नहीं जा सकते, और एक संस्करण का दस्तावेज़ अगले के समान व्यवहार का वादा नहीं करता।

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

सुनता हुआ सॉकेट ही प्रमाण है। यदि पते से कुछ भी नहीं बँधा है, तो रूटिंग तालिका जो भी कहे, गेटवे समापक नहीं है, और पैकेट कैप्चर दिखाएगा कि डेटाग्राम आ रहे हैं पर उन्हें उत्तर देने वाला कोई नहीं है।

किसी इंटरफ़ेस को ऐसे सबनेट में न रखें जो टोपोलॉजी में पहले से कहीं और मौजूद है, और यह न मानें कि प्लेटफ़ॉर्म इसे संभाल लेगा। अतिव्यापी इंटरफ़ेस सबनेट अस्पष्ट स्रोत चयन पैदा करते हैं और कई प्लेटफ़ॉर्म पर कॉन्फ़िगर करने से पूरी तरह इनकार कर देते हैं।

मॉडल B: अपस्ट्रीम उपकरण इसका अनुवाद करता है

दूसरे मॉडल में अपस्ट्रीम फ़ायरवॉल समर्पित पता रखता है और ट्रैफ़िक को किसी अन्य VPN गेटवे की ओर अग्रेषित करता है। यह वापसी पथ के साथ गंतव्य अनुवाद है, और जब तक इसे इसी रूप में प्रलेखित रखा जाए, यह पूरी तरह वैध डिज़ाइन है।

यह जो नहीं है, वह यह प्रमाण है कि अपस्ट्रीम उपकरण ने स्थानीय VPN सॉकेट प्राप्त कर लिया है। अनुवाद पैकेट अग्रेषित करता है; यह ऊपरी बॉक्स को IKE उत्तरदाता नहीं बनाता। यदि अपस्ट्रीम नियम हटा दिया जाए या उसका वापसी पथ टूट जाए, तो VPN रुक जाता है, चाहे गेटवे स्वस्थ हो और उसके अपने श्रोता अक्षुण्ण हों।

दोनों पते दर्ज करें: वह जिससे सहकर्मी संपर्क करते हैं और वह जो गेटवे वास्तव में देखता है। फिर परिवहन और वापसी पथ दर्ज करें, क्योंकि UDP 500 के लिए काम करने वाला परंतु एनकैप्सुलेटेड ESP के लिए नहीं काम करने वाला अनुवाद जुड़ेगा और फिर ट्रैफ़िक ले जाने में विफल होगा, जो बाद में डिबग करने के लिए भ्रमित करने वाली विफलता है।

पहचान बाहरी पता नहीं है

IPsec टनल के अंतिम बिंदु को उस ट्रैफ़िक से अलग करता है जिसकी वह रक्षा करता है, और वास्तुकला इन निर्णयों को अलग-अलग जगहों पर रखती है। सहकर्मी जिस पते से संपर्क करते हैं उसे बदलने से यह स्वतः नहीं बदलता कि कौन-से आंतरिक प्रीफ़िक्स की अनुमति है, कौन-से रूट स्थापित होते हैं, या सत्र किन संसाधनों तक पहुँच सकता है।

प्रमाणित पहचान फिर अलग है। IKEv2 पहचान पेलोड और प्रमाणीकरण विनिमय ले जाता है जिनका बाहरी पैकेट पते से मेल होना आवश्यक नहीं, और ठीक इसी कारण अनूदित डिज़ाइन अब भी सही ढंग से प्रमाणीकरण कर सकता है।

यह स्वतंत्रता उपयोगी है और साथ ही जाल भी। एक सामान्य श्रोता की ओर हल होने वाले दो DNS नाम अलग VPN बैकएंड नहीं चुनते, और एक पहचान का नाम लेने वाला प्रमाणपत्र दूसरी पहचान की अपेक्षा रखने वाले सहकर्मी को संतुष्ट नहीं करेगा। यह मानने से पहले कि केवल पता ही यह तय करता है, पुष्टि करें कि सहकर्मी क्या सत्यापित करता है।

एक कनेक्शन देखकर डिज़ाइन स्वीकार करें

जाँचें कि नया अधिकृत कनेक्शन वास्तव में कहाँ पहुँचाया जाता है, कौन-सी पहचान उत्तर देती है, और उसके बाद कौन-सा निजी प्रवाह अनुमत होता है। तीन अवलोकन, तीन अलग परतें, और पते की सफल सार्वजनिक लुकअप इनमें से किसी को भी नहीं जाँचती।

नकारात्मक स्थिति भी रखें: वह सहकर्मी जिसे स्वीकार नहीं किया जाना चाहिए, या वह आंतरिक प्रीफ़िक्स जिस तक पहुँच नहीं होनी चाहिए, परिवर्तन के बाद सत्यापित किया गया। शुरू में लिखा रिकॉर्ड ही स्मृति से डिज़ाइन दोबारा बनाए बिना वह परीक्षण संभव बनाता है।

इस सब का उद्देश्य नेटवर्क स्वामी को समर्थित आवंटन विधि चुनने देना है, बजाय इस सामान्य दावे पर निर्भर रहने के कि हर फ़ायरवॉल अतिरिक्त पते के साथ क्या कर सकता है। वही दावा ठीक वह जगह है जहाँ ये डिज़ाइन गलत पड़ते हैं, क्योंकि वह हर प्लेटफ़ॉर्म पर विश्वसनीय लगता है और सामान्य रूप से किसी पर भी सत्य नहीं है। चार पंक्तियों का रिकॉर्ड आपके प्लेटफ़ॉर्म के लिए दस मिनट में यह तय कर देता है।