کدام پیوند پاسخ می‌دهد: دامنه‌های مسیریابی برای DNS در VPN با تونل تقسیم‌شده

مرور معمولی را روی پیوند محلی نگه دارید، در حالی که نام‌های شرکت از طریق سرور DNSی که تونل فراهم می‌کند حل می‌شوند. خاموش‌کردن مسیر پیش‌فرض VPN نیمهٔ اول را به شما می‌دهد و نیمهٔ دوم را ساخته‌نشده باقی می‌گذارد. آنچه در ادامه می‌آید تنظیم گمشده، نشانه‌ای که معنای آن را تغییر می‌دهد، و تنها فرمانی است که نشان می‌دهد کدام پیوند واقعاً پاسخ داده است. در سراسر متن NetworkManager و systemd-resolved فرض شده‌اند، چون همین جفت جایی است که سردرگمی معمولاً آغاز می‌شود.

گام یک: مسیر را از حل‌کننده جدا کنید

ipv4.never-default به پرسش مسیریابی پاسخ می‌دهد و مانع می‌شود NetworkManager این اتصال را به‌عنوان مسیر همهٔ ترافیک IPv4 نصب کند. دامنهٔ مسیریابی DNS به پرسش دیگری پاسخ می‌دهد: سرورهای نام کدام پیوند درخواستی برای پسوند منطبق دریافت می‌کنند. هیچ‌کدام دیگری را ایجاب نمی‌کند، و یک پروفایل می‌تواند سال‌ها یکی را داشته باشد در حالی که دیگری غایب است. فقط‌مسیر یعنی تونل زیرشبکه‌های شرکت را حمل می‌کند و حل‌کنندهٔ آن به نام‌های شرکت پاسخ می‌دهد، در حالی که همه‌چیز دیگر دست‌نخورده می‌ماند.

فقط ویژگی مسیر را تنظیم کنید و نام‌های داخلی شکست می‌خورند، معمولاً با یک مهلت که مانند تونل خراب به نظر می‌رسد. فقط دامنه را تنظیم کنید و بی‌صدا یک پسوند جست‌وجو به هر نام کوتاه روی دستگاه افزوده‌اید. هر دو خطا تیکت را به سرور VPN می‌فرستند، که به‌ندرت بخش اشتباه است.

گام دو: دامنهٔ فقط‌مسیریابی را به پروفایل اضافه کنید

فرض کنید اتصال corp-vpn نام دارد، پسوند شرکت internal.example است، و حل‌کنندهٔ تونل از قبل در دسترس است. ابتدا مقادیر کنونی را بخوانید، چون فرمان‌های زیر ویژگی‌هایی را تغییر می‌دهند که ممکن است از قبل ورودی داشته باشند.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

نام اتصال و پسوند خودتان را جایگزین کنید، چون مقادیر بالا نمونه‌اند. علامت به‌علاوه مهم‌تر از آن است که به نظر می‌رسد: با آن مقدار به فهرست موجود افزوده می‌شود، و بدون آن ویژگی جایگزین می‌شود و دامنه‌های نامرتبط از پروفایلی که دیروز کار می‌کرد ناپدید می‌شوند. تیلدا رفتار را تغییر می‌دهد نه سبک را، و بند زیر توضیح می‌دهد که چه چیزی را انتخاب می‌کند. خواندن را پیش از نوشتن نگه دارید تا شکل جایگزینی هرگز غافلگیرتان نکند.

تیلدای ابتدایی یک دامنهٔ فقط‌مسیریابی را علامت می‌زند، بنابراین درخواست‌های منطبق به سرورهای این پیوند می‌روند و پسوند به نام‌های کوتاه افزوده نمی‌شود. تیلدا را بردارید و همان رشته به پسوند جست‌وجو هم تبدیل می‌شود، که نتیجهٔ متفاوتی است و مردم به‌ندرت آن را می‌خواهند. هر دو تنظیم بالا IPv4 هستند، پس پروفایل دوپشته به ipv6.never-default و همان دامنهٔ مسیریابی در ipv6.dns-search نیاز دارد، وگرنه سمت IPv6 همچنان از مسیر پیش‌فرض استفاده می‌کند و نام‌های داخلی آنجا شکست می‌خورند.

گام سه: از resolvectl بپرسید کدام پیوند پاسخ داد

resolvectl status را اجرا کنید و سرورهای DNS و دامنه‌های هر پیوند را بخوانید، سپس resolvectl query host.internal.example را علیه یک نام داخلی واقعی که اجازهٔ پرس‌وجو دربارهٔ آن را دارید اجرا کنید. فرمان دوم تنها شاهد مستقیم است که دامنهٔ مسیریابی کارش را می‌کند، چون پیوندی را که پاسخ داده نام می‌برد. فهرست وضعیت به‌تنهایی پیکربندی را اثبات می‌کند؛ پرس‌وجو حل‌شدن را اثبات می‌کند.

systemd-resolved بهترین دامنهٔ مسیریابی منطبق را انتخاب می‌کند، پس دامنهٔ مشخص‌تر روی پیوند دیگر می‌تواند هنوز در مسابقه برنده شود. اگر پرس‌وجو از پیوندی برگشت که انتظارش را نداشتید، پیش از دست‌زدن به سرور DNS مربوط به VPN فهرست‌های دامنه را بخوانید. دامنهٔ ریشهٔ ~. با همه‌چیز منطبق می‌شود، و اگر از قبل حاضر باشد دامنهٔ مشخص شما برای نام‌های خودش همچنان برنده می‌شود در حالی که پیوند به بسیار بیشتر از آنچه پرسیدید پاسخ می‌دهد. وقتی قصد فقط نام‌های شرکت بود، آن ورودی ریشه را حذف یا باریک‌تر کنید.

اگر پیوند VPN اصلاً هیچ سرور DNS فهرست نکند، کلاینت هرگز یکی ثبت نکرده است. دامنهٔ مسیریابی بدون سرور پشت آن به‌گونه‌ای متفاوت از دامنهٔ غایب شکست می‌خورد، پس ابتدا ثبت را درست کنید.

گام چهار: وقتی نام حل می‌شود اما سرویس نه

پاسخ درست فقط ثابت می‌کند که حل‌شدن کار کرده است، و برنامه هنوز به مسیری به نشانی دریافتی نیاز دارد. آن مسیر باید از مسیر پیش‌فرض تقسیم‌شده‌ای که همین حالا پیکربندی کردید جان سالم به در ببرد، پس پیش از سرزنش دوبارهٔ DNS آن را بررسی کنید. سپس دسترسی‌پذیری روی درگاه سرویس را بررسی کنید، چون اشتراک فایل یا سرویس دایرکتوری در حل‌شدن، مسیریابی یا احراز هویت شکست می‌خورد و در هر حالت پیام‌های بسیار مشابهی تولید می‌کند. هنگام گزارش نتیجه این سه لایه را جدا نگه دارید، وگرنه نفر بعدی DNSی را دوباره بررسی می‌کند که از قبل درست بود.

تغییر Samba که در کنار این پرسش می‌چرخد لایهٔ دسترسی را هدف می‌گیرد، نه انتخاب DNS را. اعمال آن بر یک نقص حل نام همان راهی است که یک مشکل کوچک مشکل دومی پیدا می‌کند.

گام پنج: حل‌کننده را برای رفع یک دامنهٔ گمشده جایگزین نکنید

توصیه‌ای که فایل حل‌کننده را بازنویسی می‌کند یا مدیر حل‌کنندهٔ دیگری نصب می‌کند، مشکل دیگری را حل می‌کند. این‌ها تغییرات یکپارچه‌سازی سیستم با حالت‌های شکست خودشان هستند، و هیچ‌کدام دامنهٔ مسیریابی‌ای را که هرگز پیکربندی نشده اضافه نمی‌کنند. پیش از جایگزینی مشخص کنید کدام مؤلفه مالک حل نام روی دستگاه است، چون روی دسکتاپ NetworkManager همراه systemd-resolved این مالکیت از قبل تعریف شده است. جنگیدن با آن همان راهی است که یک چیدمان کارآمد به چیزی تبدیل می‌شود که هیچ‌کس نمی‌تواند بازتولیدش کند.

ترتیب کار: تأیید کنید که تونل یک حل‌کننده فراهم می‌کند، دامنهٔ فقط‌مسیریابی را اضافه کنید، از طریق کنترل‌های پروفایل دوباره وصل شوید، پیوند پاسخ‌دهنده را بررسی کنید، و سپس سرویس را روی درگاهش بیازمایید. این توالی نتیجه‌ای باقی می‌گذارد که می‌توانید بدون گفت‌وگوی دوم به نفر بعدی تحویل دهید.