OpenVPN द्वारा पुश किया गया DNS अनदेखा: कौन सा घटक इसे लागू करता है

लॉग वह विकल्प दिखाता है जो सर्वर ने पुश किया, टनल चालू है, और आंतरिक नाम अब भी विफल होते हैं। रिज़ॉल्वर को सीधी क्वेरी उत्तर देती है, इसलिए सर्वर ठीक है, फिर भी हर एप्लिकेशन स्थानीय राउटर से पूछता रहता है। क्लाइंट तक जो पहुँचा वह प्रस्ताव है, रिज़ॉल्वर में बदलाव नहीं, और नाम-समाधान का स्वामी घटक Linux, Windows और macOS पर अलग है। जैसे ही आप विकल्प को उसके स्वामी से अलग करते हैं, चार दोष लगभग हर रिपोर्ट को कवर करते हैं: कोई हुक नहीं, दो प्रतिस्पर्धी हुक, विभाजित DNS जो डिज़ाइन के अनुसार काम कर रहा है, या ऐसा छोटा नाम जिसे सर्वर नहीं, प्रत्यय चाहिए।

पुश किया गया विकल्प प्रस्ताव है, इंस्टॉलेशन नहीं

सर्वर पर दो निर्देश प्रभाव नहीं, मंशा बताते हैं:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

क्लाइंट को कॉन्फ़िगर किया गया रिज़ॉल्वर नहीं मिलता। उसे पर्यावरण चर मिलते हैं, foreign_option_1 और आगे, हर पुश की गई पंक्ति के लिए एक, और किसी स्थानीय चीज़ को उन्हें पढ़कर ऑपरेटिंग सिस्टम की रिज़ॉल्वर स्थिति फिर से लिखनी होती है। Linux पर डिफ़ॉल्ट रूप से कोई ऐसा नहीं करता, इसलिए सही सर्वर और जुड़ा क्लाइंट अब भी LAN से नाम हल कर सकते हैं।

दोनों सिरों के बीच तीन चरण हैं: पुश को पहुँचना है, क्लाइंट को उसे उजागर करना है, और हुक को उसे लागू करना है। मध्य चरण क्लाइंट लॉग में और अंतिम चरण रिज़ॉल्वर स्थिति में पढ़ें, कभी उलटा नहीं, क्योंकि लॉग की एक पंक्ति केवल पहले दो को सिद्ध करती है।

पुष्टि करें कि पुश पहुँचा और स्वामी खोजें

शुरुआत लॉन्चर का नाम लेकर करें: एक नंगा openvpn कमांड, systemd इंस्टेंस, NetworkManager या विक्रेता क्लाइंट। यह तय करता है कि हुक कहाँ रह सकता है। systemd-resolved वाले होस्ट पर, resolvectl status हर लिंक को उसके वास्तव में उपयोग होने वाले DNS सर्वरों और खोज डोमेनों के साथ सूचीबद्ध करता है, और टनल लिंक का नाम हमेशा tun0 नहीं होता।

यदि पुश किया गया पता लॉग में दिखता है पर किसी लिंक पर नहीं, तो एकीकरण गायब है। यदि वह लिंक पर है और क्वेरी अब भी कहीं और जाती हैं, तो समस्या यह है कि कौन सी क्वेरी उस लिंक को चुनती हैं। NetworkManager dns=dnsmasq में /etc/NetworkManager/NetworkManager.conf फ़ाइल में एक स्थानीय फ़ॉरवर्डर चलाता है जो विभाजित DNS जानबूझकर लागू करता है: VPN डोमेन के भीतर के नाम VPN रिज़ॉल्वर पर जाते हैं, बाकी सब अपना पिछला पथ रखता है। यह व्यवहार दोष जैसा लगता है जब आपको उम्मीद थी कि सारा ट्रैफ़िक हट जाएगा; प्रति-कनेक्शन सेटिंग्स जाँचें nmcli connection show "My VPN" से, जहाँ ipv4.dns और ipv4.dns-search डिवाइस जो रिपोर्ट करता है उसके पीछे के मान रखते हैं, इसे टूटा कहने से पहले। यदि हर क्वेरी को वाकई VPN रिज़ॉल्वर तक पहुँचना चाहिए, तो हटाएँ dns=dnsmasq को NetworkManager.conf से और NetworkManager को पुनः आरंभ करें, जो नाम-समाधान कनेक्शन सेटिंग्स को लौटा देता है; अन्यथा विभाजित DNS रखें और पुश की गई डोमेन सूची सुधारें।

Linux: विकल्प रिज़ॉल्वर को सौंपें

डिस्ट्रीब्यूशन पैकेज इसके लिए हुक देते हैं, और क्लाइंट को उसे चलाने की अनुमति होनी चाहिए। systemd-resolved के बिना होस्ट पर सामान्य व्यवस्था:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

systemd-resolved के साथ पुरानी resolv.conf स्क्रिप्ट शायद कुछ महत्वपूर्ण न बदले, क्योंकि stub रिज़ॉल्वर प्रति लिंक स्थिति रखता है। update-systemd-resolved सहायक एक हुक रूप का दस्तावेज़न करता है जो up-restart और down-pre का उपयोग करता है, जो तब मायने रखता है जब कोई इंटरफ़ेस एक कनेक्शन प्रयास से अधिक टिकता है। आप जो भी चुनें, एक घटक के पास स्थिति का स्वामित्व होना चाहिए। NetworkManager के बगल में असंबंधित हुक जोड़ने से उसी लिंक को दो लेखक मिलते हैं, और परिणाम तब आपके कॉन्फ़िगरेशन के बजाय क्रम पर निर्भर करता है।

ऐसा मामला भी है जब NetworkManager ने पुश किए गए विकल्प को पूरी तरह अनदेखा किया जब तक सर्वर पता कनेक्शन की IPv4 सेटिंग्स में दर्ज नहीं हुआ, और फिर रिज़ॉल्वर स्थिति ने उसे उपयोग में दिखाया। स्क्रिप्ट फिर से लिखने से पहले इसे आज़माना उचित है, क्योंकि यह समस्या को शेल हुक से उस कनेक्शन प्रोफ़ाइल में ले जाता है जो पहले से टनल ले जाता है।

Windows और macOS अलग-अलग हिस्से लागू करते हैं

Windows क्लाइंट VPN अडैप्टर के DNS सर्वर वाकई सेट करता है, पर Windows अब भी मेट्रिक से इंटरफ़ेस चुनता है और छोटे नाम को फैलाने के लिए अब भी प्रत्यय चाहिए। प्रोफ़ाइल नहीं, अडैप्टर की स्थिति की पुष्टि करें:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

यदि पता गायब है, इसे इससे सेट करें Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, फिर प्रत्यय को अडैप्टर के IPv4 गुणों में जोड़ें ताकि fileserver बन जाए fileserver.corp.example। मशीन-व्यापी SearchList के अंतर्गत मान Tcpip\Parameters वही करता है। जहाँ लंबा नाम हल होता है और नंगा नहीं, वहाँ रिज़ॉल्वर पहले से सही है और दोष खोज सूची का है। सुधार क्रम में: पुश करें एक DOMAIN ताकि क्लाइंट प्रत्यय सीखे, वह प्रत्यय अडैप्टर या कनेक्शन की खोज सूची में जोड़ें, और अस्थायी उपाय के रूप में नाम को इसमें स्थिर करें hosts, या LMHOSTS Windows पर; NetBIOS ब्राउज़िंग राउटर पार नहीं करती, इसलिए ऑफ़िस LAN पर छोटा नाम खोजने वाला ब्रॉडकास्ट कभी टनल क्लाइंट तक नहीं पहुँचता।

block-outside-dns block-outside-dns Windows क्लाइंट का व्यवहार है, पोर्टेबल प्रोफ़ाइल पंक्ति नहीं, और इसे Linux या macOS प्रोफ़ाइल में कॉपी करने से वह वहाँ दोहराया नहीं जाता। यदि Windows पर सार्वजनिक नाम काम करते हैं और आंतरिक विफल होते हैं, तो उन्नत सेटिंग्स के अंतर्गत अडैप्टर क्रम की तुलना करें ipconfig /all से। macOS पर प्रति-सेवा रिज़ॉल्वर क्रम सिस्टम का है, इसलिए उपयोग करें scutil --dns यह देखने के लिए कि किस डोमेन के लिए कौन सा रिज़ॉल्वर पूछा जाता है, और किसी भी एकल रिपोर्ट किए गए प्रोफ़ाइल सुधार को सामान्य नहीं, क्लाइंट-निर्भर मानें।

उसी लैपटॉप पर वर्चुअल मशीन इसमें से कुछ नहीं पाती। अतिथि को आंतरिक डोमेन के लिए अपनी रिज़ॉल्वर प्रविष्टि दें, या हाइपरवाइज़र के NAT को उसकी क्वेरी होस्ट से आगे भेजने दें, जो केवल तब तक सही है जब तक होस्ट का टनल चालू है।

इतिहास तीसरा कारण है। पिछली प्रोफ़ाइल के DNS सर्वर या प्रत्यय सेटिंग्स पुनः कनेक्शन पर टिक सकते हैं, इसलिए जब अडैप्टर सही दिखता है और लुकअप अब भी विफल होते हैं, जीवंत अडैप्टर की तुलना करें Get-VpnConnection से और सर्वर को छूने से पहले पुरानी प्रविष्टि मिटाएँ या अधिलिखित करें।

सिद्ध करें कि क्वेरी कहाँ गई

एक लुकअप के दौरान कैप्चर बहस तय कर देता है: tcpdump -ni eth0 port 53 भौतिक इंटरफ़ेस पर क्वेरी दिखाता है, यानी वे टनल से बाहर जा रही हैं और रिज़ॉल्वर कभी बदला ही नहीं गया। dig @10.8.0.1 name.corp.example फिर शेष दो मामलों को अलग करता है। यदि सीधी क्वेरी उत्तर देती है, रिज़ॉल्वर काम कर रहा है और क्लाइंट उसका उपयोग नहीं कर रहा; यदि समय समाप्त होता है, रिज़ॉल्वर टनल से अगम्य है और कोई स्थानीय बदलाव मदद नहीं करेगा।

यदि अब भी उपयोग हो रहा रिज़ॉल्वर वही है जो प्रदाता ने बाँटा, तो टनल ट्रैफ़िक एन्क्रिप्ट करता है जबकि नाम उस प्रदाता को दिखते रहते हैं। यह कार्यक्षमता नहीं, लीक का प्रश्न है, और वही कैप्चर इसका उत्तर देता है: भौतिक इंटरफ़ेस पर क्वेरी टनल के बाहर किसी के पास जा रही है।

पहुँच में VPN होस्ट का फ़ायरवॉल भी है, जिसे पूल से UDP और TCP 53 की अनुमति देनी चाहिए। बंद पोर्ट ठीक टूटे पुश जैसा दिखता है, और वैसा ही वह रिज़ॉल्वर जो केवल टनल नेटवर्क के भीतर से उत्तर देता है। एक बार डिस्कनेक्ट और पुनः कनेक्ट के बाद कैप्चर दोहराएँ, क्योंकि पहले कनेक्शन पर दिखने और दूसरे पर गायब होने वाली सेटिंग्स हुक में जीवनचक्र दोष हैं, गायब विकल्प नहीं।

एक स्वामी रखें और क्रम से सत्यापित करें

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

चार जाँचों से चक्र बंद करें: पुश किया गया पता टनल लिंक पर मौजूद, आंतरिक नाम पूर्णतः योग्य नाम के रूप में हल होता, वही नाम प्रत्यय के बिना हल होता, और एक पुनः कनेक्शन के बाद भी दोनों सत्य। एक कैप्चर बताता है कि चारों में से कौन विफल हुआ। OpenVPN 2.6 मैनुअल सूचीबद्ध करता है dhcp-option और स्क्रिप्ट निर्देशों को उनके प्लेटफ़ॉर्म नोट्स के साथ।