شبکه محلی با اتصال VPN در دسترس نیست؟ چهار بررسی

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

نخست، جدول مسیریابی‌ای را که کلاینت نصب کرده ببینید

در حالی که VPN متصل است، جدول مسیریابی کلاینت را باز کنید. در لینوکس از ip route، در ویندوز از route print یا Get-NetRoute و در مک‌اواس از netstat -rn استفاده کنید. شما به دنبال یک مسیر پیش‌فرض از میان تونل و آنچه بر سر مسیر پیش‌فرض فیزیکی آمده هستید.

کلاینت تونل کامل غالباً دو مسیر نیمه‌پیش‌فرض، 0.0.0.0/1 و 128.0.0.0/1، اضافه می‌کند به‌جای آنکه 0.0.0.0/0 را جایگزین کند. مسیر پیش‌فرض اصلی هنوز دیده می‌شود اما هر جست‌وجو را از دست می‌دهد، و به همین دلیل جدول می‌تواند سالم به نظر برسد در حالی که تمام ترافیک بیرون از زیرشبکه جابه‌جا می‌شود. اگر کلاینت VPN گزینه تونل تقسیم‌شده را عرضه کند و سیاست اجازه دهد، آن پاک‌ترین تعمیر است.

اگر تونل باید مسیر پیش‌فرض بماند، به‌جای آن زیرشبکه محلی را سنجاق کنید. در لینوکس مسیر رابط فیزیکی و دروازه را نام می‌برد؛ در ویندوز -p را اضافه کنید تا پایدار بماند و شماره رابط را از route print بخوانید نه اینکه حدس بزنید:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

مسیر سنجاق‌شده تنها تا زمانی دوام می‌آورد که نشانی‌ای که نام می‌برد ثابت بماند. لپ‌تاپی که در هر اتصال آداپتور Wi-Fi خود را دوباره شماره‌گذاری می‌کند دوباره قاعده را می‌شکند، پس پیش از آنکه نتیجه بگیرید تعمیر شکست خورده، نشانی رابط را بررسی کنید.

دوم، تأیید کنید که نشانی از ابتدا محلی بوده است

اگر مقصد درون زیرشبکه متصل باشد، مسیر پیش‌فرض تونل هرگز اعمال نمی‌شود و VPN علت نیست. چاپگری با نشانی 192.168.1.40 در کلاینتی با 192.168.1.0/24 از مسیر متصل استفاده می‌کند؛ اگر آن نشانی کار نکند، به دستگاه، سوئیچ یا دیواره آتش روی کلاینت نگاه کنید نه به VPN.

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

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

سوم، ببینید اکنون چه کسی به نام‌ها پاسخ می‌دهد

حل‌کننده شرکتی اینترانت را می‌شناسد و معمولاً هیچ چیزی از نام میزبان NAS، نام Bonjour چاپگر یا نام مستعار محلی روتر نمی‌داند. وقتی VPN سرورهای DNS خود را هل می‌دهد، آن نام‌ها دیگر تفکیک نمی‌شوند هرچند نشانی‌هایشان هنوز در دسترس است. نام را مستقیم بپرسید و پاسخ را با نشانی‌ای که می‌دانید دستگاه دارد مقایسه کنید.

در لینوکس، resolvectl query nas.local نشان می‌دهد کدام حل‌کننده پاسخ داده است. در ویندوز، nslookup nas.local سرور را نام می‌برد و ipconfig /all ترتیب حل‌کننده‌ها را نشان می‌دهد. اگر پسوند محلی اکنون در اختیار حل‌کننده شرکتی است، یا آن پسوند را به حل‌کننده محلی برگردانید یا از نشانی IP دستگاه استفاده کنید.

کشف لایه‌ای جداست. mDNS و پخش از تونل مسیریابی‌شده عبور نمی‌کنند، پس دستگاه می‌تواند با نشانی در دسترس باشد در حالی که نامش نامرئی می‌ماند. بازتابنده یا یک ورودی DNS محلی این را حل می‌کند؛ مسیر حل نمی‌کند.

چهارم، بررسی کنید که دستگاه دیگر هم در VPN باشد

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

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

مسیری برای مدیریت نگه دارید که به تونل وابسته نباشد: مسیر ایستایی که شبکه مبدأ شما را نام می‌برد، رابط دیگری متصل به شبکه محلی، یا کنسولی که تونل را کاملاً دور می‌زند. طراحی آن مسیر پس از افتادن نشست بسیار دشوارتر از افزودنش پیش از اتصال بعدی است.

تعمیری را به کار ببرید که با بررسی شکست‌خورده می‌خواند

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

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

مسیر، نشانی و حل‌کننده‌ای را که هنگام اتصال VPN کار می‌کردند بنویسید. اتصال بعدی دست‌کم یکی از آن‌ها را تغییر می‌دهد و یادداشت، قطعی بعدی را به جای تحقیقی تازه به مقایسه‌ای کوتاه تبدیل می‌کند.