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। वे विकल्प पंजीकरण और हटाने को केवल पहले कनेक्शन पर नहीं, सही क्षणों पर होने देते हैं।

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

अपने आउटपुट लक्ष्य को बदलने के लिए किसी वितरण की रिज़ॉल्वर स्क्रिप्ट संपादित करना एक ही होस्ट का उपाय दर्ज करता है। यह सामान्य मरम्मत नहीं है।

जाँच पाँच: फिर से कनेक्ट करने के बाद वही परिणाम

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

फिर से कनेक्ट पर पाँचों जाँचें पास होने पर ही आप कह सकते हैं कि भेजी गई सेटिंग उपयोग में है। उससे पहले का सब कुछ एक भाग्यशाली क्षण का स्नैपशॉट है।