چگونه بررسی کنیم VPN در ویندوز واقعاً چه چیزی را در PowerShell مسیریابی می‌کند
کاشی متصل VPN پوشش را اثبات نمی‌کند. پرچم ذخیره‌شده پروفایل، جدول مسیر زنده و قواعد NRPT را به همین ترتیب بخوانید.
کلاینت VPN را روی لپ‌تاپی با Windows 11 متصل کردم، کاشی به Connected رفت، یک اشتراک فایل داخلی باز شد و یک سایت عمومی همچنان مستقیم از Wi-Fi دفتر بارگذاری می‌شد. این ترکیب شبیه تونل خراب است. اما خروجی عادی پروفایلی است که بخشی از ترافیک را از VPN می‌فرستد و بقیه را روی آداپتور فیزیکی می‌گذارد. تونل اجباری تغییر می‌دهد که Windows کدام مسیر پیش‌فرض را ترجیح دهد؛ مسیرهای دقیق‌تر را حذف نمی‌کند و وعده نمی‌دهد که با قطع اتصال ترافیک متوقف شود. آنچه در پی می‌آید ترتیبی است که وقتی کلاینتی ادعای پوشش می‌کند طی می‌کنم: وضعیت کلاینت، پروفایل ذخیره‌شده، مسیرهای اعمال‌شده، حل‌کننده و سپس جریان‌های واقعی.
از کلاینت شروع کنید و بعد به آن اعتماد نکنید
کلاینت فقط به این دلیل نقطه شروع درستی است که می‌گوید کدام پروفایل فعال است. ویژگی‌های اتصال را باز کنید و نام دقیق پروفایل، اینکه برای کاربر جاری ساخته شده یا برای همه روی دستگاه، و اینکه پس از اتصال کدام آداپتور در ncpa.cpl دیده می‌شود را یادداشت کنید. روی لپ‌تاپ آزمایشی من آداپتور نام پروفایل را داشت و همین خواندن خروجی مسیرها را آسان می‌کرد. روی دستگاه‌های دیگر به‌صورت یک ورودی WAN Miniport ظاهر می‌شود و نام چیزی به شما نمی‌گوید.
چیزی که کلاینت نمی‌تواند بگوید پوشش است. کاشی متصل وضعیت تونل را توصیف می‌کند، نه فهرستی از مقصدها. کلاینت‌های شخص ثالث هم پیکربندی خودشان را نگه می‌دارند، پس ممکن است پروفایل بومی Windows و هر ویژگی که از آن می‌خوانید هیچ ربطی به چیزی که آن کلاینت نصب کرده نداشته باشد. اگر VPN از طریق AnyConnect، OpenVPN GUI، WireGuard یا عامل یک فروشنده آمده باشد، بررسی‌های PowerShell زیر عمدتاً اعمال نمی‌شوند و باید تنظیمات split-tunnel و مسیریابی خود آن کلاینت را بخوانید.
پروفایل ذخیره‌شده را بخوانید، نه کاشی را
برای یک پروفایل بومی Windows (IKEv2، L2TP، SSTP یا پروفایلی که MDM هل می‌دهد) تصمیم ذخیره‌شده split-tunnel یک ویژگی است:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixوقتی پروفایل برای همه روی دستگاه ساخته شده -AllUserConnection را اضافه کنید. بدون آن فهرست کاربر جاری را می‌خوانید که ممکن است خالی باشد یا ورودی دیگری با نامی مشابه داشته باشد. مقدار False در SplitTunneling یعنی پروفایل به‌صورت تونل کامل ذخیره شده است: Windows یک مسیر پیش‌فرض از طریق آداپتور VPN نصب می‌کند. True یعنی split tunnel، و پوشش آن‌گاه کاملاً به مسیرها و قواعد حل نامی بستگی دارد که آن پروفایل هل می‌دهد.
آن مقدار را پیکربندی بدانید، نه مشاهده. ثبت می‌کند که پروفایل در زمان اتصال چه خواسته است. ممکن است Windows با مسیرهای اعمال‌شده متفاوتی تمام کند، به‌خاطر مسیر دقیق‌تر یک رابط دیگر، یک تنظیم سیاست یا ورودی باقی‌مانده از اتصال قبلی، پس مقدار بولی هرگز به‌تنهایی پرسش را حل نمی‌کند.
مقدار ذخیره‌شده را با جدول مسیرهای اعمال‌شده مقایسه کنید
پس از اتصال، مسیرهای آداپتور تونل را فهرست کنید به‌جای پیمایش کل جدول:
$vpn = Get-NetAdapter | Where-Object InterfaceDescription -match 'VPN|WAN Miniport'
Get-NetRoute -InterfaceIndex $vpn.ifIndex | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.20.4.15 | Select-Object -First 1Find-NetRoute نیمه مفید است. به پرسشی پاسخ می‌دهد که کلاینت هرگز پاسخ نمی‌دهد: برای این مقصد، Windows واقعاً از کدام رابط و کدام نشانی مبدأ استفاده می‌کند؟ آن را برای یک میزبان داخلی، یک میزبان عمومی و هر چیزی که آن را استثنای عمدی می‌دانید اجرا کنید. پروفایل تونل کامل باید برای نشانی عمومی رابط تونل را نشان دهد. پروفایل split tunnel معمولاً آنجا آداپتور فیزیکی را نشان می‌دهد در حالی که پیشوندهای داخلی هنوز به VPN حل می‌شوند.
دو تله بیشتر گزارش‌های «مسیر را اشتباه می‌رود» را توضیح می‌دهند. دقیق‌ترین پیشوند همیشه برنده است، پس یک /24 روی آداپتور فیزیکی بر مسیر پیش‌فرض VPN چیره می‌شود هر‌چقدر هم متریک تونل پایین باشد. متریک فقط بین مسیرهای هم‌پیشوند تساوی را می‌شکند. و IPv4 و IPv6 جداگانه تصمیم‌گیری می‌شوند: پروفایلی که 0.0.0.0/0 را می‌پوشاند می‌تواند IPv6 را روی پیوند محلی بگذارد، که باعث می‌شود یک سایت دوس‌تکه نیمه‌تونل‌شده به نظر برسد. پیش از نتیجه‌گیری که تونل سالم است Get-NetRoute -AddressFamily IPv6 را بررسی کنید.
| What you see | Most likely cause | Check next |
|---|---|---|
| Public traffic leaves the physical adapter while SplitTunneling reads False | A more specific route on that adapter wins over the tunnel default | Find-NetRoute for the exact destination, then look for a /24 or host route on the physical interface |
| Internal name fails, internal IP works | No NRPT rule for that namespace, or a broader rule matches first | Get-DnsClientNrptPolicy and the namespace order |
| A dual-stack site opens directly while IPv4 uses the tunnel | The profile covers only the IPv4 default route | The IPv6 route table on both interfaces |
| Routes look right but one app still goes direct | The app uses its own proxy, or the client keeps a per-app list | The app's proxy settings and the client's application list |
حل نام را جداگانه با NRPT بررسی کنید
نام‌های داخلی که شکست می‌خورند در حالی که نشانی‌های IP داخلی کار می‌کنند به سیاست حل‌کننده اشاره دارند، نه به مسیریابی. Windows DNS را برای هر فضای نام از طریق جدول سیاست حل نام تصمیم می‌گیرد که از جدول مسیر مستقل است:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexوقتی قاعده‌ای با *.corp.example مطابقت دارد، پرس‌وجوهای آن فضای نام به سرورهای DNS تونل می‌روند حتی اگر مسیر داده به آن سرورها در حالت split tunnel روی آداپتور فیزیکی بماند. طراحی همین است و به همین دلیل آزمون مرورگری که یک سایت عمومی باز می‌کند چیزی درباره نام‌های داخلی نمی‌گوید. اگر آداپتور سرورهای مورد انتظار را فهرست می‌کند اما جست‌وجوها هنوز جای دیگری می‌روند، ترتیب قواعد NRPT را مقایسه کنید و ببینید آیا فضای نام دقیق‌تری اول مطابقت می‌کند.
جریان‌ها را بررسی کنید، سپس تصمیم بگیرید واقعاً چه خواسته‌اید
مقصدها را به ترتیبی ثابت طی کنید تا نتایج بین دستگاه‌ها قابل مقایسه باشد: یک نشانی عمومی، یک نشانی داخلی، یک نام داخلی و یک استثنای عمدی مثل چاپگر محلی یا تماس ویدیویی. برای هرکدام رابط و نشانی مبدأیی که Find-NetRoute برمی‌گرداند را ثبت کنید. پس از هر تغییر سیاست، دوباره متصل شوید و همان چهار بررسی را تکرار کنید؛ جدول مسیر بعد از اتصال مجدد تنها شاهد اعمال پروفایل جدید است.
سپس مسیریابی را از اجرای اجباری جدا کنید. تونل اجباری برای ترافیک پوشش‌داده‌شده تا وقتی تونل بالاست تونل را ترجیح می‌دهد. این یک کلید قطع اضطراری نیست. اگر الزام این است که با افتادن تونل چیزی از دستگاه خارج نشود، این باید از یک طراحی مسدودکننده بیاید: پروفایل فایروالی که به وضعیت تونل گره خورده، پروفایل همیشه‌روشن با فیلترهای ترافیک، یا گزینه بستن هنگام خطای خود کلاینت فروشنده. تونل اجباری همچنین باید نشانی خود سرور VPN را بیرون از تونل قابل دسترس بگذارد، و مسدود کردن آن به نام «اجبار همه‌چیز» راهی مطمئن برای قفل کردن خودتان بیرون از اتصالی است که می‌کوشید اعمال کنید.
پیش از تغییر هر چیزی، این فهرست را مرور کنید. هر موردی که شکست می‌خورد جای مشکل واقعی را باریک‌تر می‌کند.
- نام و دامنه پروفایل تأیید شد، با استفاده از
-AllUserConnectionبرای پروفایل‌های سراسر دستگاه. SplitTunnelingخوانده و به‌عنوان پیکربندی تلقی شد، نه شاهد پوشش.- مسیرهای آداپتور تونل جداگانه برای IPv4 و IPv6 فهرست شد.
Find-NetRouteبرای یک مقصد عمومی، یک داخلی و یک استثنا اجرا شد.- قواعد NRPT پیش از سرزنش مسیرها برای شکست یک نام بررسی شد.
- الزام مسدودسازی دوباره خوانده شد: مسیریابی ترجیحی همان مسدودسازی اعمال‌شده نیست.
تصمیم تونل کامل یا split متعلق به مالک پروفایل است، و یادداشت‌های مسیریابی Microsoft رفتاری را توصیف می‌کنند که Windows وقتی پروفایل آن را تنظیم می‌کند پیاده می‌کند. Microsoft: تونل اجباری و split مرجعی است که هنگام خواندن خروجی باز نگه می‌دارم.