तुमच्या होम 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 धोरण काढून टाका, आता अस्तित्वात नसलेल्या टनेलमधूनच पोहोचता येणाऱ्या पत्त्याकडे निर्देश करणारा लॅपटॉप सोडण्याऐवजी.