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 संदर्भ ऊपर प्रयुक्त सुनने और क्वेरी नियंत्रणों को समाहित करता है, और आपके स्थापित संस्करण के लिए व्यवहार की पुष्टि करने का यही सही स्थान है।

अगला कदम: ज़ोन की सीरियल वृद्धि और जाँच कमांड अपनी परिवर्तन प्रक्रिया में जोड़ें, ताकि कोई रिकॉर्ड संपादन बिना जाँचे उत्पादन तक न पहुँच सके।