OpenVPN ले DNS पठाउँछ, तर तपाईंको रिजोल्भरले यो कहिल्यै नदेख्न सक्छ

क्लाइन्ट लगले पठाइएको DNS सर्भर देखाउँछ, टनेल जोडिएको छ, र आन्तरिक नाम अझै कुनै कुरामा रिजोल्भ हुँदैन। पठाउने काममा आफैंमा केही बिग्रेको छैन। विकल्प आइपुग्यो र अपरेटिङ सिस्टमको रिजोल्भरले यसलाई कहिल्यै प्रयोग गरेन, किनकि अधिकांश Unix क्लाइन्टमा OpenVPN मान बुझाएर एप्लिकेसनलाई प्लेटफर्ममा छोड्छ।

लक्षण: लगले DNS देखाउँछ र नामहरू अझै असफल हुन्छन्

OpenVPN dhcp-option ले DNS र डोमेन जानकारी बोक्छ, र क्लाइन्टले पाएको कुरा अभिलेख गर्छ। केही कार्यान्वयनमा क्लाइन्टले ती सेटिङहरू भित्री रूपमा लागू गर्छ; अरूमा तिनलाई एकीकरण स्क्रिप्ट वा नेटवर्क सेवाका लागि निर्यात गर्छ। लग लाइनले कथाको पहिलो आधा मात्र वर्णन गर्छ। दोस्रो आधा क्लाइन्टले नियन्त्रण नगर्ने ठाउँमा हुन्छ। असफलता सामान्यतया त्यहीँ बस्छ।

त्यसैले जोडिएको टनेल र असफल आन्तरिक नाम यति धेरै पटक सँगै रहन्छन्। मान छ, प्रयोगकर्ता छैन वा गलत कन्फिगर गरिएको छ, र रिजोल्भर चुपचाप जोडिनुअघि प्रयोग गरेको सार्वजनिक सर्भर प्रयोग गरिरहन्छ।

प्राप्त गर्नु लागू गर्नु होइन

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

हरेक Unix क्लाइन्टले उही फाइल पुनः लेख्छ भन्ने मान्नुको सट्टा कार्यान्वयनको समर्थित एकीकरण जाँच्नुहोस्। त्यही धारणाले मानिसहरूलाई केही पनि नपढ्ने रिजोल्भर कन्फिगरेसन सम्पादन गर्न लगाउँछ।

हरेक प्लेटफर्ममा रिजोल्भरको मालिक खोज्नुहोस्

Windows मा नाम रिजोल्युसन नीति तालिकाले निश्चित प्रत्ययहरूलाई निश्चित सर्भरतर्फ पठाउन सक्छ, र VPN क्लाइन्टले त्यहाँ नियम स्थापना गर्न सक्छ। एडाप्टरको DNS सूची मात्र होइन, नीति जाँच्नुहोस्। Linux मा NetworkManager वा systemd-resolved कन्फिगरेसनको मालिक हुन सक्छ, र तीमध्ये कुन मालिक हो त्यसले पुनः जोड्दा के सुरक्षित रहन्छ भन्ने निर्धारण गर्छ।

वास्तविक अवस्था साँच्चै प्रश्नहरूको जवाफ दिने उपकरणले पढ्नुहोस्: systemd-resolved होस्टमा resolvectl query internal.example.net, वा प्लेटफर्मको समकक्ष। त्यसपछि त्यो जवाफलाई क्लाइन्ट लगले पठाएको दाबी गर्ने DNS सर्भरसँग तुलना गर्नुहोस्।

समन्वय बिना रिजोल्भर सेटिङमाथि लेख्ने धेरै सेवाहरू चलाउनबाट बच्नुहोस्। दुई मालिकले बीच-बीचमा देखिने नतिजा दिन्छन्, र हरेक पुनः जडानले त्यसलाई अनियमित रूपमा सुधार्ने वा बिगार्ने देखिन्छ।

स्क्रिप्ट र foreign_option

OpenVPN ले पठाइएका विकल्पहरू foreign_option_N नामका चरहरूमार्फत स्क्रिप्टहरूमा निर्यात गर्छ, र स्क्रिप्टले तिनलाई रिजोल्भर आदेशमा अनुवाद गर्न सक्छ। यो व्यवस्था समर्थित एकीकरण हो, स्वचालित व्यवहार होइन, र यसलाई क्लाइन्टमा स्थापना गरी आह्वान गर्नुपर्छ।

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

लग होइन, नाम परीक्षण गर्नुहोस्

जोडिएपछि क्लाइन्टबाट केवल-आन्तरिक होस्टनाम सोध्नुहोस्, त्यसपछि सार्वजनिक नाम सोध्नुहोस्, त्यसपछि कुन सर्भरले जवाफ दियो जाँच्नुहोस्। काम गर्ने सेटअपमा दुवै जवाफ फरक ठाउँबाट आउँछन्, र दुवै डिजाइनसँग मिल्नुपर्छ।

नाम रिजोल्भ भयो तर सेवा असफल भयो भने DNS फेरि बदल्नुको सट्टा राउटिङ र एप्लिकेसन पहुँच तर्फ अघि बढ्नुहोस्। OpenVPN म्यानुअल ले dhcp-option र स्क्रिप्ट वातावरणको दस्तावेजीकरण गर्छ; अर्को रिजोल्भर फाइल सम्पादन गर्नुअघि तपाईंको क्लाइन्टले के लागू गर्नुपर्छ भनी पुष्टि गर्न यो प्रयोग गर्नुहोस्।