गेस्ट VPN और होस्ट VPN: कौन-सा रूट वास्तव में जीतता है

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

पहले गेस्ट का कनेक्शन दर्ज करें

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

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

गेस्ट के एंडपॉइंट को बाहर की ओर ट्रेस करें

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

किसी भी संदर्भ में चौड़ा रूट वह ट्रैफ़िक पकड़ लेता है जिसकी दूसरे क्लाइंट ने अपेक्षा की थी। गेस्ट के अंदर 0.0.0.0/0 रूट और पूरी टनल वाला होस्ट क्लाइंट दोनों सब पर दावा करते हैं, और जो अंत में लागू होता है वही जीतता है। गेस्ट के वर्चुअल नेटवर्क, स्थानीय LAN और दूरस्थ नेटवर्क के बीच ओवरलैप निजी प्रीफ़िक्स के लिए वही असर डालते हैं, ऐसी विफलताओं के साथ जो प्रमाणीकरण की समस्याओं जैसी लगती हैं; पता अनुवाद का व्यवहार वही है जो कंटेनर नेटवर्किंग के लिए बताया गया है।

पहले और बाद का रिकॉर्ड तुलना करें

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

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

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

रीस्टार्ट के दौरान मालिकाना साफ़ रखें

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

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