WireGuard DNS पुश करत नाही: खाजगी BIND झोनची सेवा

तुम्ही WireGuard उभारले, टनेल ट्रॅफिक पास करत आहे, आणि अंतर्गत नाव अजूनही सोडवले जात नाही। पुढचे पाऊल सहसा WireGuard कॉन्फिगरेशनमध्ये DNS सेटिंग शोधणे असते, जसे की एखादा पीअर रिझोल्व्हर पुश करू शकतो जसे काही इतर VPN करतात। तो करू शकत नाही। हँडशेक की, इंटरफेस पत्ते आणि परवानगी दिलेले IP घेऊन जातो, आणि त्यात DNS सर्व्हर किंवा शोध डोमेनसाठी कोणतेही फील्ड नाही। रिझोल्व्हर धोरण क्लायंटवर राहते, आणि दुरुस्ती तिथेच आहे।

टनेल आणि रिझोल्व्हर वेगळे करार आहेत

WireGuard जाणूनबुजून लहान आहे। तुम्ही सूचीबद्ध केलेल्या पत्त्यांसाठी तो पॅकेट हलवतो आणि पीअर प्रमाणित करतो; त्या थराच्या वरचे सर्व काही तुमची रचना आहे। OpenVPN dhcp-option DNS पुश करू शकतो कारण त्याचा नियंत्रण चॅनेल कॉन्फिगरेशन घेऊन जातो, आणि हा फरक दोघांमध्ये फिरणाऱ्यांना अडखळवतो।

त्यामुळे काम करणारे टनेल नाव निराकरणाबद्दल काहीही सांगत नाही। क्लायंटकडे 10.90.0.1 पर्यंत उत्तम मार्ग असू शकतो आणि तरीही तो आपल्या क्वेरी सार्वजनिक रिझोल्व्हरला पाठवू शकतो, म्हणूनच लक्षण “VPN ने DNS तोडले” असे दिसते, जेव्हा DNS कधीही VPN कडे निर्देशित झाले नव्हते।

पुनरावृत्ती रिझोल्व्हर न बनता झोनची सेवा करा

सर्व्हर बाजू एक छोटा अधिकृत झोन आहे, सामान्य रिझोल्व्हर नव्हे। या उदाहरणात गेटवे 10.90.0.1 आहे, क्लायंट 10.90.0.0/24 आहेत, आणि तुम्हाला महत्त्वाचे असलेले अनुप्रयोग 10.60.0.20 वर उत्तर देतात।

दुसरा ब्लॉक तयार करण्याऐवजी ही सेटिंग्ज विद्यमान options ब्लॉकमध्ये विलीन करा:

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

नंतर झोन आणि त्याची फाइल घोषित करा:

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};

$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

रीलोड करण्यापूर्वी पडताळणी करा, कारण लोड होताना वाक्यरचना त्रुटी तो सेवा देत असलेल्या प्रत्येक झोनसाठी संपूर्ण सर्व्हर खाली आणते:

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

UDP आणि TCP 53 फक्त VPN इंटरफेसवर उघडा। सार्वजनिक इंटरफेसवर खाजगी अधिकार प्रकाशित केल्यास क्वेरी आणि गणना दोन्ही आमंत्रित होतात, आणि allow-transfer दुय्यमला खरोखर आवश्यक नसल्यास बंद राहिले पाहिजे।

क्लायंटला त्याकडे वळवा, प्रत्येक लिंकसाठी

कनेक्शन NetworkManager च्या मालकीचे आहे आणि रिझोल्व्हर systemd-resolved आहे असे गृहीत धरा। प्रथम विद्यमान धोरण वाचा, विशेषतः कोणतेही मूळ राउटिंग डोमेन, कारण ~. नोंद तुम्ही जोडणार असलेल्या गोष्टीपेक्षा पुढे जाईल।

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

टिल्ड हे महत्त्वाचे अक्षर आहे। ते डोमेनला केवळ-मार्ग म्हणून चिन्हांकित करते: corp.example अंतर्गत नावे या लिंकच्या DNS सर्व्हरकडे जातात, आणि डोमेन लहान नाव शोध प्रत्यय म्हणून जोडले जात नाही। त्याशिवाय, portal टाइप केल्यावर portal.corp.example सोडवले जाऊ लागते, जे तुमच्यासाठी सोयीचे आणि बाकी सर्वांसाठी आश्चर्यकारक आहे। टिल्ड अवतरण चिन्हांच्या आत ठेवा, कारण अवतरण नसलेले हे तुमच्या होम डिरेक्टरीकडे निर्देश करण्याच्या प्रतीक्षेत असलेले शेल विस्तार आहे।

इंटरफेसच्या मालक व्यवस्थापकामार्फत बदल लागू करा, नंतर कनेक्शन पुन्हा जोडा। त्याच इंटरफेससाठी दुसरे wg-quick उदाहरण सुरू करू नका; दोन मालक मार्गांसाठी भांडतील आणि त्यातील एक सर्वात वाईट क्षणी जिंकेल।

नावापूर्वी मार्ग पडताळा

क्लायंटकडून नाव विचारा आणि उत्तर तसेच ते तयार करणारा सर्व्हर दोन्हीची पुष्टी करा:

resolvectl query portal.corp.example

जर ते 10.60.0.20 परत देते, तर DNS करार पूर्ण झाला। जर वेळ संपत असेल, तर प्रथम 10.90.0.1 चा मार्ग, नंतर फायरवॉल नियम, नंतर सर्व्हरवरील allow-query तपासा। या रचनेतील नाव निराकरणातील अपयश जवळजवळ नेहमी पोहोच किंवा ACL असते, झोन फाइल नाही। क्लायंटपासून बाहेरच्या दिशेने काम करा, कारण क्वेरी का कधीही पोहोचली नाही हे सर्व्हर तुम्हाला सांगू शकत नाही।

लक्षात ठेवा की अनुप्रयोगाला अजूनही स्वतःचा मार्ग आणि स्वतःची सेवा परवानगी हवी आहे। पोहोचता न येणाऱ्या पत्त्याकडे निर्देश करणारे सोडवलेले नाव हे त्याच कपड्यांतील दुसरे अपयश आहे।

अजूनही स्वयंचलित नसलेले

स्वतःचे रिझोल्व्हर तर्क असलेले अनुप्रयोग सिस्टम रिझोल्व्हरकडे पूर्णपणे दुर्लक्ष करतात, आणि कितीही nmcli असले तरी ते बदलत नाही। DNSSEC पडताळणी करणाऱ्या तैनातींना खाजगी झोनसाठी स्पष्ट ट्रस्ट अँकर रचना आवश्यक आहे; पडताळणी बंद करण्याची सर्वव्यापी सूचना हे उत्तर नाही। तुमचे वापरकर्ते चालवत असलेल्या त्याच क्लायंट सॉफ्टवेअरने चाचणी करा, योगायोगाने सिस्टम रिझोल्व्हर वापरणाऱ्या साधनाने नाही। या दोघांमधील फरक हाच संपूर्ण बग अहवाल आहे।

फ्लीट त्यांच्या प्रोव्हिजनिंग सिस्टमद्वारे हे क्लायंट धोरण स्वयंचलित करू शकतात, परंतु धोरण मालक असलेली स्वतंत्र वस्तू राहते। BIND 9 संदर्भ वर वापरलेले ऐकणे आणि क्वेरी नियंत्रण समाविष्ट करतो, आणि तुमच्या स्थापित आवृत्तीसाठी वर्तनाची पुष्टी करण्यासाठी योग्य ठिकाण तेच आहे।

पुढचे पाऊल: झोनची अनुक्रमांक वाढ आणि तपासणी आदेश तुमच्या बदल प्रक्रियेत जोडा, जेणेकरून कोणतेही रेकॉर्ड संपादन न तपासता उत्पादनापर्यंत पोहोचू शकणार नाही।