VPN شبکه LAN محلی را در Windows مسدود می‌کند: مسیر یا سیاست کلاینت؟
دسترسی به LAN محلی در Windows به دو دلیل متفاوت قطع می‌شود: مسیر گم‌شده، یا سیاست دروازه‌ای که زیرشبکه را رها می‌کند. سه بررسی می‌گوید کدام.
چاپگر، NAS یا ماشین توسعه روی میز خودتان همان لحظه‌ای که VPN کاری وصل می‌شود از پاسخ دادن باز می‌ماند. گاهی یک فرمان مسیر در چند ثانیه درستش می‌کند؛ گاهی همان مسیر درست است و بسته‌ها باز هم ناپدید می‌شوند، یعنی با مشکل دیگری با نشانهٔ مشابه روبه‌رو هستید. تصمیم به سه پرسش خلاصه می‌شود، و پرسیدن آن‌ها به ترتیب نادرست دلیل آن است که مردم یک شب کامل را صرف حذف و افزودن دوبارهٔ مسیرها می‌کنند.
سه پرسش پیش از هر فرمان
نخست: آیا برای پیشوند محلی ورودی وجود دارد و آیا به آداپتور فیزیکی اشاره می‌کند؟ دوم: آیا کلاینت هنگام اتصال از دروازه اجازه یا منع شبکهٔ محلی می‌گیرد؟ سوم: آیا فقط به دسترسی خروجی به LAN نیاز دارید، یا چیزی در اینترنت هم باید به سرویسی برسد که روی ماشین شما اجرا می‌شود؟
پرسش نخست خطای مسیریابی را از خطای فیلتر جدا می‌کند. دومی می‌گوید آیا اصلاح مسیر اصلاً اجازهٔ کار دارد. سومی ترمیم را عوض می‌کند: مسیر ترافیک خروجی را درست می‌کند، در حالی که سرویس ورودی دسترسی‌ناپذیر معمولاً مشکل اتصال شنونده و مسیر بازگشت است که مسیر آن را بدتر می‌کند.
| What you see | What it points at |
|---|---|
| No local prefix in the table | Missing route |
| Correct prefix, no reply | Client filter or gateway policy |
| Works by IP, fails by name | Resolver changed by the tunnel |
| Inbound service dies, outbound fine | Return path or listener binding |
پرسش یک: مسیر، فیلتر یا نام
پیش از افزودن چیزی، جدول را بخوانید. ایندکس رابط اهمیت دارد، چون هر فرمان مسیر زیر به آن لنگر انداخته است:
route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetricیک زیرشبکهٔ مستقیماً متصل معمولاً حتی وقتی تونل بالا است مسیر روی‌پیوند را نگه می‌دارد، پس ممکن است ورودی وجود داشته باشد و ترافیک باز هم شکست بخورد. این ترکیب امضای فیلتری است که پس از مسیریابی اجرا می‌شود، و همان حالتی است که مسیر دوم و مشخص‌تر هیچ چیزی را تغییر نمی‌دهد.
جداگانه با نشانی و با نام آزمایش کنید. اگر ping 192.168.1.50 پاسخ می‌دهد و net view 192.168.1.50 نه، جدول مسیریابی هرگز مشکل نبوده است: تونل resolver را عوض کرده و نام محلی دیگر حل نمی‌شود. افزودن مسیر برای آن کار هدررفته است.
پرسش دو: آیا دروازه به LAN محلی اجازه می‌دهد؟
کلاینت تجاری بیش از مسیرها نصب می‌کند. هنگام اتصال یک سیاست می‌گیرد، و آن سیاست می‌تواند اجازهٔ صریح شبکهٔ محلی داشته باشد. در استقرارهای Cisco IPsec سیاست گروه تنظیم split-tunneling و پرچم جداگانهٔ دسترسی به LAN محلی را حمل می‌کند؛ تیک داخل کلاینت درخواستی است که دروازه می‌تواند رد کند. در AnyConnect پروفایل فهرست‌های شمول و استثنای split و همان اجازه را کنترل می‌کند. در Windows RRAS معادل‌ها گزینهٔ دروازهٔ پیش‌فرض در پروفایل به‌همراه مسیرهای ثابتی است که سرور اختصاص می‌دهد.
وقتی پرچم خاموش است، رفتار مستند این است که کلاینت ترافیک به زیرشبکهٔ مستقیماً متصل را مسدود می‌کند حتی وقتی مسیر معتبر و مشخص‌تری وجود دارد. به همین دلیل هم مسیرهایی که مالکشان کلاینت نیست می‌تواند ثانیه‌هایی پس از افزودن ناپدید شود: کلاینت وضعیتی را که به او گفته شده بسازد بازمی‌سازد، نه اینکه با شما بجنگد.
گزارش کلاینت تصمیم را هنگام اتصال ثبت می‌کند، و خواندنش از هر آزمایشی روی ماشین سریع‌تر است. اگر گزارش می‌گوید دسترسی محلی مسدود است، بایستید: هیچ اصلاح خط فرمانی از آن جان سالم به در نمی‌برد، و تنها راه‌های باقی‌مانده تغییر سیاست، رسیدن به منبع از طریق تونل، یا نگه داشتن کلاینت در ماشین مجازی و گذاشتن میزبان روی شبکهٔ محلی است.
پرسش سه: به کدام جهت نیاز دارید؟
ترافیک خروجی به دستگاهی نزدیک پرسش مسیریابی است. پیشوند LAN را با متریکی به‌قدر کافی پایین به دروازهٔ محلی نشانه بگیرید تا مسیر پیش‌فرض تونل را شکست دهد:
route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -pشکل دوم یک دستگاه را میخکوب می‌کند، و همین را می‌خواهید وقتی تمام نیاز یک نشانی است. معادل netsh همان تصمیم را با نام رابط به‌جای ایندکس ثبت می‌کند:
netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistentفرمان‌های مسیر وقتی نشانی و ماسک همخوانی ندارند با پارامتر نادرست است شکست می‌خورند، مثلاً نشانی میزبان با ماسک /24. برای مسیر زیرشبکه از نشانی شبکه و برای یک میزبان از ماسک میزبان استفاده کنید.
ترافیک ورودی متفاوت است. سرور VNC یا SSH روی همان ماشین وقتی پاسخ‌های یک اتصال ورودی از دروازهٔ VPN خارج می‌شوند و هرگز برنمی‌گردند دسترسی‌ناپذیر می‌شود. پیش از دست زدن به مسیرها بررسی کنید سرویس روی چه چیزی گوش می‌دهد:
netstat -ano | findstr :5900شنونده‌ای که به یک نشانی مشخص بسته شده روی رابط دیگر پاسخ نمی‌دهد. بستن آن به همهٔ رابط‌ها تصمیمی آگاهانه است که همراه با قاعدهٔ دیوار آتش محدود به شبکه‌ای که به آن اعتماد دارید گرفته می‌شود. تنها پس از آن است که ترمیم مسیر مسیر بازگشت را برمی‌گرداند.
کوچک‌ترین تغییر سازگار را اعمال کنید
حرکت رایج دیگر برداشتن تیک «استفاده از دروازهٔ پیش‌فرض در شبکهٔ راه دور» در ویژگی‌های پیشرفتهٔ IPv4 است. این کار ترافیک اینترنت را محلی نگه می‌دارد، اما دو کار را همزمان می‌کند: VPN دیگر مسیر پیش‌فرض نیست، و کلاینت دیگر مسیرهایی برای شبکهٔ راه دور از جمله multicast دریافت نمی‌کند. تیک را بردارید و LAN راه دور ناپدید می‌شود مگر اینکه سرور پیشوندهای مشخص راه دوری را که هر کلاینت نیاز دارد هل بدهد.
این عدم تقارن ترتیب کار را تعیین می‌کند. اگر سمت راه دور باید کاملاً دسترس‌پذیر بماند، زیرشبکه‌های راه دور را از سرور هل بدهید و پیش‌فرض محلی را رها کنید. اگر نمی‌توانید سرور را عوض کنید، از طریق نشانی‌ای که تونل اختصاص داده یک مسیر پایدار به پیشوند راه دور اضافه کنید و با route print بررسی کنید که پیشوند به رابط VPN اشاره می‌کند در حالی که پیش‌فرض هنوز به دروازهٔ فیزیکی اشاره دارد.
سپس تأیید کنید که ترمیم از اتصال دوباره جان سالم به در می‌برد، چون مسیرهای ناپایدار با آداپتور می‌میرند و اسکریپتی که پس از هر اتصال اجرا می‌شود جای درست آن‌هاست. یک دستگاه محلی و یک منبع راه دور را در همان نشست آزمایش کنید، قطع کنید، دوباره وصل شوید و باز آزمایش کنید. اگر دستگاه محلی هنوز شکست می‌خورد در حالی که مسیر درست به نظر می‌رسد، به پرسش دوم برگردید: کلاینت فیلتر می‌کند و پاسخ تغییر سیاست است نه مسیر دوم رقیب.