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

چرا توزیع resolver خودش را نگه می‌دارد

کلاینت DNS ویندوز درون توزیع استفاده نمی‌شود. WSL2 هنگام راه‌اندازی فایل resolver خودش را می‌سازد که به یک آدرس stub اشاره می‌کند که ویندوز آن را روی سوئیچ مجازی برای ماشین مجازی کمکی منتشر می‌کند.

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

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

نخست از هر دو سو شواهد جمع کنید

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

درون توزیع، فایل resolver، جدول مسیریابی و یک جست‌وجوی داخلی و یک جست‌وجوی عمومی را چاپ کنید:

ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.com

در ویندوز، سرورهای DNS هر آداپتور و جدول IPv4 را با متریک‌ها فهرست کنید. کلاینت VPN معمولاً مسیری برای زیرشبکه WSL2 نصب می‌کند و متریک آن تعیین می‌کند که این ترافیک از تونل بیرون برود یا محلی بماند.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

متریک مسیر یا فایل کهنه

نخستین خرابی فایل کهنه است. resolver برای وضعیت آداپتور در زمان راه‌اندازی نوشته شده بود و تونل آن وضعیت را تغییر داد. آدرس stub آن اکنون ممکن است دسترسی‌ناپذیر باشد، یا سروری را نام ببرد که هیچ از ناحیه داخلی نمی‌داند.

دومی یک مشکل مسیریابی است. وقتی VPN مسیری را اضافه می‌کند که زیرشبکه WSL2 را با متریکی کمتر از مسیر پیوند میزبان می‌پوشاند، بسته‌های آدرس‌دهی‌شده به ماشین مجازی کمکی وارد تونل می‌شوند. آن‌گاه هر سرویس WSL2 زمان‌اش تمام می‌شود، نه فقط DNS.

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

برای مورد مسیریابی، متریک خودکار را از آداپتور تونل بردارید و عددی بالاتر از مسیر پیوند WSL2 به آن بدهید:

Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown

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

فایل را آگاهانه به دست بگیرید

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

درون توزیع /etc/wsl.conf را با بخش شبکه‌ای که تولید را غیرفعال می‌کند بسازید، سپس فایل resolver را خودتان بنویسید، نخست سرور شرکتی و دوم یک سرور عمومی به‌عنوان جایگزین:

[network]
generateResolvConf = false
search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

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

نخست نام‌ها را بررسی کنید، سپس بسته‌ها

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

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

getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com

یک جست‌وجوی داخلی کارآمد و یک جست‌وجوی عمومی کارآمد، از درون توزیع، همان نتیجه‌ای است که ارزش ثبت دارد. یک نماد سبز VPN روی میزبان هیچ‌کدام را اثبات نمی‌کند.

مقالات مرتبط