रुट गरिएको OpenVPN टनेलमा नाम खोजी किन असफल हुन्छ

होस्टले ठेगानाद्वारा ping को जवाफ दिन्छ र नामद्वारा गरिने हरेक खोजीमा असफल हुन्छ। टनेल चालु छ र मार्ग अवस्थित छ, त्यसैले स्वाभाविक निष्कर्ष VPN गलत कन्फिगर गरिएको हो। अझ उपयोगी निष्कर्ष के हो भने त्यो खोजी कहिल्यै रुट गर्न योग्य थिएन: रुट गरिएको टनेलले unicast IP बोक्छ, जबकि त्यो प्रश्न ब्रोडकास्ट थियो जो अर्को छेउमा नभएको सेग्मेन्ट खोजिरहेको थियो। तहहरूको असमझदारी देखिने बित्तिकै उपायहरू आफैं लागतका क्रममा मिल्छन्।

भ्रम: नाम असफल हुने भएकाले टनेल बिग्रिएको छ

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

यसलाई टनेलको खराबीका रूपमा लिनुले मद्दत गर्न नसक्ने प्रोफाइल सम्पादनमा पुर्याउँछ। विकल्प थप्ने, इन्क्रिप्सन बदल्ने वा क्लाइन्ट पुनः स्थापना गर्ने कामले ब्रोडकास्टलाई जहाँ थियो त्यहीं छोड्छ।

उपायको नाम लिनुअघि असफल भएको संयन्त्रको नाम लिनुहोस्। ब्रोडकास्ट प्रयोग गर्ने खोजीलाई सेग्मेन्ट चाहिन्छ, जबकि रिजोल्भर प्रयोग गर्ने खोजीलाई सोध्न ठेगाना चाहिन्छ।

TUN ले के बोक्छ र के बोक्दैन

TUN यन्त्र एउटा IP इन्टरफेस हो, र यही कुराले यसलाई रुट गर्न योग्य बनाउँछ। OpenVPN ले क्लाइन्टलाई ठेगाना र मार्गहरूको समूह दिन्छ, र त्यसपछि क्लाइन्टले साथीलाई डेटाग्राम पठाउँछ। त्यो मोडेलमा प्रत्येक होस्टले प्रत्येक फ्रेम सुन्ने साझा लिङ्क बनाउने कुनै कुरा छैन।

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

त्यसैले टनेल स्वस्थ हुन सक्छ जबकि खोजी पूर्ण रूपमा असफल हुन्छ। कोहीले VPN डाउन छ भनी रिपोर्ट गर्दा यही वाक्य समात्नुपर्छ।

ब्रिजिङले सीमा हटाएर काम गर्छ

TAP यन्त्रले फ्रेम बोक्छ, र पुलले यसलाई वास्तविक LAN सेग्मेन्टसँग जोड्छ। त्यसपछि क्लाइन्टसँग त्यो सेग्मेन्टमा ठेगाना हुन्छ र त्यसको ब्रोडकास्ट ट्राफिक सुन्छ। यही कारण ब्रिजिङले नामको समस्या निको पारेजस्तो देखिन्छ। यसले क्लाइन्टलाई ठेगाना दिन त्यो सेग्मेन्टमा निर्भर पनि बनाउँछ।

उपचार भनेको रुटिङ सीमा हटाउनु हो, टनेलभित्र नामकरणको नयाँ क्षमता होइन। सेग्मेन्टले ब्रोडकास्ट गर्ने सबै अब लिङ्क पनि तर्छ।

सानो प्रयोगशालाका लागि यो न्यायपूर्ण साटासाट हो। छरिएको जनशक्तिका लागि यो विरलै हुन्छ।

DNS र WINS पुश गर्नु साँघुरो उपचार हो

क्लाइन्टलाई सोध्ने निश्चित ठाउँ दिनुहोस्। dhcp-option DNS र dhcp-option DOMAIN ले आन्तरिक नामहरूलाई जोन चिन्ने सर्भरतिर पठाउँछ, र अझै NetBIOS मा भर पर्ने Windows क्लाइन्टले त्यही तरिकाले WINS सर्भर पाउन सक्छ। टनेल रुट गरिएकै रहन्छ र सेग्मेन्ट आफ्नो ठाउँमै रहन्छ।

दुई सर्तले यो काम गर्छ कि गर्दैन भन्ने तय गर्छ। नाम लिइएको सर्भरले जोनका लागि जवाफ दिनुपर्छ, र प्रश्नलाई टनेलबाट अनुमति दिइनुपर्छ।

रिजोल्भर क्लाइन्टबाट परीक्षण गर्नुहोस्, सर्भरको आफ्नै शेलबाट होइन। स्थानीय रूपमा काम गर्ने रिजोल्भरले टनेलले के बोक्छ भन्नेबारे केही भन्दैन।

कुन तह असफल भयो पत्ता लगाउनुहोस्

पहिले ठेगानामा ping गर्नुहोस्, त्यसपछि नाम रिजोल्भ गर्नुहोस् र कुन सर्भरले जवाफ दियो पढ्नुहोस्। जोन होस्ट नगर्ने सर्भरको नकारात्मक जवाफ, मेसिनबाट कहिल्यै ननिस्केको प्रश्नभन्दा फरक देखिन्छ। रिजोल्भ हुने तर जडान अस्वीकार गर्ने नाम पूर्ण रूपमा तेस्रो समस्या हो।

मल्टिकास्ट त्यही पर्खालपछि छ। 224.0.0.251 जस्तो समूह पूर्वनिर्धारित रूपमा रुट गरिएको टनेलबाट अगाडि पठाइँदैन, र मल्टिकास्ट बुझ्ने मार्ग वा LAN मा परावर्तक बिना समूहका लागि मार्ग पर्याप्त हुँदैन।