WireGuard درخواست DNS ارسال نمی‌کند: سرویس‌دهی به یک ناحیه خصوصی BIND

WireGuard را بالا آورده‌اید، تونل ترافیک را عبور می‌دهد، و نام داخلی هنوز حل نمی‌شود. گام بعدی معمولاً جست‌وجوی یک تنظیم DNS در پیکربندی WireGuard است، گویی یک peer می‌تواند resolver را مانند برخی VPNهای دیگر هل بدهد. نمی‌تواند. دست‌دادن کلیدها، نشانی‌های واسط و IPهای مجاز را حمل می‌کند و هیچ فیلدی برای سرورهای DNS یا دامنه‌های جست‌وجو ندارد. خط‌مشی resolver روی کلاینت زندگی می‌کند، و اصلاح همان‌جاست.

تونل و resolver دو قرارداد جداگانه‌اند

WireGuard عمداً کوچک است. بسته‌ها را برای نشانی‌هایی که فهرست می‌کنید جابه‌جا می‌کند و peerها را احراز هویت می‌کند؛ هر چیزی بالاتر از این لایه طراحی شماست. OpenVPN می‌تواند یک dhcp-option DNS را هل بدهد چون کانال کنترلش پیکربندی را حمل می‌کند، و همین تفاوت کسانی را که بین این دو جابه‌جا می‌شوند به اشتباه می‌اندازد.

بنابراین یک تونل کارآمد هیچ چیزی درباره حل نام به شما نمی‌گوید. کلاینت می‌تواند مسیری بی‌عیب به 10.90.0.1 داشته باشد و باز هم پرس‌وجوهایش را به یک resolver عمومی بفرستد، و به همین دلیل نشانه شبیه «VPN فلان DNS را خراب کرد» به نظر می‌رسد، در حالی که DNS هرگز به سمت VPN نشانه نرفته بود.

ناحیه را بدون تبدیل شدن به resolver بازگشتی سرویس بدهید

سمت سرور یک ناحیه معتبر کوچک است، نه یک resolver عمومی. در این نمونه دروازه 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 همان resolver است. ابتدا خط‌مشی موجود را بخوانید، به‌ویژه هر دامنه مسیریابی ریشه، چون یک ورودی ~. از آنچه می‌خواهید اضافه کنید پیشی می‌گیرد.

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 است، نه پرونده ناحیه. از کلاینت به بیرون کار کنید، چون سرور نمی‌تواند به شما بگوید چرا یک پرس‌وجو هرگز نرسیده.

یادتان باشد که برنامه هنوز به مسیر خودش و مجوز سرویس خودش نیاز دارد. نامی که حل شده و به نشانی دسترس‌ناپذیر اشاره می‌کند، شکستی دیگر با همان لباس است.

چه چیزی هنوز خودکار نیست

برنامه‌هایی که منطق resolver خودشان را دارند، resolver سیستم را کاملاً نادیده می‌گیرند، و هیچ مقدار nmcli این را تغییر نمی‌دهد. استقرارهایی که DNSSEC را اعتبارسنجی می‌کنند به طراحی صریح لنگر اعتماد برای ناحیه خصوصی نیاز دارند؛ پاسخ یک دستور کلی برای خاموش کردن اعتبارسنجی نیست. با همان نرم‌افزار کلاینتی که کاربرانتان اجرا می‌کنند آزمایش کنید، نه با ابزاری که تصادفاً از resolver سیستم استفاده می‌کند. شکاف میان این دو همان کل گزارش خرابی است.

ناوگان‌ها می‌توانند این خط‌مشی کلاینت را از طریق سامانه تأمین خود خودکار کنند، اما خط‌مشی یک شیء جداگانه با مالک می‌ماند. مرجع BIND 9 کنترل‌های شنود و پرس‌وجوی به‌کاررفته در بالا را پوشش می‌دهد، و جای درستی است برای تأیید رفتار برای نسخه نصب‌شده شما.

گام بعدی: افزایش شماره سریال ناحیه و فرمان‌های بررسی را به رویه تغییرات خود اضافه کنید، تا ویرایش یک رکورد نتواند بدون بررسی به تولید برسد.