resolv.conf در WSL 2: DNS وقتی VPN وصل می‌شود از کار می‌افتد

مرور درون توزیع کار می‌کند، و نخستین نام میزبان داخلی همان لحظه‌ای که تونل بالا می‌آید شکست می‌خورد. واکنش طبیعی افزودن یک resolver عمومی است که اینترنت را برمی‌گرداند و نام شرکتی را برای باقی روز دسترس‌ناپذیر می‌کند. در WSL 2، /etc/resolv.conf خروجی تولیدشده است نه پیکربندی، و همین سازوکار ارزش فهمیدن دارد. راه‌حل resolver بهتر نیست، مالکیت فایل است.

فایل تولید می‌شود، نه پیکربندی

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

شکل دوم خرابی آرام‌تر است: WSL ممکن است سرورها را فقط از برخی آداپتورها کپی کند. اگر آداپتور فیزیکی از قبل resolver IPv6 داشته باشد، سرورهای IPv4 که آداپتور VPN تأمین می‌کند ممکن است به‌جای افزوده‌شدن حذف شوند، و فایل کامل به نظر می‌رسد در حالی که دقیقاً همان سروری را که به نام‌های داخلی پاسخ می‌دهد جا می‌اندازد.

نمای ویندوز را با نمای لینوکس مقایسه کنید

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

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

Get-DnsClientServerAddress -AddressFamily IPv4
Get-NetAdapter | Where-Object Status -eq 'Up'

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

تولید را خاموش کنید و فایل خودتان را بنویسید

یک تنظیم مستندشده جلوی بازنویسی فایل توسط WSL را می‌گیرد و در /etc/wsl.conf قرار دارد. یک بخش شبکه به آن فایل بیفزایید:

[network]
generateResolvConf = false

سپس توزیع را از ویندوز با wsl --shutdown پایان دهید و دوباره راه‌اندازی کنید. اگر مسیر پیوند نمادین باشد و نه فایل عادی، پیش از نوشتن محتوای خودتان پیوند را حذف کنید، زیرا نوشتن از طریق پیوند می‌تواند هدف تولیدشده را در راه‌اندازی بعدی بازسازی کند. از آن لحظه فایل از آنِ شماست و چیزی آن را بازنویسی نمی‌کند.

nameserver 172.28.4.10
nameserver 172.28.4.11
search site.corp.example
options timeout:1 attempts:2 rotate

بدون دامنه جست‌وجو، نام میزبان غیرکامل با ریشه عمومی تکمیل می‌شود و به‌صورت «چنین دامنه‌ای وجود ندارد» برمی‌گردد. timeout جلوی سرور نخست مرده را می‌گیرد که هر جست‌وجو را معطل کند، attempts محدود می‌کند که یک جست‌وجو چند تلاش صرف کند، و rotate تلاش‌های دوباره را پخش می‌کند به‌جای اینکه همیشه از بالا شروع شود. معامله این است که فایل دیگر از VPNی که نشانی resolver آن بین نشست‌ها تغییر می‌کند پیروی نمی‌کند.

با resolver جابه‌جاشونده برخورد کنید، سپس بررسی

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

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

با نام آزمایش کنید نه با بسته: getent hosts sensor-access0.corp.example از پشته resolver می‌گذرد، در حالی که ping ممکن است علیه نشانی ذخیره‌شده یا تحت‌اللفظی موفق شود. سپس پس از قطع و اتصال دوباره تکرار کنید، زیرا تنظیمی که یک بار کار می‌کند و هنگام ازسرگیری بازتولید می‌شود هرگز درست نشده است. محتوای پیشین را ذخیره کنید و بنویسید کدام مؤلفه مالک مسیر روی آن ماشین است، تا تغییر بعدی با شواهد آغاز شود.