गेस्ट 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 बद्दल बग अहवाल तयार करतो. व्यवस्था रीबूटनंतरही टिकली पाहिजे, कोणालाही ती का चालली होती हे आठवत नसतानाही.