OpenVPN ले DNS सर्भर पठायो, तर Linux ले त्यसलाई बेवास्ता गर्छ

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

जाँच एक: जडान कसरी सुरु हुन्छ

जडानको मालिकले रिजोल्भर सेटिङ कसले लागू गर्न सक्छ भन्ने निर्धारण गर्छ। शेलबाट दिइएको सिधा openvpn आदेशले आफ्नै प्रक्रियाबाहेक केही राख्दैन, जबकि systemd युनिट, NetworkManager वा विक्रेताको ग्राहक प्रत्येकसँग DNS प्रकाशित गर्ने आफ्नै तरिका छ। यीमध्ये कुनै पनि मान्नुअघि प्रक्रिया सूची र युनिटको नाम पढ्नुहोस्।

कमाण्ड-लाइन प्रक्रिया आफैंमा NetworkManager जडान होइन, र NetworkManager जडान आफैंमा resolv.conf लेख्ने कुरा होइन। यी दुई अनुमानले यस अनुसन्धानमा बर्बाद भएका अधिकांश घण्टा व्याख्या गर्छन्। तपाईंले वास्तवमै देखिरहनुभएको इन्टरफेसका लागि कुन घटकले DNS प्रकाशित गर्छ भनी सोध्नुहोस्।

अगाडि बढ्नुअघि मालिक लेख्नुहोस्। पछिका हरेक जाँच यसमै निर्भर छ।

जाँच दुई: रिजोल्भर लिंकले वास्तवमा के राखेको छ

systemd-resolved होस्टमा, resolvectl status ले प्रत्येक लिंकलाई यसका DNS सर्भर र डोमेनसहित सूचीबद्ध गर्छ। टनेल लिंक भेट्टाउनुहोस् र यसका प्रविष्टि पढ्नुहोस्, र इन्टरफेसको नाम tun0 हो भनी नमान्नुहोस्, किनकि क्रमांकन सिर्जनाको क्रम पछ्याउँछ। पठाइएको ठेगाना लिंकमा छैन भने हस्तान्तरण असफल भयो, क्वेरी होइन।

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

कुनै निष्कर्षमा पुग्नुअघि रिजोल्भर आउटपुटको लिंक नामलाई VPN लगको इन्टरफेस नामसँग तुलना गर्नुहोस्। त्यहाँको अमिल्दोले सामान्यतया लगको लाइन अर्को प्रक्रियाबाट आएको देखाउँछ।

जाँच तीन: नामको ठाउँले त्यो लिंक छान्छ कि

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

डोमेन बाँडफाँट जाँच्नुहोस्, सर्भर ठेगाना मात्र होइन। ~corp.example का रूपमा लेखिएको डोमेन राउटिङ डोमेन हो, र टिल्ड चिन्हले नाम कसरी मिलाइन्छ भन्ने बदल्छ।

अनुप्रयोगसँग आफ्नै रिजोल्भर छ भने, प्रणाली उपकरणले होइन, त्यसले प्रयोग गर्ने त्यही संयन्त्रले परीक्षण गर्नुहोस्। प्रणाली रिजोल्भर छल्ने क्वेरी उपकरण लिंकको अवस्था जे भए पनि सफल हुनेछ।

जाँच चार: एक मालिक, दुई होइन

NetworkManager ले पहिले नै VPN र रिजोल्भरको अवस्था सम्हालिरहेको छ भने, असम्बन्धित हुक स्क्रिप्ट थप्नाले प्रतिस्पर्धी लेखक बन्छन्। प्याकेजले systemd-resolved का लागि दिने हुक समर्थित एकीकरण हो, र यसले निश्चित जीवनचक्र अपेक्षा गर्छ: script-security 2, up मार्ग, up-restart, down मार्ग र down-pre। ती विकल्पले दर्ता र हटाउने काम पहिलो जडानमा मात्र होइन, सही क्षणमा हुन्छ।

मार्गदर्शिकाबाट प्रतिलिपि गरिएको उदाहरणको सट्टा प्याकेजबाट स्थापित मार्ग प्रयोग गर्नुहोस्। अनुमतिहरू पनि महत्त्वपूर्ण छन्, किनकि हुक विशेषाधिकार घटेपछि चल्छ।

आफ्नो आउटपुट लक्ष्य बदल्न वितरणको रिजोल्भर स्क्रिप्ट सम्पादन गर्नु एउटा होस्टको उपाय अभिलेख गर्नु हो। यो सामान्य मर्मत होइन।

जाँच पाँच: फेरि जोडिएपछि त्यही परिणाम

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

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