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 आणि स्क्रिप्ट निर्देश त्यांच्या प्लॅटफॉर्म टिपांसह।