امنح شبكتك الخاصة الافتراضية سجلات DNS خاصة بها لـ nas.home.arpa
انشر اسمًا واحدًا من dnsmasq، ووجّه المُحلِّل عبر WireGuard، ثم اختر بين دفع DNS إلى العميل بأكمله أو DNS المنقسم لـ home.arpa فقط.
بعد أن يصبح النفق قائمًا، تكون الخطوة الأخيرة عادةً اسمًا يعمل بدلًا من عنوان تلصقه في إشارة مرجعية. سجل مضيف في dnsmasq مع عنوان مُحلِّل يستطيع العميل الوصول إليه يفعل ذلك بملفين ودون بث متعدد. القرار الذي يحتاج تفكيرًا فعلًا أضيق من ذلك: هل يرسل العميل كل DNS عبر مُحلِّل المنزل، أم الأسماء تحت home.arpa فقط؟ كل ما يلي يفترض إعداد WireGuard معتمدًا مع عميل Linux ومُحلِّل مختبر يديره مسؤول المنزل بالفعل.
ثلاث طرق لتسليم العميل مُحلِّلًا
| 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 |
لحاسوب محمول ينضم إلى النفق من وقت لآخر، يكون DNS المنقسم هو الافتراضي الأفضل: فهو يبقي أسماء الإنترنت العادية على المُحلِّل الذي تثق به الآلة بالفعل. ولآلة وُجدت للوصول إلى خدمات المنزل، يكون دفع المُحلِّل أبسط ولا تهم تكلفة النطاق.
انشر السجل عند المُحلِّل الذي يملك المنطقة
افصل الأدوار قبل كتابة الإعداد: عنوان عميل VPN والمُحلِّل والخدمة هي ثلاثة مضيفين مختلفين بثلاث مهام مختلفة. في هذا المختبر هي 10.77.0.2 للعميل، و192.168.50.53 لـ dnsmasq، و192.168.50.20 لـ NAS، مع توجيه النفق لشبكة المنزل المحلية.
listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20يوفر سطر host-record العنوان، ويُبقي سطر local= أسئلة home.arpa غير المعروفة داخل هذا المُحلِّل بدلًا من تمريرها إلى أعلى. اقرأ إعدادك الحالي أولًا ووفّق أي شيء يعرّف بالفعل خادمًا أو واجهة أو النطاق المحلي نفسه؛ فإضافة جزء فوق جزء متعارض تنتج مُحلِّلًا يُحمَّل بسلاسة ويجيب خطأً. ويحدد دليل dnsmasq التوجيهين وضوابط الاستماع.
ثم تحقق من الخدمة العاملة، لا من الملف. اختبار الإعداد مع إعادة تشغيل هو الحد الأدنى، والجواب الفعلي هو ما يعيده الاستعلام.
وجّه المُحلِّل، لا صفحة الويب فقط
يحدد AllowedIPs في WireGuard الوجهات التي تدخل النفق. وإذا وقع عنوان المُحلِّل خارجه، يغادر الاستعلام عبر المسار العادي ولا يصل إلى dnsmasq أبدًا، رغم أن NAS نفسه قابل للوصول. أدرج عنوان المُحلِّل، أو بادئة الشبكة المحلية التي تحتويه، وتحقّق من سياسة التمرير في البوابة على الطرف الآخر.
اسمح بـ UDP وTCP على المنفذ 53 من نطاق النفق المصرّح به، مع مسار عودة إلى عنوان نفق العميل. لا تمرّر المنفذ 53 من WAN لتسهيل الاختبار: فالمُحلِّل العودي المفتوح على اتصال منزلي يُكتشف خلال ساعات. والارتباط بواجهة ليس سياسة وصول بحد ذاته.
تحقق من الجواب قبل التطبيق
استعلم من المُحلِّل مباشرة أولًا، ثم اسأل النظام، ثم اسأل التطبيق. كل خطوة تعزل حلقة واحدة في السلسلة، والفرق بينها هو التشخيص.
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 ما يفعله إعداد المُحلِّل في الآلة فعلًا، وهو ليس دائمًا ما دفعته.
قرّر ما يحدث عندما يكون النفق متوقفًا
إذا كان DNS العام للعميل يشير إلى 192.168.50.53، يتوقف كل تحليل أسماء عن العمل عندما لا يكون النفق قائمًا. هذا مقبول على آلة لا تنفع إلا مع النفق، وغير مقبول على حاسوب محمول يستخدم أيضًا Wi-Fi المقهى. ويتجنب DNS المنقسم السؤال برمته، لأن عمليات البحث عن home.arpa وحدها تعتمد على مُحلِّل المنزل.
تذكّر ما هو الاسم: home.arpa محجوز للشبكات السكنية وليس فريدًا عالميًا، لذا يمكن لشبكة أخرى استخدام الاسم نفسه بشكل مشروع. إنه تسهيل محلي، وليس معرّفًا موثوقًا. أبقِ السجل محدثًا عندما تنتقل الخدمة، وأزل سياسة المُحلِّل عند إخراج المختبر من الخدمة بدلًا من ترك حاسوب محمول يشير إلى عنوان لا يمكنه الوصول إليه إلا عبر نفق لم يعد موجودًا.