Debian resolvconf रेकर्ड क्रम: VPN रेकर्ड पहिले राख्नुहोस्

VPN को नेमसर्भर बारम्बार LAN को नेमसर्भरभन्दा तल पर्छ, र /etc/resolv.conf सम्पादन गर्दा त्यो केही मिनेटका लागि ठीक हुन्छ। त्यो फाइल उत्पन्न हुन्छ, त्यसैले सुधार कहिल्यै टिक्दैन। Debian को resolvconf मा क्रमको इनपुट /etc/resolvconf/interface-order हो, र यसले DNS ठेगाना नभई रेकर्डका नामहरू क्रमबद्ध गर्छ। दुईमध्ये कुनै पनि फाइल छुनुअघि कुन resolver स्ट्याक वास्तवमा जिम्मेवार छ भनी पुष्टि गर्नुहोस्।

आउटपुट resolvconf कै हो भनी पुष्टि गर्नुहोस्

हालको फाइल कसले लेख्यो र फेरि कसले लेख्नेछ भनेर सोधेर सुरु गर्नुहोस्। resolvconf प्याकेजले आफूलाई गतिशील resolver कन्फिगरेसनको ढाँचाका रूपमा वर्णन गर्छ, र systemd-resolved वा NetworkManager ले व्यवस्थापन गरेको resolver चलाउने होस्ट बाहिरबाट उस्तै देखिन सक्छ तर पूर्ण रूपमा फरक नीति प्रयोग गर्न सक्छ।

readlink -f /etc/resolv.conf
dpkg -l resolvconf 2>/dev/null | tail -n 1

यदि समाधान गरिएको बाटो resolvconf को रनटाइम डाइरेक्टरीमा पुग्दैन भने यहीँ रोक्नुहोस्: यो पुस्तिका अर्को स्ट्याकको हो।

त्यो जाँचपछि मात्र resolvconf सँग अहिले रहेका रेकर्डहरू सूचीबद्ध गर्नु उपयुक्त हुन्छ।

ढाँचा लेख्नुअघि रेकर्डहरू पढ्नुहोस्

interface-order आपूर्तिकर्ता रेकर्डका नामसँग मिल्छ, ठेगाना वा कर्नेल इन्टरफेस नामसँग होइन। के दर्ता भएको छ सूचीबद्ध गर्नुहोस् ताकि तपाईंका ढाँचाले अवस्थित प्रविष्टिहरूलाई सन्दर्भ गरून्।

ls /run/resolvconf/interfaces
cat /etc/resolvconf/interface-order

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

क्रमलाई पहिलो-मेल ढाँचाका रूपमा लेख्नुहोस्

फाइल shell glob ढाँचाहरूको सूची हो, प्रत्येक लाइनमा एक। रेकर्डले आफू मिल्ने पहिलो ढाँचाको स्थान लिन्छ, त्यसैले विशिष्ट ढाँचामाथि फराकिलो ढाँचा राख्दा त्यो विशिष्ट लाइन पुग्न नसकिने हुन्छ।

# /etc/resolvconf/interface-order
lo*
tun_work.*
enp*
*

विशिष्ट टनेल ढाँचालाई सबै समात्ने ढाँचामाथि र भौतिक इन्टरफेस ढाँचामाथि राख्नुहोस्।

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

पुनः उत्पन्न गर्नुहोस् र नतिजा जाँच्नुहोस्

अपडेट स्क्रिप्टले फाइल पुनर्निर्माण गर्दा क्रम लागू हुन्छ। उत्पन्न आउटपुट सम्पादन गर्नुको सट्टा समर्थित अपडेट मार्ग चलाउनुहोस्, त्यसपछि resolver ले वास्तवमा के प्राप्त गर्यो पढ्नुहोस्।

resolvconf -u
cat /etc/resolv.conf

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

पुरानो रेकर्डलाई तल्लो दर्जामा राख्नुको सट्टा अवकाश दिनुहोस्

जडान काटिएपछि फेरि फेरि देखा पर्ने पुरानो VPN रेकर्ड क्लाइन्ट एकीकरणमा जीवनचक्रको त्रुटि हो. यसलाई सबैभन्दा तल सार्दा लक्षण लुक्छ र सूचीमा मृत resolver रहन्छ।

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

आपूर्तिकर्ताको नाम, तपाईंले बदलेको ढाँचा र तपाईंले चलाएका दुई लुकअप लेख्नुहोस्। अर्को व्यक्तिलाई कथाभन्दा ती नामहरू बढी चाहिन्छ।