چرا WSL هنگام اتصال VPN نام میزبان کاری را از دست می‌دهد؟
همان نام در Windows کار می‌کند و داخل WSL به محض بالا آمدن تونل شکست می‌خورد. پیش از افزودن یک حل‌کننده، حالت DNS سکو و بازنویسی‌های کهنه را بررسی کنید.
Windows میزبان داخلی را بدون هیچ شکایتی حل می‌کند، و همان نام داخل WSL درست در لحظه‌ای که تونل بالا می‌آید شکست می‌خورد. تعمیر معمول این است که یک حل‌کننده عمومی در توزیع بنویسیم، که مرور عادی را برمی‌گرداند و نام میزبان کاری را غیرقابل‌حل می‌کند. این یک خطا را با خطای دیگر عوض می‌کند و لایه‌ای را که واقعاً شکسته است پنهان می‌کند. پیش از افزودن یا حذف هر خط حل‌کننده، مشخص کنید کدام یک از سه لایه شکست می‌خورد.
ابتدا خطای مسیریابی را کنار بگذارید
همان نام کاملاً واجد شرایط را از هر دو طرف بپرسید، نه دو نام شبیه به هم. موفقیت در Windows و شکست در WSL برای همان رشته، امضای دو مسیر حل متفاوت است و چیز دیگری این الگو را این‌قدر تمیز تولید نمی‌کند. اگر WSL به سرویس در نشانی عددی شناخته‌شده‌اش هم نرسد، مشکل مسیریابی یا فیلترکردن هم وجود دارد. در آن صورت کار روی DNS آن را آشکار نمی‌کند و بعدازظهر به لایه اشتباه می‌رود.
سه نشانه بیشتر این موارد را پوشش می‌دهند و هر یک به جای متفاوتی اشاره می‌کند. پیش از باز کردن فایل پیکربندی، ردیفی را که مطابقت دارد بخوانید:
| Symptom inside WSL | Likely layer | Where to look |
|---|---|---|
| Private name fails while public browsing works | Resolver path | Tunneling mode and the Windows build |
| A name that worked yesterday fails today | Stale override | Generated resolver file, immutable flag, shell profile |
| The name resolves but the service does not | Routing or filtering | The resolved address and the path to it |
ردیف میانی همانی است که مردم بد می‌خوانند، چون تغییری که آن را شکست هفته‌ها پیش انجام شده بود و آن زمان موفق به نظر می‌رسید. ردیف سوم همانی است که مردم بد تشخیص می‌دهند، چون نامی که حل می‌شود مثل مدرکی است بر سالم بودن شبکه. هر دو ردیف شما را به بخش متفاوتی در پایین می‌فرستند.
تونل DNS یک کف نسخه دارد
Microsoft حالت شبکه‌ای در WSL را مستند می‌کند که درخواست‌های DNS را از طریق کانالی مجازی‌سازی به حل‌کننده Windows تونل می‌کند. در بیلدهای پشتیبانی‌شده Windows 11 به‌طور پیش‌فرض فعال است و به همین دلیل دو ماشین در یک شبکه سازمانی یکسان رفتار متفاوتی دارند. متغیر، شماره بیلد است نه سیاست سازمان.
راهنمای شبکه WSL آن حالت و نسخه‌هایی را که از آن پشتیبانی می‌کنند توصیف می‌کند. این ویژگی اهمیت دارد چون سیاست DNS سازمانی معمولاً در حل‌کننده Windows زندگی می‌کند و توزیعی که مسیر Windows را به ارث می‌برد، سیاست را هم با آن به ارث می‌برد. توزیعی که از حل‌کننده عمومی می‌پرسد هیچ مسیری به یک نام خصوصی ندارد، هرقدر هم پیکربندی خودش مرتب به نظر برسد. همین سازوکار کل نشانه را توضیح می‌دهد و توضیح می‌دهد که چرا راه‌حل موقت با حل‌کننده عمومی شکست می‌خورد.
پیش از تغییر هر چیزی، شماره بیلد را بخوانید. تنظیمی که از یک نصب جدیدتر کپی شده مدرکی نیست بر اینکه نصب قدیمی‌تر آن را پیاده می‌کند. شماره بیلد را کنار تغییر یادداشت کنید، چون تفاوت دو ماشین تقریباً همیشه نسخه است نه سیاست.
بازنویسی‌های قدیمی از مشکلی که حلش کردند بیشتر عمر می‌کنند
دستورهای قدیمی‌تر فایل‌های حل‌کننده تولیدشده را غیرفعال می‌کردند، یک سرور نام را سخت‌کد می‌کردند، یا فایل را با ویژگی تغییرناپذیر قفل می‌کردند. آن تغییرات مدت‌ها پس از ناپدید شدن مشکل اتصالی که آنها را برانگیخته بود در جای خود می‌مانند و معمولاً دلیل آن‌اند که یک تنظیم جدیدتر بی‌اثر به نظر می‌رسد. آنها همچنین از نصب دوباره توزیع در قالب یک پروفایل shell که فایل را در هر ورود بازنویسی می‌کند جان سالم به در می‌برند. یافتن آخری سخت‌ترین است، چون از فایلی که همه بازرسی می‌کنند نامرئی است.
به دنبال فایل حل‌کننده‌ای دست‌نویس، ویژگی تغییرناپذیر روی آن و اسکریپت راه‌اندازی‌ای بگردید که آن را بازنویسی می‌کند. پیش از ویرایش پرچم تغییرناپذیر را بررسی کنید، چون نوشتن در فایل قفل‌شده به شکلی شکست می‌خورد که مثل مشکل دسترسی خوانده می‌شود. سپس پروفایل shell را بررسی کنید، چون اسکریپتی آنجا محتوای قدیمی را در عرض چند ثانیه پس از اصلاح شما برمی‌گرداند.
حذف یک بازنویسی پیامد دارد، پس ثبت کنید چه چیزی را حذف کردید و چرا. توزیعی که واقعاً برای هدفی دیگر به حل‌کننده ثابت نیاز دارد، وقتی فایل تولیدشده برگردد می‌شکند.
دو فایل، دو نقش متفاوت
دو فایل پیکربندی در جاهای متفاوتی زندگی می‌کنند و چیزهای متفاوتی را کنترل می‌کنند، و اشتباه گرفتن آنها ویرایش‌هایی می‌سازد که روی لایه اشتباه اعمال می‌شوند. فایل سمت Windows ویژگی‌های ماشین مجازی را تعیین می‌کند، در حالی که فایل سمت توزیع تعیین می‌کند که آن توزیع پیکربندی حل‌کننده خودش را چگونه می‌سازد. هیچ‌کدام دیگری را بازنویسی نمی‌کند و به همین دلیل هر دو باید هماهنگ باشند.
برای نصبی که از این ویژگی پشتیبانی می‌کند، قطعه سمت Windows کوتاه است. تمام تغییر در آن سمت همین است:
[wsl2]
dnsTunneling=trueاین قطعه به پروفایل کاربر Windows تعلق دارد و برای ماشین مجازی اعمال می‌شود نه برای یک توزیع واحد. تونل‌سازی همچنین نیاز دارد که توزیع تولید حل‌کننده را غیرفعال نکرده باشد، پس فایل سمت توزیع باید این رفتار را به حال خود بگذارد. یکی را بدون دیگری تغییر دهید و حالت بی‌صدا هیچ کاری نمی‌کند، و این رایج‌ترین راهی است که این تعمیر به‌عنوان خراب گزارش می‌شود. هر دو فایل را در یک نشست بررسی کنید، چون دو ویرایش با فاصله چند هفته دو ویرایشی است که هیچ‌کس نمی‌تواند به کسی نسبت دهد.
دوباره راه‌اندازی کنید، سپس از هر دو طرف بپرسید
این تنظیمات هنگام شروع محیط خوانده می‌شوند، پس یک shell جدید داخل توزیع در حال اجرا آنها را دوباره بارگذاری نمی‌کند. به جای راه‌اندازی دوباره shell، محیط را خاموش کنید و ابتدا هر کار در حال اجرا را ذخیره کنید چون هر توزیع با آن متوقف می‌شود. همین یک غفلت بیشتر گزارش‌های بی‌اثر بودن یک تغییر را توضیح می‌دهد.
سپس همان پرسش را از هر دو طرف بپرسید. خروجی همچنین نشان می‌دهد توزیع واقعاً با کدام حل‌کننده کار را تمام کرده است:
wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'دستور اول محیط را پایان می‌دهد، دومی نشان می‌دهد توزیع اکنون از کدام حل‌کننده استفاده می‌کند، و دو دستور آخر همان پرسش را به هر طرف می‌کنند. پاسخ‌ها را مقایسه کنید نه وضعیت تنظیم را. پرسشی که پس از یک راه‌اندازی تمیز و با درست بودن هر دو فایل هنوز شکست می‌خورد به سیاست حل‌کننده سازمانی اشاره می‌کند و آن گفت‌وگو صاحب دیگری دارد.