DNS شبکه خصوصی هر جست‌وجو را می‌گیرد: dns-priority را در NetworkManager اصلاح کنید

به VPN دفتر وصل شوید و ناگهان هر جست‌وجوی نام به resolver شرکت می‌رود. نام‌های عمومی همچنان حل می‌شوند، پس هیچ چیز خراب به نظر نمی‌رسد تا وقتی نام یک چاپگر محلی شکست بخورد یا یک رکورد split-horizon آدرس دفتر را برگرداند. در بعضی نصب‌های Fedora عکس این اتفاق می‌افتد: resolver ارائه‌دهنده پس از بالا آمدن تونل هم پاسخ می‌دهد. هر دو یک پرسش است — کدام resolver مالک این پرسش است — و در سیستم‌های NetworkManager پاسخ در ویژگی‌های DNS هر اتصال زندگی می‌کند.

دو اتصال، یک resolver برنده

هر اتصال یک اولویت DNS اعلام می‌کند. اتصال‌های معمولی به‌طور پیش‌فرض 50 دارند و اتصال‌های VPN مقدار 0، و مقدار کمتر برنده می‌شود. همین پیش‌فرض دلیل آن است که اتصال VPN بی‌صدا از پیوند سیمی برای هر دامنه‌ای که ادعا می‌کند جلو می‌زند: صفر بدون اینکه کسی آن را انتخاب کرده باشد از پنجاه پیش می‌افتد.

اولویت نامزدها را مرتب می‌کند. محدود نمی‌کند که از برنده درباره چه چیزی پرسیده شود. اتصال VPN بدون دامنه جست‌وجو همه چیز را ادعا می‌کند، بنابراین ترجیح دادنش پرسش‌های عمومی را هم به تونل می‌فرستد و در طراحی تونل تقسیم‌شده به همان جایی که resolver شرکت هدایت می‌کند.

اولویت ترتیب را تعیین می‌کند، فهرست جست‌وجو مالکیت را

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

فهرست جست‌وجو بیانیه مالکیت است. دامنه لخت مانند corp.example به پسوند جست‌وجو و دامنه مسیریابی تبدیل می‌شود. شکل فقط مسیریابی ~corp.example جست‌وجوهای زیر آن پسوند را بدون افزودن دامنه به نام‌های کوتاه به این اتصال می‌فرستد. همان تیلدا تفاوت میان «از این سرور بپرس» و «از این سرور بپرس و تایپ من را تمام کن» است.

هر دو شکل را استفاده کنید وقتی کاربران نام میزبان کوتاه تایپ می‌کنند و رکوردها با نام‌های کاملاً واجد هم نشانی می‌شوند. فقط شکل مسیریابی را استفاده کنید وقتی تقسیم را می‌خواهید بدون تغییر اینکه resolver چگونه یک نام لخت را کامل می‌کند.

سپس ترجیح را صریح کنید و دوباره فعال کنید:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

اولویت منفی روش مستند برای گفتن «این اتصال را ترجیح بده» است، و تنظیم هر دو خانواده نشانی رفتار را روی میزبان دارای اتصال IPv6 یکدست نگه می‌دارد. تغییر ویژگی بدون فعال‌سازی دوباره اتصال هیچ چیزی از آنچه اکنون در حال اجراست را تغییر نمی‌دهد، به همین دلیل دنباله با یک up صریح پایان می‌یابد.

بگذارید systemd-resolved تقسیم را نگه دارد

افزونه پیش‌فرض dnsmasq پرسش‌ها را به یک resolver محلی سرازیر می‌کند، پس جداسازی به‌ازای هر پیوند درشت می‌ماند. systemd-resolved تقسیم را به‌ازای هر پیوند آشکار می‌کند، و resolvectl query نام پیوندی را می‌گوید که پاسخ داده است.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

بعد از آن پیوند شرکت corp.example را حمل می‌کند و یک resolver عمومی بقیه را سرو می‌کند. وقتی پرسشی به پیوند اشتباه می‌رسد، فرمان نام پیوندی را می‌گوید که به آن پاسخ داده است، و دانستن این بهتر از دانستن تنها نشانی است.

طراحی DNS را با نوع تونل هماهنگ کنید

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

سپس kill switch هست که DNS بیرون تونل را مسدود می‌کند. نام‌ها برای مناطق تونل حل می‌شوند و در همه جای دیگر شکست می‌خورند در حالی که اتصال کاملاً سالم است. پاسخ‌های عملی یک اجازه صریح برای resolver شبکه محلی است یا یک کش محلی که فقط منطقه شرکت را هدایت می‌کند، و هر کدام استثنایی با مالک است نه نقصی در تونل.

پروفایلی که هنگام بالا آمدن رابط، پیکربندی resolver را بازنویسی می‌کند تقریباً همین‌گونه رفتار می‌کند: وقتی resolver محلی در دسترس نباشد، فقط نام‌هایی حل می‌شوند که تونل می‌شناسد. هر مکانیزمی که اعمال شود، بنویسید کدام نام‌ها باید در هر وضعیت کار کنند و آن فهرست را به کسی بدهید که گزارش‌ها را بررسی می‌کند.

به‌ازای هر پیوند بررسی کنید، سپس پس از اتصال دوباره بازبینی کنید

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

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