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

बाइंड त्रुटी स्थानिक पत्त्याचे नाव घेते

OpenVPN स्थानिक पत्ता बाइंड करू शकत नाही असे नोंदवते तेव्हा ते ट्रान्सपोर्ट सॉकेटबद्दल बोलत असते: एन्क्रिप्टेड कनेक्शन पीअरपर्यंत नेणारा UDP किंवा TCP अंतिम बिंदू।

स्पष्ट local निर्देश डेमॉनला ते सॉकेट विशिष्ट स्थानिक पत्त्यावर बाइंड करण्यास सांगतो। पत्ता ज्या नेटवर्क नामस्थानात प्रक्रिया चालते तेथे असणे आवश्यक आहे, आणि क्लायंट सुरू होतो त्या क्षणी तो वाटपयोग्य असणे आवश्यक आहे।

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

local आणि remote प्रत्यक्षात काय निवडतात

remote संपर्क साधावयाच्या पीअरचे नाव घेते। local त्याच सॉकेटचे जवळचे टोक बाइंड करते। nobind स्थानिक पत्ता आणि पोर्ट दोन्ही ऑपरेटिंग सिस्टमला निवडू देतो, म्हणून घरगुती राउटरमागील क्लायंट सहसा दोन्हीपैकी कोणत्याही निर्देशाशिवाय चालतात।

दोन्हीपैकी कोणत्याही निर्देशाचा टनेलमधील पत्त्याशी काही संबंध नाही।

कंटेनर किंवा नेटवर्क नामस्थानात तोच नियम अरुंद सीमांसह लागू होतो: होस्टचे पत्ते आत नसतात, म्हणून होस्ट कॉन्फिगरेशनमधून कॉपी केलेली local ओळ चुकीच्या पत्त्यापेक्षा पूर्णपणे वेगळ्या कारणाने अयशस्वी होते।

ip -brief address show
ip route get 203.0.113.10

आतील पत्ता सर्व्हरकडून येतो

टनेलमधील पत्ता नियंत्रण चॅनल स्थापित झाल्यानंतर वाटाघाटीने किंवा वाटपाने ठरवला जातो। गतिशील पूलमध्ये सर्व्हर तो कनेक्शनच्या वेळी ठरवतो, आणि क्लायंट-विशिष्ट कॉन्फिगरेशनमध्ये तो प्रत्येक ओळखीसाठी स्थिर असू शकतो।

आतील पत्त्यासह local लिहिणे सर्व्हरला तो पत्ता वाटप करण्यास सांगत नाही। सर्वोत्तम बाबतीत बाइंड अयशस्वी होते; सर्वात वाईट बाबतीत क्लायंटला त्याच मूल्याचा असंबंधित होस्ट पत्ता सापडतो आणि तो ट्रान्सपोर्टसाठी वापरण्यास सुरुवात करतो।

वाचावयाचे इंटरफेसही वेगळे आहेत। ifconfig पॅरामीटर आणि पूल कॉन्फिगरेशन आतील बाजू वर्णन करतात, तर remote, local, proto आणि nobind बाहेरील बाजू वर्णन करतात। दोन्ही याद्या वेगळ्या ठेवल्यास फोरमवर सापडणारे जवळजवळ प्रत्येक गोंधळात टाकणारे उदाहरण स्पष्ट होते। OpenVPN 2.6 पुस्तिका याच कारणास्तव ते वेगळ्या विभागांत नोंदवते।

सापळा: स्वतःचे ट्रान्सपोर्ट पकडणारे पूर्ण टनेल

टनेल उभे राहिल्यावर आणि डीफॉल्ट मार्ग वाहून नेल्यावर, ते टिकवणारे पॅकेट त्याच्या आत मार्गस्थ होऊ नयेत। ही पत्त्याची नव्हे, तर मार्गनिर्देशनाची समस्या आहे, आणि डेमॉन ती मूळ गेटवेमार्फत सर्व्हरच्याच पत्त्याकडे अधिक विशिष्ट मार्ग बसवून सोडवतो।

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

मग लक्षणे जोडले जाऊन गोठणाऱ्या टनेलसारखी दिसतात, किंवा उपयुक्त त्रुटीशिवाय लूपमध्ये पुन्हा जोडल्या जाणाऱ्या टनेलसारखी दिसतात। टनेलमध्ये काहीही तपासण्यापूर्वी पीअरच्या पत्त्याकडे जाणारा मार्ग तपासा, आणि तुम्ही बाइंड केलेला स्थानिक पत्ता अजूनही अपेक्षित इंटरफेसचा आहे याची खात्री करा।

गोंधळ टाळणारी एक सवय

प्रोफाइलमधील प्रत्येक पत्ता वाचा आणि संपादित करण्यापूर्वी तो कोणत्या स्तराचा आहे ते ठरवा।

जर तो ट्रान्सपोर्टच्या दूरच्या टोकाचे नाव घेत असेल किंवा त्याचे जवळचे टोक बाइंड करत असेल, तर तो बाहेरील पत्ता आहे आणि सुरू होण्यापूर्वी तो असला पाहिजे। जर तो टनेलमध्ये काय घडते याचे वर्णन करत असेल, तर तो सर्व्हरकडून किंवा टोपोलॉजीकडून येतो, आणि कोणताही स्थानिक निर्देश त्याची जागा घेऊ शकत नाही।

दोन्ही याद्या प्रोफाइलजवळील तैनाती नोंदींमध्ये लिहा। पुढील समस्या-निवारण सत्र नंतर अंदाजाने नव्हे, तर स्तरापासून सुरू होईल।

संबंधित लेख