ویرایش resolv.conf مشکل DNS پس از قطع VPN را حل نمی‌کند

VPN را قطع می‌کنید، ping 1.1.1.1 هنوز پاسخ می‌دهد، و هر جست‌وجوی نام پیش از آنکه صفحه دست آخر تسلیم شود معلق می‌ماند. سپس cat /etc/resolv.conf یک کارساز نام نشان می‌دهد که هرگز فقط داخل تونل وجود داشته، معمولاً اول فهرست. پاک کردن آن خط ظاهراً حدود ده دقیقه درستش می‌کند، تا وقتی یک تعلیق، یک رومینگ Wi-Fi یا یک راه‌اندازی دوباره آن را برگرداند. فایلی که ویرایش کردید خودِ تنظیم نیست؛ بلکه نمایشی از وضعیت پیوند است که مالک آن مؤلفه دیگری است.

چرا یک ورودی کهنه برای هر جست‌وجو ثانیه‌ها هزینه دارد

ریزحل‌کننده glibc فهرست کارسازهای نام را به ترتیب می‌پیماید و پیش از امتحان کردن بعدی صبر می‌کند تا مهلتی تمام شود، و resolv.conf(5) این فهرست را به سه ورودی محدود می‌کند. یک ریزحل‌کننده سمت تونل مانند 10.8.0.1 را پس از رفتن تونل در بالای فهرست بگذارید و هر جست‌وجو پیش از رسیدن به کارسازی که پاسخ می‌دهد، هزینه مهلت را می‌پردازد. به همین دلیل نشانه شبیه اتصال مرده به نظر می‌رسد و نه خطای DNS: مرورگرها بلوکه می‌شوند، زمانشان تمام می‌شود و گاهی نشانی ذخیره‌شده‌ای را تحویل می‌دهند که بعداً کهنه می‌شود.

این همچنین توضیح می‌دهد چرا شکایت به شکل «اینترنت خراب است» می‌رسد. ping به یک نشانی IP ثابت می‌کند پیوند سالم است و همین باعث می‌شود خطا تقصیر برنامه به نظر برسد. فهرست ریزحل‌کننده نخستین چیزی است که باید خواند و آخرین چیزی که باید ویرایش کرد.

افسانه: resolv.conf یک فایل تنظیمات است

پیش از تغییر آن بپرسید این مسیر واقعاً چیست:

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

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

resolvectl status همان نمایی است که حقیقت را می‌گوید: کارسازهای DNS هر پیوند، دامنه‌های مسیریابی، و اینکه پیوند تونل هنوز وجود دارد یا نه. resolvectl query example.com جلوتر می‌رود و نشان می‌دهد کدام رابط پاسخ داده است. پیش از دست زدن به هر فایل هر دو را به کار ببرید، و در نظر داشته باشید مرورگری با DNS امن خودش همه اینها را نادیده می‌گیرد.

پیش از ویرایش هر چیز، مالک را پیدا کنید

معمولاً سه مؤلفه بر سر یک تنظیم رقابت می‌کنند: systemd-resolved، NetworkManager و آنچه کلاینت VPN نصب کرده است. نخست مؤلفه زنده را مشخص کنید:

systemctl is-active systemd-resolved
nmcli connection show --active
ps aux | grep -E "openvpn|wg-quick|vpn"

اگر resolved فعال است و پیوند نمادین به stub آن اشاره می‌کند، فایل سراسری خروجی تولیدشده است و ویرایش شما ظاهری است. اگر NetworkManager مالک اتصال است، کارسازها به نمایه اتصال تعلق دارند، پس اصلاح یک تغییر ویژگی با nmcli است نه ویرایش فایل. اگر دیمن فروشنده در حال اجراست، تنها مسیر بازیابی خودش از اتصال بعدی جان سالم به در می‌برد.

وضعیت پیوندی را که کلاینت جا گذاشته پاک کنید

کلاینت کشته‌شده نمی‌تواند قلاب پاک‌سازی خود را اجرا کند. SIGKILL اصلاً گرفته نمی‌شود، در حالی که SIGINT و SIGTERM گرفته می‌شوند، پس تونلی که پس از یک کشتن اجباری «فقط متوقف شد» اغلب هم ثبت رابط و هم ورودی ریزحل‌کننده را سر جای خود می‌گذارد. PID مشخص را پیدا کنید و سیگنال را فقط به همان بفرستید:

ps aux | grep -E "openvpn|wg-quick"
sudo kill <pid>
resolvectl revert tun0

پیش از خواندن فهرست کامل تطابق‌ها به سراغ pkill -f vpn یا killall vpn نروید. -f با کل خط فرمان تطبیق می‌دهد، پس می‌تواند یک اسکریپت پوششی، یک نشست ویرایشگر یا فرآیند نامرتبطی را که مسیرش آن رشته را دارد پایان دهد. پایان دادن به فرآیند اشتباه در میانه کار همان راهی است که یک مشکل ریزحل‌کننده به فایل گمشده تبدیل می‌شود.

resolvectl revert پیکربندی DNS زمان اجرای آن پیوند را بازنشانی می‌کند، که محدودتر از راه‌اندازی دوباره ریزحل‌کننده و بسیار محدودتر از ویرایش فایل سراسری است. اگر پیوند تونل کاملاً از میان رفته باشد، systemctl restart NetworkManager وضعیت اتصال را از نو می‌سازد و همان گامی است که رشته‌های منبع مدام به آن برمی‌گردند. مراقب مدیر سرویسی با Restart=always باشید، چون می‌تواند کلاینت کشته‌شده و تنظیمات DNS آن را مستقیم برگرداند.

جهت دیگر: DNS هل‌داده‌شده‌ای که هرگز نرسید

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

سپردن را با انجام دستی آن بیازمایید، که «کارساز غلط است» را از «هیچ‌کس آن را اعمال نکرد» جدا می‌کند:

resolvectl dns tun0 10.10.10.10
resolvectl domain tun0 ~.

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

nmcli connection modify office ipv4.ignore-auto-dns yes
nmcli connection modify office ipv4.dns 10.10.10.10
nmcli connection modify office ipv4.dns-search "~."

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

راه‌حل‌های موقت که به قطعی بعدی تبدیل می‌شوند

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

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

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