WSL2 لا يرث شبكة VPN المؤسسة، وهذا هو الخلل
يعمل WSL2 في شبكة افتراضية خاصة به ولا يرث مكدس VPN الخاص بالمضيف أبدًا. افصل إخفاقات الأسماء عن إخفاقات المسار قبل أن تحرر resolv.conf من الأساس.
تفتح الويكي الداخلية في Edge، بينما ينتهي git clone داخل التوزيعة بمهلة. تُقرأ هذه الملاحظة الوحيدة عادةً على أنها «شبكة VPN تحجب WSL2»، وتذهب الساعة التالية في تحرير /etc/resolv.conf. القراءة الأنفع هي أن WSL2 لم يكن يملك مسار شبكة المضيف من الأساس: فهو يعمل في جهاز ظاهري مرافق بمهايئه الخاص ومسارات خاصة به وملف resolver يولّده Windows له. كل ما يلي يعتمد على أي من تلك الثلاثة ينقصك فعلًا.
الجهاز الظاهري له مكدسه ومقياسه وresolver الخاص به
في وضع NAT الافتراضي، تقف التوزيعة خلف مبدّل افتراضي وتصل إلى الإنترنت عبر المضيف، لكنها لا ترى مهايئات المضيف. يعرض ip addr واجهة واحدة بعنوان خاص، ويعرض ip route مسارًا افتراضيًا عبر ذلك المبدّل، و /etc/resolv.conf ملف مولّد يشير إلى resolver جذعي اختاره Windows. لا شيء من ذلك يتغير لأن عميل VPN بدأ على جانب Windows.
لهذا فإن «المتصفح يعمل» يثبت القليل جدًا. المتصفح يستخدم مكدس المضيف والنفق وسياسة resolver الخاصة بالمضيف. أما صدفتك فتستخدم مكدسًا مختلفًا يصادف أنه يشارك بطاقة شبكة فيزيائية. وهما يتفقان في الحالة السعيدة ويختلفان تحديدًا عندما يثبّت VPN مرشحًا أو يعيد كتابة قائمة DNS أو يضيف مسارًا للشبكة الفرعية للمبدّل الافتراضي.
اختباران يحسمان في أي عالم أنت، ويجب أن يجريا داخل التوزيعة:
getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.confفشل الأسماء مع استجابة عنوان حرفي مشكلة resolver. فشل الأسماء والعناوين معًا مشكلة مسار، ولن يمسها أي قدر من تحرير resolver. تأتي أدلة جانب Windows بعد ذلك: Get-NetAdapter | Get-DnsClientServerAddress و route print -4 يُظهران ما إذا كان النفق قد استحوذ على الشبكة الفرعية التي يعيش فيها جهازك الظاهري.
الخرافة الأولى: خوادم DNS المؤسسية تحل الأمر
تحرير ملف resolver هو النصيحة الكلاسيكية، وهي صحيحة نحو نصف الوقت. وحين تكون صحيحة، تكون صحيحة لسبب محدد: الملف المولّد يشير إلى resolver يعرف الأسماء العامة فقط، فيعود الاستعلام عن intranet.example.internal كغير موجود رغم أن المسار سليم.
تثبيت خوادم VPN يعني منع Windows من إعادة توليد الملف، لأن أي ملف تكتبه يدويًا يُستبدل عند التشغيل التالي:
[network]
generateResolvConf = falseاحفظ ذلك باسم /etc/wsl.conf، وشغّل wsl --shutdown من Windows، ثم ابدأ التوزيعة واكتب /etc/resolv.conf بخوادم النفق أولًا وresolver عام كاحتياط فقط. هذا تغيير دائم له كلفة صيانة: الملف لم يعد يتبع المضيف، فعندما تتغير عناوين DNS الخاصة بالمؤسسة تستمر التوزيعة في سؤال العناوين القديمة. ويجب أن يملك أحدهم ذلك الملف.
ولا يفعل شيئًا حين يكون الإخفاق أوسع. إذا انتهى curl إلى 1.1.1.1 بمهلة، فإن عميل النفق يرشّح المبدّل الافتراضي أو يوجّه الشبكة الفرعية للجهاز الظاهري إلى النفق، وresolver الصحيح لا يعطيك إلا أسماء لا يمكن الوصول إليها.
الخرافة الثانية: تغيير المقياس يبقى
عندما تُحلّ الأسماء لكن الحركة تخرج عبر المهايئ الفيزيائي، تكون مقاييس الواجهات هي الرافعة. أعطِ مهايئ VPN كلفة عالية ومبدّل WSL كلفة منخفضة:
Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1ثم تذكّر أن مهايئ النفق في كثير من إصدارات العميل يُعاد إنشاؤه عند كل اتصال ويعود المقياس إلى قيمته الافتراضية. الأمر لمرة واحدة إصلاح ينتهي بهدوء، غالبًا خلال عطلة نهاية أسبوع، فتعود التذكرة بعبارة «كان يعمل الأسبوع الماضي». المهمة المجدولة التي يطلقها حدث VPN، أو سكربت يشغّله المستخدم بعد الاتصال، هي النسخة الصادقة من هذا الإصلاح.
ينطبق الانتهاء نفسه على مسارات المضيف المضافة لبادئة واحدة عنيدة. لها قيمة كتشخيص، لأنها تخبرك هل المشكلة وجهة واحدة أم المسار كله، لكنها ليست معمارًا.
الخرافة الثالثة: إصلاح واحد يغطي كل إصدار Windows
| Approach | What it actually does |
|---|---|
| Resolver pin | Fixes private names only; no effect on path failures |
| Sidecar distribution | Forwards traffic over a socket to a helper VM, so the switch's filter no longer matters |
| Mirrored networking | Gives the distribution the host's interface set; also enables DNS tunnelling |
wsl-vpnkit هو نمط sidecar: توزيعة صغيرة تملك المسار على جانب المضيف وتعيد التوجيه لتوزيعات أخرى عبر مقبس افتراضي، فيتوقف مرور التطبيقات عن الاعتماد على المبدّل المرشّح. يحتاج المسار القياسي ليعمل، أي إزالة تجاوزات networkingMode و dnsTunneling من %UserProfile%\.wslconfig، واستعادة generateResolvConf = true في كل توزيعة عاملة، وبدء الخدمة عند تسجيل الدخول.
الوضع المرآوي هو البديل المدمج في Windows 11 22H2 وما بعده، وهو إعداد واحد زائد إيقاف تشغيل:
[wsl2]
networkingMode=mirroredداخل التوزيعة يسرد ip addr حينها مهايئات المضيف، وقد يظهر النفق بينها، كما يعيد نفق DNS توجيه الاستعلامات عبر resolver الخاص بـ Windows حتى عندما يعيد العميل كتابة قائمة DNS. وهو ليس شاملًا: بعض برامج تشغيل الترشيح ما زالت تُسقط المسار المرآوي، وقد تحتاج قواعد جدار حماية Hyper-V إلى سماح صريح. ويقدّم دليل شبكات WSL من Microsoft الصفحة التي يجب مطابقتها مع إصدارك قبل تطبيق وصفة كُتبت لإصدار أحدث.
اختبر ثلاثة أشياء بعد كل تغيير
اختر آلية واحدة لكل جهاز واكتبها، لأن الاثنتين تتجمعان بشكل سيئ. sidecar فوق الوضع المرآوي يضاعف إعادة التوجيه، والمضيف المرآوي مع مدخل sidecar قديم في .wslconfig يميل إلى الإخفاق بعد الترقية لا قبلها.
أيًا ما اخترت، اختبار القبول هو الطلبات الثلاثة نفسها داخل التوزيعة: اسم داخلي واسم عام وعنوان خام. ثم كررها بعد فصل النفق وإعادة وصله، وبعد wsl --shutdown. فشل الاسم الداخلي وحده يعني سياسة resolver؛ وفشل الاسمين الداخلي والعام معًا مع عنوان عامل يعني سياسة resolver أيضًا؛ وفشل كل شيء يعني المسار.
إذا فشل مضيف داخلي واحد بينما يعمل الباقي، فتوقف عن النظر إلى resolver وابحث عن مسار ناقص لتلك البادئة. وإذا كان كل شيء يعمل حتى إعادة الاتصال التالية، فقد وجدت إصلاحًا يعتمد على حالة وقت التشغيل، ويجب إعادة تطبيقه تلقائيًا أو استبداله بإحدى الآليتين أعلاه.