नेस्टेड VPN: बाह्य कनेक्शन कोणती बोगदा वाहते?
आतील बोगद्याला त्याच्या शेवटच्या टोकापर्यंत बाह्य मार्ग आवश्यक आहे. चुकीच्या क्रमाने सुरू झालेले दोन क्लायंट मार्गाचा संघर्ष निर्माण करतात, म्हणून प्रथम नेस्टिंग दुरुस्त करा.
एकाच वेळी चालणारे दोन VPN क्लायंट नेस्टेड बोगदा तयार करत नाहीत; ते दोन बोगदे आणि राउटिंगवरून भांडण तयार करतात। नेस्टेड बोगदा तेव्हा असतो जेव्हा आतील क्लायंटचे स्वतःच्या सर्व्हरशी असलेले कनेक्शन स्वतः बाह्य बोगद्याद्वारे वाहून नेले जाते, आणि ही अशी रचना आहे जी जाणीवपूर्वक बांधली जाते। बरोबर झाल्यास आतील सर्व्हर बाह्य सर्व्हरचा पत्ता पाहतो; चूक झाल्यास एक क्लायंट शांतपणे दुसऱ्याभोवती पुन्हा जोडला जातो। नेस्टिंग खरे आहे की योगायोगाने, हे तीन अटी ठरवतात।
नेस्टिंग तीन अटी ठरवतात
पहिली अट म्हणजे कोणत्या टोकाला कोणता मार्ग आवश्यक आहे। आतील सर्व्हरचा पत्ता सांगा, बाह्य सर्व्हरचा पत्ता सांगा आणि आतील सर्व्हर फक्त बाह्य बोगद्यातूनच उपलब्ध आहे हे स्पष्टपणे सांगा। बाकी सर्व त्या वाक्यातून निघते, कोणते मार्ग कोणत्या तक्त्यात आहेत हे देखील।
दुसरी अट म्हणजे प्रत्येक स्तरावर तुम्ही मार्ग पाहू शकता का। एखादे विशिष्ट गंतव्य कोणता मार्ग वापरेल हे तुम्ही कर्नेलला विचारू शकत नसाल, तर तुम्ही अंतिम बाहेर जाणाऱ्या IP वरून साखळीचा अंदाज लावत आहात, आणि हाच तो पुरावा आहे जो नेस्टिंगला योगायोगापासून वेगळे करू शकत नाही।
तिसरी अट म्हणजे बाह्य बोगदा पडल्यावर काय होते। आतील बोगदा त्याच्यासोबत थांबू शकतो, सामान्य नेटवर्कवरून पुन्हा जोडू शकतो, किंवा बाह्य मार्ग परत येईपर्यंत अडवलेला राहू शकतो, आणि तिन्हीही समर्थनीय धोरणे आहेत। ती एकच धोरण नाहीत, आणि बहुतेक क्लायंटचे डीफॉल्ट वर्तन दुसरे आहे। जो क्लायंट आपले टोक भौतिक नेटवर्कवरून पुन्हा जोडतो आणि त्याच वेळी निरोगी कनेक्शन दाखवतो, तो हेतूने बांधलेली साखळी शांतपणे दोन असंबंधित बोगद्यांत बदलण्याचा सर्वात सामान्य मार्ग आहे।
पहिली अट: कोणत्या टोकाला कोणता मार्ग आवश्यक आहे
ip route get 203.0.113.10 त्या प्रश्नाचे सरळ उत्तर देते: ते मार्ग, स्रोत पत्ता आणि कर्नेल आता त्या गंतव्यासाठी वापरेल तो इंटरफेस छापते।
आतील क्लायंट सुरू होण्यापूर्वी आतील सर्व्हरसाठी आणि नंतर पुन्हा एकदा ते चालवा, आणि तुलना करा। उत्तर भौतिक इंटरफेसवरून बाह्य बोगद्याच्या इंटरफेसवर बदलल्यास त्या क्षणी नेस्टिंग खरे आहे। ते बदलत नसल्यास आतील क्लायंट थेट जोडत आहे, पॅनेल काहीही म्हणो। बाह्य सर्व्हरच्या पत्त्यासाठी ते पुन्हा करा, जो अजूनही भौतिक इंटरफेसवरून सोडवला पाहिजे, कारण दोन्ही टोके पुनरावृत्तीने पकडणारा मार्ग हाच तो दोष आहे जो यंत्राला नेटवर्कवरून पूर्णपणे काढतो।
दुसरी अट: प्रत्येक स्तरावर मार्ग तपासा
आधुनिक क्लायंटवर मार्गनिवड मुख्य तक्त्यापेक्षा जास्त आहे। धोरण नियम चिन्हांकित पॅकेट दुसऱ्या तक्त्यात पाठवू शकतात, क्लायंट आपले सॉकेट एखाद्या इंटरफेसला बांधू शकतो, आणि कंटेनर किंवा नामस्थानाचे स्वतःचे तक्ते असतात। ip rule आणि ip route show table all हे यापैकी कोणती यंत्रणा सुरू आहे हे शोधण्याचा मार्ग आहे।
जो क्लायंट आपल्या सॉकेटवर SO_MARK लावतो, किंवा एखाद्या विशिष्ट उपकरणाला बांधण्यासाठी संरचित आहे, तो तुम्ही व्यवस्थित केले असे वाटलेला डीफॉल्ट मार्ग टाळतो। हे वैशिष्ट्य आहे, दोष नाही, आणि याचा अर्थ एकमेव विश्वासार्ह तपासणी तीच आहे जी क्लायंटच्या त्याच नामस्थानात चालते। क्लायंट कंटेनरमध्ये चालत असतील तर तपासण्या त्या कंटेनरमध्ये करा, होस्टवर नाही।
तिसरी अट: बाह्य बोगदा पडल्यावर काय होते
अपयशाच्या वेळचे वर्तन निर्णय मागते, डीफॉल्ट मूल्य नाही। बाह्य बोगदा नाहीसा झाल्यावर आतील बोगद्याचे काय व्हायला हवे ते लिहा, मग क्लायंटना तसे करायला लावा।
पर्याय ठोस आहेत। बाह्य मार्ग नाहीसा झाल्यावर आतील क्लायंट थांबवणे स्वच्छ साखळी आणि स्पष्ट खंड देते। त्याला थेट पुन्हा जोडू देणे उपलब्धता देते आणि ज्या गुणधर्मासाठी साखळी बांधली होती तो शांतपणे काढून टाकते। बाह्य मार्ग परत येईपर्यंत अडवणे हा सर्वात कडक आणि चालवायला सर्वात त्रासदायक पर्याय आहे, कारण बाह्य बोगद्याचा प्रत्येक डगमगाट दिसणारी घटना बनतो।
तिन्हीही निरुपद्रवी रहदारी आणि बाह्य बोगद्याच्या जाणीवपूर्वक अपयशासह तपासा, कारण संरचना वाचल्याने तुमच्याकडे कोणता पर्याय आहे ते कळणार नाही। बाह्य बोगदा मारा, आतील क्लायंट काय करतो ते पाहा, आणि तो पडलेला असताना मार्ग पुन्हा तपासा। मग बाह्य बोगदा परत आणा आणि साखळी पुन्हा तयार होते याची खात्री करा, आतील क्लायंटला यादरम्यान निवडलेल्या थेट मार्गावर सोडत नाही।
साखळी तुम्हाला काय देत नाही
अतिरिक्त स्तर टोके, किल्ल्या आणि अपयशाच्या पद्धती जोडतात; ते अनामिकतेची कोणतीही हमी जोडत नाहीत आणि बाह्य ऑपरेटरला बोगदा अस्तित्वात आहे हे पाहण्यापासून रोखत नाहीत। नेस्टिंग कशापासून संरक्षण देते याबद्दलच्या प्रत्येक दाव्यात तो निरीक्षक नमूद करणे आवश्यक आहे ज्याच्यापासून ते संरक्षण देते।
निष्पत्ती एक छोटा दस्तऐवज आहे, चालणारे कनेक्शन नाही: कोणते टोक कोणता मार्ग वापरते, बाह्य अपयशावर काय होते, आणि सध्याची स्थिती दाखवणाऱ्या तीन आज्ञा। strongSwan चे फॉरवर्डिंगवरील दस्तऐवज Linux होस्टवर बोगद्याची रहदारी इंटरफेसांमध्ये कशी पुढे पाठवली जाते याबद्दल उपयुक्त संदर्भ आहे। प्रत्येक क्लायंट अद्ययावतानंतर तपासण्या पुन्हा चालवा, कारण तुमची साखळी बनवणारी डीफॉल्ट मूल्ये करार नाहीत। जो नेस्टेड बोगदा तुम्ही तपासू शकत नाही तो स्थिती दिवा असलेली अफवा आहे।