جلوی رقابت دو سرویس لینوکس بر سر /etc/resolv.conf را بگیرید

DNS مدام به حالت قبل برمی‌گردد، اتصال دوباره VPN اصلاح شما را باطل می‌کند، و در نهایت کسی در تیم پیشنهاد می‌کند فایل را قفل کنید. این توالی یک نشانه است، نه راه‌حل: دو مؤلفه هر دو گمان می‌کنند مالک /etc/resolv.conf هستند، و آن‌که آخر می‌نویسد برنده است. قفل کردن فایل تعارض مالکیت را حل نمی‌کند، فقط آن را پنهان می‌کند و در همان حال مؤلفه‌ای را که واقعاً می‌خواستید می‌شکند. چهار بررسی زیر را به ترتیب انجام دهید و ترتیب را در سطحی که مالک آن است اصلاح کنید، نه روی فایل.

بررسی 1: آیا پیوند نمادین است، و به چه چیزی

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

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

پیوند به مسیر stub در systemd-resolved یعنی محتوای فایل تولید می‌شود، و ویرایش دستی در رویداد بعدی بازنویسی خواهد شد. فایل ساده‌ای با خطوط nameserver را معمولاً همان کارخواه یا قلاب DHCP می‌نویسد که هنگام اتصال اجرا می‌شود. هر دو مشروع‌اند؛ مهم این است که پیش از تغییر هر چیزی بدانید کدام را دارید.

بررسی 2: کدام دیمن اجرا می‌شود

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

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

خروجی وضعیت سرورهای DNS هر پیوند و دامنه‌های مسیریابی را نام می‌برد، که همان نقشه‌ای است که برای split DNS لازم دارید. اگر نام‌های داخلی باید به یک سرور داخلی بروند و بقیه به یک سرور عمومی، آن سیاست در دامنه‌های هر پیوند زندگی می‌کند، و تخت کردن آن در فهرست ثابت nameserver داخل فایل، این تمایز را بی‌صدا از دست می‌دهد.

پیکربندی خود NetworkManager تعیین می‌کند کدام‌یک از این backendها را استفاده می‌کند. تنظیم dns= آن در فایل پیکربندی اصلی بین حل‌کننده داخلی خودش، dnsmasq، systemd-resolved و none یکی را انتخاب می‌کند، و ممکن است توزیع به‌جای شما انتخاب کرده باشد. پیش از تصمیم درباره معنای «تعمیر DNS» روی این میزبان، آن تنظیم را بخوانید.

بررسی 3: کارخواه VPN اجازه نوشتن چه چیزی را دارد

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

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

قلاب‌های بالا و پایین کارخواه را بخوانید، نه حدس بزنید. چند خط shell در /etc/openvpn/up.sh یا پوشه‌ای معادل رفتاری را توضیح می‌دهد که در غیر این صورت تصادفی به نظر می‌رسد، و همان‌جا نقطه‌ای است که می‌توانید کارخواه را به همکاری به‌جای رقابت وادار کنید.

بررسی 4: آن را نزد مالک اصلاح کنید، نه در فایل

وقتی مالک را شناختید، DNS را از طریق رابط پشتیبانی‌شده همان مالک پیکربندی کنید. برای systemd-resolved این یعنی تنظیمات هر پیوند و دامنه‌های مسیریابی به‌جای فایل ثابت؛ برای NetworkManager یعنی تنظیمات DNS پروفایل اتصال و backend انتخاب‌شده؛ برای توزیعی با یکپارچگی resolvconf یعنی نوشتن از طریق همان کمک‌کننده.

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

آن‌جا که دو مؤلفه واقعاً باید همزیستی کنند، کارهای متفاوت به آن‌ها بدهید. بگذارید مدیر شبکه مالک پیکربندی سطح رابط باشد، بگذارید کارخواه VPN از طریق همان یکپارچگی DNS و دامنه‌های هر پیوند را فراهم کند، و اسکریپت سومی را که فایل را مستقیم می‌نویسد حذف کنید. مستندات systemd-resolved حالت‌هایی را که پشتیبانی می‌کند و آنچه هر یک در /etc/resolv.conf آشکار می‌کند توضیح می‌دهد. حالتی را انتخاب کنید که با میزان سیاستی که باید نگه دارید سازگار است. اگر split DNS مهم است، چیدمان stub با دامنه‌های هر پیوند آن را حفظ می‌کند، در حالی که حالتی که سرورهای بالادست را در فایل کپی می‌کند بی‌صدا آن را تخت می‌کند.

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

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

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

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

مالک، backend و حالت پیوند نمادین را در یادداشت‌های استقرار ثبت کنید. همان یک پاراگراف ارتقای بسته در آینده را از یک حادثه به یک مورد بازبینی تبدیل می‌کند، و مانع می‌شود نفر بعدی همان تعارض را با فرمان chattr دوباره کشف کند.