لماذا يفقد 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'الأمر الأول ينهي البيئة، والثاني يُظهر أي مُحلِّل تستخدمه التوزيعة الآن، والأمران الأخيران يطرحان السؤال نفسه على كل جانب. قارن الإجابات لا حالة الإعداد. الاستعلام الذي لا يزال يفشل بعد إعادة تشغيل نظيفة مع صحة الملفين يشير إلى سياسة المُحلِّل المؤسسية، ولهذا الحوار مالك مختلف.