WSL2 به زیرشبکه VPN نمی‌رسد: مسیر میزبان را بخوانید

از داخل توزیع، ping به یک سرور داخلی منقضی می‌شود، در حالی که همان آدرس از Windows پاسخ می‌دهد. VPN متصل است و مسیر Windows درست است، پس شکاف، مرز WSL است. مسیر را از فرمان ناموفق به عقب تا رابط میزبان دنبال کنید. راه‌حل یک CIDR ثابت در فایل پیکربندی نیست؛ خواندن آدرس فعلی و افزودن آن جایی است که توزیع می‌تواند از آن استفاده کند.

تأیید کنید که مسیر کجا متوقف می‌شود

همان آزمون را در هر دو طرف اجرا کنید: یک میزبان داخلی را از Windows حل و به آن متصل شوید، سپس آن را در توزیع تکرار کنید. موفقیت در Windows به‌همراه انقضا در توزیع، خطا را بین این دو مشخص می‌کند، نه در کلاینت VPN یا سرور داخلی. این کار را پیش از تغییر هر مسیری انجام دهید تا دو نتیجه یک مقصد را توصیف کنند.

در داخل توزیع، ip -4 addr یک آداپتور مجازی با آدرسی از محدوده NAT در WSL نشان می‌دهد، و ip route یک مسیر پیش‌فرض به سمت دروازه WSL نشان می‌دهد. هیچ مسیری برای پیشوند سازمانی وجود ندارد، چون آداپتور تونل میزبان همتایی در داخل توزیع ندارد. دروازه پیش‌فرض به NAT در WSL می‌رسد، نه به شبکه سازمانی.

افزودن مسیر سازمانی بدون افزودن نخست یک آدرس محلی روی پیوندی قابل‌دسترس، انقضا یا خطای شبکه دسترسی‌ناپذیر تولید می‌کند. آدرس همان بخشی است که مسیر را قابل‌استفاده می‌کند، پس نخست آن را بخوانید و مسیر را گام دوم بدانید.

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

شبکه آینه‌ای رابط‌های خود میزبان را به توزیع می‌دهد، بنابراین تونل و مسیرهایش بدون کپی ظاهر می‌شوند. این قابلیت به بیلد تازه Windows و به networkingMode=mirrored در .wslconfig وابسته است، و فعال‌کردنش رفتارهای نامرتبط مانند ارسال localhost را تغییر می‌دهد. آن را تغییر پلتفرم بدانید، نه تنظیم مسیر. اگر بیلد پشتیبانی می‌کند و عوارض جانبی پذیرفتنی است، کوتاه‌ترین راه است.

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

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

جزئیات فعلی تونل را از میزبان بگیرید

آداپتور را با آدرس MAC مطابقت دهید نه با نام، چون نام‌ها با کلاینت VPN و ترتیب اتصال تغییر می‌کنند. آداپتورها را یک بار فهرست کنید، MAC آداپتور تونل را یادداشت کنید، سپس آدرس و پیشوندش را بپرسید. MAC در اتصال‌های دوباره با آداپتور مجازی می‌ماند، اما نام و ایندکس رابط نمی‌مانند:

powershell.exe 'Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" } | Get-NetIPAddress -AddressFamily IPv4 | Select-Object IPAddress, PrefixLength'

دروازه از پیکربندی رابط می‌آید. نخست ایندکس رابط را بگیرید، سپس گام بعدی را بخوانید. ایندکس ممکن است پس از راه‌اندازی دوباره یا بازنشانی آداپتور تغییر کند، از این رو اسکریپت باید آن را بخواند نه ذخیره کند:

powershell.exe '(Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" }).InterfaceIndex'
powershell.exe '(Get-NetIPConfiguration -InterfaceIndex 27).IPv4DefaultGateway.NextHop'

خروجی را پیش از انتساب به متغیر از tr -d '\r' عبور دهید. PowerShell خطوط را با بازگشت کالسکه پایان می‌دهد، و بدون حذف آن فیلد آخر یک نویسه پنهان دارد که فرمان مسیر را با خطای تجزیه گیج‌کننده شکست می‌دهد.

آدرس و مسیر را داخل توزیع اعمال کنید

آدرس تونل را به‌عنوان آدرس دارای پیشوند روی رابط توزیع نصب کنید، سپس بلوک سازمانی را از دروازه میزبان عبور دهید:

sudo ip addr add 172.20.14.37/22 dev vpn
sudo ip route add 172.20.0.0/16 via 172.20.12.1 dev vpn

NetworkManager وقتی اتصال چرخه می‌شود آدرس پیکربندی‌شده دستی را رها می‌کند، و هیچ کلاینت DHCP جایگزینی نمی‌خواهد. روش را خودکار بگذارید تا هر اتصال دوباره آدرس را تازه کند، سپس اتصال را دوباره بالا بیاورید. روش دستی تا نخستین اتصال دوباره پایدار به نظر می‌رسد:

nmcli con show vpn
sudo nmcli con mod vpn ipv4.method auto
sudo nmcli con up vpn

هر دو گام را از قلابی که VPN را آغاز می‌کند اجرا کنید، نه از پوسته تعاملی. اسکریپتی که آدرس را می‌خواند، اضافه می‌کند، مسیر را اضافه می‌کند و مقادیر را ثبت می‌کند، تعمیر دستی تکرارشونده را تکرارپذیر می‌کند، و گزارش نخستین چیزی است که هنگام تغییر پیشوند باید خوانده شود.

نام را تثبیت کنید و مسیر را اثبات کنید

کرنل می‌تواند پس از تغییر شبکه، نام رابط توزیع را بین eth1 و eth2 عوض کند، و اسکریپتی که بر اساس نام نوشته شده آن‌گاه دستگاه اشتباه را ویرایش می‌کند. قاعده udev کلیدشده به MAC به رابط برچسب پایدار می‌دهد:

SUBSYSTEM=="net", ACTION=="add", ATTRS{address}=="3c:52:82:0a:1b:7c", NAME="vpn"

سپس با آدرس، مسیر و یک اتصال واقعی TCP بررسی کنید: ip -4 addr show dev vpn، ip route get 172.20.4.10 و اتصال به یک درگاه داخلی شناخته‌شده. جست‌وجوی مسیر باید دستگاه vpn و آدرس مبدأیی را که افزودید نام ببرد.

اگر هر سه داخل توزیع بگذرند و اتصال هنوز شکست بخورد، بسته از WSL خارج می‌شود و در سمت Windows دور انداخته می‌شود. پیش از تغییر اسکریپت، دیوار آتش میزبان و پالایش خود کلاینت VPN را بررسی کنید، چون ویرایش مسیر دیگر بسته‌ای را که از قبل به میزبان می‌رسد درست نمی‌کند.