अपने होम VPN को nas.home.arpa के लिए अपने DNS रिकॉर्ड दें
dnsmasq से एक नाम प्रकाशित करें, resolver को WireGuard से रूट करें, फिर पूरे क्लाइंट को DNS भेजने और केवल home.arpa के लिए split-DNS के बीच चुनें।
टनल ऊपर आने के बाद, अंतिम चरण आमतौर पर एक नाम होता है जो बुकमार्क में चिपकाए पते की जगह काम करता है। dnsmasq होस्ट रिकॉर्ड और एक resolver पता जहाँ तक क्लाइंट पहुँच सके, यह दो फ़ाइलों और बिना multicast के कर देते हैं। जिस निर्णय पर वास्तव में सोचना पड़ता है वह अधिक सँकरा है: क्लाइंट सारा DNS होम resolver से भेजता है, या केवल home.arpa के अंतर्गत नाम? नीचे सब कुछ Linux क्लाइंट और होम व्यवस्थापक द्वारा पहले से प्रबंधित लैब resolver वाले स्वीकृत WireGuard सेटअप को मानता है।
क्लाइंट को resolver देने के तीन तरीके
| Approach | Scope | Cost |
|---|---|---|
DNS = in the wg-quick interface | the client's general DNS while the tunnel is up | every name in the house now depends on the tunnel |
Platform split-DNS for home.arpa | only that suffix | more configuration per client platform |
Manual dig @resolver | one query at a time | fine for testing, useless for applications |
जो लैपटॉप कभी-कभी टनल में जुड़ता है, उसके लिए split-DNS बेहतर डिफ़ॉल्ट है: यह सामान्य इंटरनेट नामों को उस resolver पर रखता है जिस पर मशीन पहले से भरोसा करती है। जो मशीन घरेलू सेवाओं तक पहुँचने के लिए ही है, उसके लिए resolver भेजना सरल है और दायरे की कीमत मायने नहीं रखती।
रिकॉर्ड उस resolver पर प्रकाशित करें जो ज़ोन का मालिक है
कॉन्फ़िगरेशन लिखने से पहले भूमिकाएँ अलग रखें: VPN क्लाइंट पता, resolver और सेवा तीन अलग कामों वाले तीन अलग होस्ट हैं। इस लैब में वे क्लाइंट के लिए 10.77.0.2, dnsmasq के लिए 192.168.50.53 और NAS के लिए 192.168.50.20 हैं, और टनल घरेलू LAN को रूट करता है।
listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20host-record पंक्ति पता देती है और local= पंक्ति अज्ञात home.arpa प्रश्नों को ऊपर भेजने के बजाय इस resolver के भीतर रखती है। पहले अपना मौजूदा कॉन्फ़िगरेशन पढ़ें और जो पहले से सर्वर, इंटरफ़ेस या वही स्थानीय डोमेन परिभाषित करता है उसे मिलाएँ; विरोधाभासी टुकड़े पर टुकड़ा चढ़ाने से ऐसा resolver बनता है जो खुशी से लोड होता है और गलत उत्तर देता है। dnsmasq मैनुअल दोनों निर्देशों और सुनने के नियंत्रणों को परिभाषित करता है।
फिर फ़ाइल नहीं, चल रही सेवा जाँचें। कॉन्फ़िगरेशन परीक्षण और पुनःआरंभ न्यूनतम है, और प्रभावी उत्तर वही है जो क्वेरी लौटाती है।
resolver को रूट करें, केवल वेब पेज को नहीं
WireGuard का AllowedIPs तय करता है कि कौन-से गंतव्य टनल में प्रवेश करते हैं। यदि resolver का पता उससे बाहर पड़ता है, तो क्वेरी सामान्य मार्ग से निकल जाती है और dnsmasq तक कभी नहीं पहुँचती, भले ही NAS स्वयं पहुँच योग्य हो। resolver का पता या उसे समाहित करने वाला LAN प्रीफ़िक्स शामिल करें, और दूसरी ओर गेटवे की फ़ॉरवर्डिंग नीति जाँचें।
अधिकृत टनल श्रेणी से पोर्ट 53 पर UDP और TCP की अनुमति दें, क्लाइंट के टनल पते तक वापसी मार्ग के साथ। परीक्षण आसान बनाने के लिए WAN से पोर्ट 53 फ़ॉरवर्ड न करें: घरेलू कनेक्शन पर खुला रिकर्सिव resolver घंटों में मिल जाता है। किसी इंटरफ़ेस से बँधना अपने आप में कोई एक्सेस नीति नहीं है।
एप्लिकेशन से पहले उत्तर जाँचें
पहले सीधे resolver से पूछें, फिर सिस्टम से, फिर एप्लिकेशन से। हर चरण शृंखला की एक कड़ी अलग करता है, और उनके बीच का अंतर ही निदान है।
dig @192.168.50.53 nas.home.arpa. A
dig +tcp @192.168.50.53 nas.home.arpa. A
getent ahostsv4 nas.home.arpa
curl -sS --max-time 5 http://nas.home.arpa/ -o /dev/null -w '%{http_code}\n'TCP क्वेरी चलाना उचित है, क्योंकि कटा हुआ UDP उत्तर पुनः प्रयास के लिए बाध्य करता है, और TCP 53 गिराने वाली नीति ऐसी विफलताएँ पैदा करती है जो रुक-रुक कर दिखती हैं। getent चरण दिखाता है कि मशीन का resolver कॉन्फ़िगरेशन वास्तव में क्या करता है, जो हमेशा वही नहीं होता जो आपने भेजा।
तय करें कि टनल बंद होने पर क्या होता है
यदि क्लाइंट का सामान्य DNS 192.168.50.53 की ओर इंगित करता है, तो टनल ऊपर न होने पर हर नाम विश्लेषण काम करना बंद कर देता है। यह ऐसी मशीन पर स्वीकार्य है जो केवल टनल के साथ उपयोगी है, और ऐसे लैपटॉप पर अस्वीकार्य है जो कैफ़े का Wi-Fi भी उपयोग करता है। Split-DNS प्रश्न को पूरी तरह टाल देता है, क्योंकि केवल home.arpa लुकअप होम resolver पर निर्भर हैं।
याद रखें कि नाम क्या है: home.arpa आवासीय नेटवर्क के लिए आरक्षित है और वैश्विक रूप से अद्वितीय नहीं है, इसलिए कोई दूसरा नेटवर्क वैध रूप से वही नाम उपयोग कर सकता है। यह स्थानीय सुविधा है, विश्वसनीय पहचानकर्ता नहीं। सेवा के स्थानांतरित होने पर रिकॉर्ड अद्यतन रखें, और लैब के सेवानिवृत्त होने पर resolver नीति हटा दें, ऐसे लैपटॉप को छोड़ने के बजाय जो ऐसे पते की ओर इंगित करता है जहाँ वह केवल उस टनल से पहुँच सकता है जो अब मौजूद नहीं है।