به VPN خانگی خود رکوردهای DNS اختصاصی برای nas.home.arpa بدهید
یک نام را از dnsmasq منتشر کنید، resolver را از طریق WireGuard مسیریابی کنید، سپس بین فرستادن DNS به کل کلاینت و split-DNS تنها برای home.arpa یکی را انتخاب کنید.
وقتی تونل بالا باشد، آخرین گام معمولاً نامی است که کار می‌کند، به‌جای نشانی که در یک نشانک می‌چسبانید. یک رکورد میزبان dnsmasq به‌همراه نشانی resolver که کلاینت به آن دسترسی دارد، این کار را با دو فایل و بدون multicast انجام می‌دهد. تصمیمی که واقعاً نیاز به فکر دارد باریک‌تر است: آیا کلاینت همهٔ DNS را از resolver خانه می‌فرستد یا فقط نام‌های زیر home.arpa؟ همهٔ موارد زیر یک راه‌اندازی تأییدشدهٔ WireGuard با کلاینت Linux و یک resolver آزمایشگاهی را فرض می‌کند که مدیر خانه از قبل آن را اداره می‌کند.
سه راه برای دادن یک 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 برای کلاینت، 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 را داخل همین resolver نگه می‌دارد، به‌جای آنکه آن‌ها را به بالادست بفرستد. نخست پیکربندی موجود خود را بخوانید و هر چیزی را که از قبل یک سرور، یک رابط یا همان دامنهٔ محلی را تعریف می‌کند هم‌ساز کنید؛ انباشتن یک قطعه روی قطعه‌ای ناسازگار resolverی می‌سازد که با خوشی بارگذاری می‌شود و اشتباه پاسخ می‌دهد. راهنمای dnsmasq هر دو دستور و کنترل‌های شنود را تعریف می‌کند.
سپس سرویس در حال اجرا را بررسی کنید، نه پرونده را. یک آزمون پیکربندی به‌همراه راه‌اندازی مجدد حداقل است و پاسخ مؤثر همان چیزی است که یک پرس‌وجو برمی‌گرداند.
resolver را مسیریابی کنید، نه فقط صفحهٔ وب را
AllowedIPs در WireGuard تعیین می‌کند کدام مقاصد وارد تونل می‌شوند. اگر نشانی resolver بیرون از آن بیفتد، پرس‌وجو از مسیر عادی خارج می‌شود و هرگز به dnsmasq نمی‌رسد، هرچند خود NAS در دسترس است. نشانی resolver یا پیشوند LAN که آن را در بر دارد وارد کنید و سیاست ارسال دروازه را در سمت مقابل بررسی کنید.
UDP و TCP روی درگاه 53 را از محدودهٔ مجاز تونل اجازه دهید، با مسیر بازگشت به نشانی تونل کلاینت. درگاه 53 را از WAN به‌خاطر آسان‌تر کردن آزمون هدایت نکنید: 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 اشاره کند، هر resolve نامی وقتی تونل بالا نیست از کار می‌افتد. این روی دستگاهی که فقط با تونل سودمند است پذیرفتنی است و روی لپ‌تاپی که از Wi-Fi کافه هم استفاده می‌کند پذیرفتنی نیست. split-DNS پرسش را کاملاً دور می‌زند، چون فقط جست‌وجوهای home.arpa به resolver خانه وابسته‌اند.
یادتان باشد این نام چیست: home.arpa برای شبکه‌های مسکونی رزرو شده و در سطح جهانی یگانه نیست، پس شبکهٔ دیگری می‌تواند به‌طور مشروع از همان نام استفاده کند. این یک راحتی محلی است، نه شناسه‌ای قابل اعتماد. وقتی سرویس جابه‌جا می‌شود رکورد را به‌روز نگه دارید و وقتی آزمایشگاه بازنشسته می‌شود سیاست resolver را بردارید، به‌جای آنکه لپ‌تاپی را رها کنید که به نشانی‌ای اشاره می‌کند که تنها از طریق تونلی می‌تواند به آن برسد که دیگر وجود ندارد.