OpenVPN: स्थानीय ठेगाना र टनेलको ठेगाना — दुई फरक सकेट

क्लाइन्ट सुरु हुन इन्कार गर्छ र स्थानीय ठेगाना बाइन्ड गर्न सक्दिन भनी गुनासो गर्छ, र स्पष्ट समाधान भनेको उसले अपेक्षा गरेको टनेल ठेगानातर्फ संकेत गर्नु जस्तो देखिन्छ। त्यो काम गर्न सक्दैन, र कारण बुझ्न लायक छ: टनेल अस्तित्वमा आउनुअघि भित्री ठेगाना हुँदैन, र सर्भरसँग सम्पर्क गर्ने सकेट पहिले हुनैपर्छ। यहाँ दुई फरक ठेगाना छन्, र तीमध्ये एउटा मात्र स्थानीय रूपमा छान्न सकिन्छ।

बाइन्ड त्रुटिले स्थानीय ठेगानाको नाम लिन्छ

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 पुस्तिका ले यही कारणले तिनलाई अलग खण्डमा लेखेको छ।

जाल: आफ्नै ट्रान्सपोर्ट समात्ने पूरा टनेल

टनेल उठेपछि र पूर्वनिर्धारित मार्ग बोकेपछि, त्यसलाई टिकाउने प्याकेटहरू त्यसभित्र रुट गर्नु हुँदैन। यो ठेगानाको नभई रुटिङको समस्या हो, र डेमनले मूल गेटवेमार्फत सर्भरकै ठेगानातर्फ बढी विशिष्ट मार्ग स्थापना गरेर समाधान गर्छ।

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

त्यसपछि लक्षणहरू जोडिएर स्तब्ध हुने टनेलजस्तै, वा उपयोगी त्रुटि बिना लूपमा फेरि जोडिने टनेलजस्तै देखिन्छन्। टनेलभित्र केही जाँच्नुअघि पियरको ठेगानासम्मको मार्ग जाँच्नुहोस्, र तपाईंले बाइन्ड गरेको स्थानीय ठेगाना अझै अपेक्षित इन्टरफेसकै हो भनी पुष्टि गर्नुहोस्।

भ्रम रोक्ने एउटा बानी

प्रोफाइलको हरेक ठेगाना पढ्नुहोस् र सम्पादन गर्नुअघि त्यो कुन तहको हो निर्णय गर्नुहोस्।

यदि त्यसले ट्रान्सपोर्टको टाढाको छेउको नाम दिन्छ वा त्यसको नजिकको छेउ बाइन्ड गर्छ भने त्यो बाहिरी ठेगाना हो र सुरु हुनुअघि हुनैपर्छ। यदि त्यसले टनेलभित्र के हुन्छ वर्णन गर्छ भने त्यो सर्भर वा टोपोलोजीबाट आउँछ, र कुनै स्थानीय निर्देशनले त्यसको ठाउँ लिन सक्दैन।

दुई सूची प्रोफाइलनजिकैको परिनियोजन नोटमा लेख्नुहोस्। अर्को समस्या-समाधान सत्र त्यसपछि अनुमानबाट नभई तहबाट सुरु हुनेछ।