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 stub انتخاب‌شده توسط 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 ویندوز هدایت می‌کند حتی وقتی کارخواه فهرست DNS را بازنویسی می‌کند. جهانی نیست: برخی درایورهای فیلتر هنوز مسیر آینه‌ای را دور می‌ریزند، و قواعد فایروال Hyper-V ممکن است به اجازه صریح نیاز داشته باشند. راهنمای شبکه WSL مایکروسافت صفحه‌ای است که باید پیش از اعمال دستوری که برای نسخه جدیدتر نوشته شده، با نسخه خود بسنجید.
پس از هر تغییر سه چیز را بیازمایید
برای هر ماشین یک مکانیزم انتخاب کنید و بنویسید، چون این دو بد ترکیب می‌شوند. sidecar روی حالت آینه‌ای هدایت را دوبرابر می‌کند، و میزبان آینه‌ای با ورودی sidecar کهنه در .wslconfig معمولاً پس از ارتقا شکست می‌خورد نه پیش از آن.
هر چه انتخاب کرده باشید، آزمون پذیرش همان سه درخواست درون توزیع است: یک نام داخلی، یک نام عمومی و یک نشانی خام. سپس آن‌ها را پس از قطع و اتصال دوباره تونل و پس از wsl --shutdown تکرار کنید. شکست تنها نام داخلی یعنی سیاست resolver؛ شکست همزمان نام داخلی و عمومی در حالی که نشانی کار می‌کند هنوز یعنی سیاست resolver؛ شکست همه‌چیز یعنی مسیر.
اگر یک میزبان داخلی شکست بخورد و بقیه کار کنند، از resolver دست بردارید و مسیر گمشده‌ای برای آن پیشوند بجویید. اگر همه‌چیز تا اتصال دوباره بعدی کار کند، اصلاحی یافته‌اید که به وضعیت زمان اجرا وابسته است، و باید خودکار دوباره اعمال شود یا با یکی از دو مکانیزم بالا جایگزین شود.