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 र स्क्रिप्ट निर्देशनहरू तिनका प्लेटफर्म टिप्पणीसहित।