नेस्टेड VPN: बाहरी कनेक्शन कौन-सी सुरंग ले जाती है?

एक साथ चल रहे दो VPN क्लाइंट नेस्टेड सुरंग नहीं बनाते; वे दो सुरंगें और रूटिंग पर झगड़ा बनाते हैं। नेस्टेड सुरंग तब होती है जब भीतरी क्लाइंट का अपने सर्वर से कनेक्शन स्वयं बाहरी सुरंग द्वारा ले जाया जाता है, और यह वह व्यवस्था है जो जान-बूझकर बनाई जाती है। सही होने पर भीतरी सर्वर बाहरी सर्वर का पता देखता है; गलत होने पर एक क्लाइंट चुपचाप दूसरे के चारों ओर फिर से जुड़ता है। तीन शर्तें तय करती हैं कि नेस्टिंग असली है या संयोगवश।

नेस्टिंग को तीन शर्तें तय करती हैं

पहली यह है कि किस अंतिम छोर को कौन-सा मार्ग चाहिए। भीतरी सर्वर का पता बताएं, बाहरी सर्वर का पता बताएं, और स्पष्ट रूप से कहें कि भीतरी सर्वर केवल बाहरी सुरंग से पहुंच योग्य है। बाकी सब उसी वाक्य से निकलता है, जिसमें यह भी शामिल है कि कौन-से रूट किस तालिका में हैं।

दूसरी यह है कि क्या आप हर परत पर मार्ग देख सकते हैं। यदि आप कर्नेल से नहीं पूछ सकते कि कोई विशेष गंतव्य कौन-सा रूट इस्तेमाल करेगा, तो आप श्रृंखला का अनुमान अंतिम आउटगोइंग IP से लगा रहे हैं, और यही वह साक्ष्य है जो नेस्टिंग को संयोग से अलग नहीं कर सकता।

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

पहली शर्त: किस अंतिम छोर को कौन-सा मार्ग चाहिए

ip route get 203.0.113.10 उस प्रश्न का सीधा उत्तर देता है: यह मार्ग, स्रोत पता और वह इंटरफ़ेस छापता है जो कर्नेल अभी उस गंतव्य के लिए उपयोग करेगा।

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

दूसरी शर्त: हर परत पर मार्ग जांचें

आधुनिक क्लाइंट पर रूट चयन मुख्य तालिका से अधिक है। नीति नियम चिह्नित पैकेट को दूसरी तालिका में भेज सकते हैं, क्लाइंट अपने सॉकेट को किसी इंटरफ़ेस से बांध सकता है, और कंटेनर या नामस्थान की अपनी तालिकाएं होती हैं। ip rule और ip route show table all यह पता लगाने का तरीका हैं कि इनमें से कौन-सी व्यवस्था चल रही है।

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

तीसरी शर्त: बाहरी सुरंग गिरने पर क्या होता है

विफलता का व्यवहार निर्णय मांगता है, डिफ़ॉल्ट मान नहीं। लिखें कि बाहरी सुरंग गायब होने पर भीतरी सुरंग के साथ क्या होना चाहिए, फिर क्लाइंट से वैसा ही करवाएं।

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

तीनों को हानिरहित ट्रैफ़िक और बाहरी सुरंग की जानबूझकर खराबी के साथ परखें, क्योंकि कॉन्फ़िगरेशन पढ़ना आपको नहीं बताएगा कि आपके पास कौन-सी है। बाहरी सुरंग को मार डालें, देखें भीतरी क्लाइंट क्या करता है, और गिरे रहने के दौरान मार्ग फिर जांचें। फिर बाहरी सुरंग वापस लाएं और पुष्टि करें कि श्रृंखला फिर बनती है, भीतरी क्लाइंट को इस बीच चुने गए सीधे मार्ग पर नहीं छोड़ती।

श्रृंखला आपको क्या नहीं देती

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

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