एक ही डेस्कटॉप पर दो VPN क्लाइंट: क्या टकराता है और क्या काम करता है

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

चरण 1: पता करें कि इग्रेस का स्वामी कौन-सा क्लाइंट है

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

ip route get 1.1.1.1
ip route show default
route print

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

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

चरण 2: रिज़ॉल्वर और अतिव्यापी प्रीफ़िक्स जाँचें

DNS दूसरा टकराव है, और यह एक विशिष्ट लक्षण पैदा करता है: नाम विफल होते हैं जबकि पते काम करते हैं। हर क्लाइंट अपना रिज़ॉल्वर थोपता है, और आगे की क्वेरी के लिए अंतिम लिखने वाला जीतता है। क्लाइंट के सेटिंग्स पृष्ठ को पढ़ने के बजाय रिज़ॉल्वर सेवा से पूछें कि वह प्रति लिंक क्या उपयोग करती है।

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

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

यदि प्रीफ़िक्स अतिव्यापी हैं तो यहीं रुकें। इस सूची में आगे सब कुछ मानता है कि वे अतिव्यापी नहीं हैं।

चरण 3: ऐसा पृथक्करण पैटर्न चुनें जो टिके

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

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

नेमस्पेस दूसरे ऑपरेटिंग सिस्टम के बिना वर्चुअल मशीन जैसा ही पृथक्करण देता है, पर इसके किनारे खुरदुरे हैं: सुरंग उपकरण को उसमें ले जाना पड़ता है, और एप्लिकेशन को उसके अंदर शुरू करना पड़ता है। प्रबंधित कार्य क्लाइंट के साथ निजी VPN के लिए अलग भौतिक उपकरण अक्सर सबसे कम आश्चर्यजनक विकल्प होता है। एक सुरंग को दूसरी के अंदर ढेर करना पृथक्करण पैटर्न नहीं है; अंदर का अंतिम बिंदु बाहरी सुरंग से पहुँचने योग्य रहना चाहिए, और यह व्यवस्था ऊपर से MTU और विलंब की समस्याएँ जोड़ती है।

एक पैटर्न चुनें और लिखें कि क्यों। एक एप्लिकेशन के लिए नेमस्पेस और बाकी के लिए स्प्लिट टनल मिलाना मूल टकराव को अधिक कठिन डिबग करने योग्य रूप में फिर से बना देता है।

चरण 4: उसी सत्र से दोनों नेटवर्क सत्यापित करें

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

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

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

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