روتر در حالت کلاینت VPN: چرا دستگاه‌های LAN ناپدید می‌شوند
دستگاه‌های LAN پس از ورود روتر به حالت کلاینت VPN ناپدید می‌شوند: نخست ویژگی بازرسی مسیر ارسال را آزمایش کنید، سپس محدوده LAN را که firmware زیر پای شما تغییر داده است.
این باور که خود حالت کلاینت دسترسی LAN را از بین می‌برد، مردم را به منوی تنظیمات اشتباه می‌فرستد، و علت‌های واقعی معمولاً دو تاست. تونل پل LAN را حذف نمی‌کند و مانع دسترسی کلاینت‌های سیمی و بی‌سیم به یکدیگر نمی‌شود. آنچه دسترسی محلی را می‌شکند یا ویژگی بازرسی در مسیر ارسال روتر است یا محدوده نشانی LAN که هنگام تغییر firmware جابه‌جا شد. هر دو همان شکایت را تولید می‌کنند و هیچ‌کدام با نصب دوباره پروفایل VPN درست نمی‌شود.
افسانه، و اینکه حالت کلاینت واقعاً چه چیزی را تغییر می‌دهد
حالت کلاینت یک واسط تونل و یک مسیر پیش‌فرض که از آن می‌گذرد اضافه می‌کند، و سپس ترافیک LAN را به آن تونل ارسال می‌کند. پل میان درگاه‌های سیمی و رادیوهای بی‌سیم دست‌نخورده می‌ماند، و همچنین سوئیچینگ محلی. آنچه تغییر می‌کند سیاست است: کدام ترافیک ارسال می‌شود، کجا ترجمه می‌شود و کلاینت‌ها کدام resolver را دریافت می‌کنند.
این تمایز مهم است زیرا LAN خراب معمولاً یعنی یکی از آن سه سیاست تغییر کرده، نه اینکه روتر دیگر سوئیچ نباشد. روتری که هنوز به صفحه مدیریت خودش پاسخ می‌دهد مدرکی است بر زنده بودن واسط LAN. روتری که به هیچ چیز پاسخ نمی‌دهد مشکل دیگری دارد، مانند نشانی LAN تغییرکرده یا کلاینتی در زیرشبکه اشتباه.
پس نخستین گام مفید یافتن لایه‌ای است که شکسته، نه تغییر لایه‌ای که به آن مشکوک هستید.
پیش از دست زدن به هر تنظیم، سه هدف را آزمایش کنید
از یک کلاینت سیمی سه هدف را جداگانه آزمایش کنید و هر نتیجه را بنویسید: نشانی LAN خود روتر، دستگاه دیگری روی همان سوئیچ بر اساس IP، و چیزی که فقط از طریق تونل قابل دسترسی است. به این ترتیب انجام دهید، زیرا هر نتیجه لایه متفاوتی را کنار می‌گذارد. در دور اول از نشانی به جای نام استفاده کنید، چون شکست نام DNS را با پرسش اتصال مخلوط می‌کند.
الگوی پاسخ‌ها همان تشخیص است. روتری که پاسخ می‌دهد در حالی که دستگاه‌های محلی پاسخ نمی‌دهند به سوئیچینگ محلی یا ویژگی فیلتر اشاره می‌کند، نه به مسیریابی. دستگاه‌های محلی که پاسخ می‌دهند در حالی که سمت تونل پاسخ نمی‌دهد به مسیر تونل یا فایروال دور اشاره می‌کنند. اگر همه با نشانی پاسخ دهند اما نام‌ها شکست بخورند، مسئله resolver است و هیچ ویرایش مسیری آن را درست نمی‌کند.
| What answers | What it points at |
|---|---|
| Router only | LAN-side filtering or a broken bridge |
| Router and local hosts, not remote | Tunnel route, NAT or remote firewall |
| Addresses yes, names no | DNS handed to clients by the router |
| Nothing at all | Client subnet or router LAN address changed |
جدول را کنار نتایج آزمایش نگه دارید. شکایت مبهم را به یک خط قابل اقدام تبدیل می‌کند.
لایه امنیتی درون مسیر ارسال
روترهای مصرفی به‌طور فزاینده ویژگی بازرسی دارند که ترافیک ارسال‌شده را می‌پاید، و در همان مسیری اجرا می‌شود که بسته‌های LAN به تونل را حمل می‌کند. وقتی آن بازرسی نمی‌تواند ترافیک تونل را طبقه‌بندی کند، ارسال می‌تواند متوقف شود در حالی که خود تونل برپاست و روتر اتصال سالم گزارش می‌کند. هیچ چیز در گزارش VPN این را نشان نمی‌دهد، زیرا VPN واقعاً متصل شد.
تشخیص یک آزمایش کنترل‌شده است، نه تغییر دائمی. تنظیم کنونی را یادداشت کنید، ویژگی را برای مدت یک آزمایش خاموش کنید، تونل را دوباره برپا کنید و یک میزبان محلی را با نشانی آزمایش کنید. ارسالی که بازمی‌گردد همان مدرکی است که نیاز داشتید، و آنگاه مصالحه به تصمیم تبدیل می‌شود نه حدس. اگر چیزی تغییر نکرد، بی‌درنگ دوباره فعالش کنید و به علت نشانی‌دهی بروید.
خاموش گذاشتن یک ویژگی امنیتی پولی تا تونل کار کند مصالحه‌ای است که باید آگاهانه انجام و نوشته شود. همچنین ارزش دارد بپرسید آیا تونل به دستگاه دیگری تعلق دارد، زیرا روتری که باید همه چیز را بازرسی کند و روتری که باید همه چیز را ارسال کند دو کار متفاوت‌اند.
علت دوم: محدوده LAN جابه‌جا شد
به‌روزرسانی‌های firmware به‌طور معمول نشانی LAN را به پیش‌فرض سازنده بازمی‌گردانند، و برخی روترها کلید حالت صریحی دارند که تعیین می‌کند LAN محدوده خصوصی را نگه می‌دارد یا یکی را از دستگاه بالادست به ارث می‌برد. کلاینتی که انتظار 192.168.8.x دارد ممکن است روی 10.64.0.x بیفتد، و آنگاه نشست SSH به یک میزبان منقضی می‌شود هرچند تونل کاملاً سالم است.
ipconfig /all
ip addr show
ip route get 192.168.8.20پیش از باز کردن صفحه روتر، پیشوند و درگاه را از اجاره بخوانید. دو فرمان نخست نشان می‌دهند کلاینت واقعاً چه دریافت کرده، و سوم نشان می‌دهد کلاینت برای نشانی محلی از کدام واسط استفاده می‌کرد، و این‌گونه مسیر باقی‌مانده یا زیرشبکه کهنه خود را نشان می‌دهد. سپس آن را با صفحه LAN و حالتی که روتر در آن است مقایسه کنید.
اگر محدوده نمی‌تواند برگردد، هر شیئی را که آن را نام می‌برد به‌روزرسانی کنید: رزروهای DHCP، هر مسیر ایستا به زیرشبکه قدیم، و هر قاعده فایروال که پیشوند پیشین را دارد. محدوده‌ای که با زیرشبکه دور تونل برخورد می‌کند گونه بدتر است، زیرا دستگاه‌های محلی در دسترس می‌مانند در حالی که مقصدهای دور بی‌صدا به LAN مسیریابی می‌شوند.
دوباره وصل شوید و به ترتیب بسته آزمایش کنید
پس از هر یک از دو تغییر، تونل را دوباره وصل کنید و آزمایش‌ها را به ترتیب بسته تکرار کنید: روتر، میزبان محلی، میزبان دور، سپس نام‌ها، سپس برنامه. آزمایش برنامه در ابتدا پنهان می‌کند کدام لایه هنوز شکسته است، و تلاش دوباره مرورگر روی نام کش‌شده می‌تواند مانند خطای مسیریابی به نظر برسد.
نسخه firmware، پیشوند LAN و وضعیت ویژگی بازرسی را کنار پروفایل VPN بنویسید. هر سه تنظیماتی هستند که به‌روزرسانی بعدی ممکن است بازنویسی کند، و دو خط یادداشت ساعتی را که همین حالا گذراندید ذخیره می‌کند.