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 रह जाता है।

जो घटक उसे पंजीकृत करता है उसके माध्यम से उसे सेवानिवृत्त करें, फिर पुष्टि करें कि रिकॉर्ड निर्देशिका अब उसे सूचीबद्ध नहीं करती।

आपूर्तिकर्ता का नाम, आपने जो पैटर्न बदला और आपने जो दो लुकअप चलाए, उन्हें दर्ज करें। अगले व्यक्ति को कहानी से अधिक उन नामों की ज़रूरत है।