هیچ مسیری مخزن VPN را که با LAN شما همپوشانی دارد درست نمی‌کند
وقتی مخزن تونل و LAN خانه هر دو 192.168.1.0/24 را به اشتراک می‌گذارند، زیرشبکه محلی برنده می‌شود. طرفی را که کنترل می‌کنید دوباره شماره‌گذاری کنید یا بازه دوردست را ترجمه کنید.
برنامه ادعا می‌کند تونل سالم است، و با این حال نیمی از مقصدهایی که لازم دارید هرگز پاسخ نمی‌دهند. واکنش اولیه افزودن یک مسیر یا کم کردن یک متریک است، و همین واکنش همان افسانه‌ای است که باید اول کشته شود. وقتی LAN خودِ کلاینت و مخزن تونل هر دو یک پیشوند را ادعا می‌کنند، جدول مسیریابی دو واقعیت ناسازگار را نگه می‌دارد، و نه یک مسیر پیش‌فرض و نه یک متریک آنها را حل نمی‌کند. این تعمیر یک تصمیم آدرس‌دهی است، و هیچ ویرایش مسیری جای آن را نمی‌گیرد.
چرا یک مسیر اضافه نمی‌تواند یک پیشوند را تقسیم کند
یک مسیر نمی‌تواند دو ادعا روی یک پیشوند را جدا کند، به همین دلیل حرکت معقول این است که جست‌وجو برای خط مسیر درست را متوقف کنید. پشته یک پیشوند یکسان را جلوی مسیر متصل قرار نمی‌دهد، و یک ورودی دقیق‌تر آدرس را می‌گیرد، اما میزبان محلی که صاحب آن است را غیرقابل دسترسی می‌کند. آنچه شبیه مشکل مسیریابی به نظر می‌رسد برخورد آدرس‌دهی است، و هر دو تعمیر آدرس‌ها را عوض می‌کنند نه مسیرها. این ادعا را پیش از پذیرش روی دستگاه خودتان آزمایش کنید.
ip route get 192.168.1.50
route -n get 192.168.1.50
Find-NetRoute -RemoteIPAddress 192.168.1.50از سیستم درباره یک آدرس بپرسید و توجه کنید کدام رابط را نام می‌برد. Linux، macOS و Windows هر کدام با جست‌وجویی فقط‌خواندنی پاسخ می‌دهند که رابط انتخاب‌شده و پرش بعدی را گزارش می‌کند بدون آنکه چیزی بفرستد. وقتی پاسخ در حالی که تونل بالاست به آداپتور فیزیکی اشاره می‌کند، هسته آدرس را به‌عنوان روی پیوند در نظر می‌گیرد نه چیزی که تونل می‌توانست حمل کند.
پیشوندی که ارائه‌دهنده داده است را کنار پیشوندی که روتر خانه سرویس می‌دهد بگذارید و آنها را به‌صورت رشته مقایسه کنید. تطابق دقیق حالت روشن است، و مخزن گسترده‌تر ارائه‌دهنده که زیرشبکه خانه را در بر می‌گیرد هم به همان شکل شکست می‌خورد، با این تفاوت که دیدنش سخت‌تر است. دو پیشوند که فقط شبیه هم به نظر می‌رسند برخورد نیستند، پس پیش از تغییر هر چیزی هر دو را بنویسید.
مخزنی را بخوانید که کلاینت واقعا گرفت
آنچه کلاینت دریافت کرده را بخوانید، نه صفحه بازاریابی ارائه‌دهنده را. سطح جزئیات گزارش یک کلاینت OpenVPN را بالا ببرید تا مسیرهایی که سرور هُل می‌دهد در آن دیده شوند و پیشوندهای تونل را آشکار کنند؛ در جای دیگر مخزن در جزئیات اتصال یا روی خود آداپتور دیده می‌شود. از ارائه‌دهنده فهرست کامل بازه‌های خصوصی که استفاده می‌کند را بخواهید، چون یک /24 امروز می‌تواند فردا دو تا باشد. پرهیز از بلوک‌های رایج RFC 1918 با پرهیز از تخصیصی که واقعا گرفته‌اید یکی نیست.
مخزن می‌تواند کوچک شود یا بین مناطق جابه‌جا شود، پس فهرست به تاریخ و مسئول نیاز دارد. هر پاسخ ارائه‌دهنده که قدیمی‌تر از آخرین تغییر طرح شماست را گمانه بگیرید، نه واقعیت. پیش از تعهد به یک بازه دوباره بپرسید، و پاسخ را همراه یادداشت‌های شبکه نگه دارید تا نفر بعدی شواهد را به ارث ببرد.
شماره‌گذاری مجدد همان تعمیری است که می‌توانید انجام دهید
اگر سرور VPN مال شما نیست که تغییرش دهید، جابه‌جا کردن LAN خانه تنها تعمیر موجود است، و این وضعیت معمول با یک ارائه‌دهنده تجاری است. بازه‌ای بیرون از مخزن ارائه‌دهنده و بیرون از بازه‌هایی که ممکن است بعدا لازم شوند انتخاب کنید، و آن را با هر سایت دیگری که از راه تونل به آن می‌رسید بسنجید. انتظار یک قطعی کوتاه و دُمی طولانی‌تر از دستگاه‌های فراموش‌شده را داشته باشید: دستگاهی که هنوز آدرس قدیمی را دارد تا وقتی به دروازه نیاز پیدا کند سالم به نظر می‌رسد.
- اول فهرست‌برداری: آدرس خود روتر، محدوده DHCP، رزروها، انتقال‌های پورت و هر دستگاهی که آدرسش با دست تایپ شده است.
- سپس پیشوند LAN روتر و محدوده DHCP را با هم در یک پنجره نگهداری عوض کنید، و اجاره‌های سیمی را پیش از بی‌سیم تمدید کنید.
- بعد آدرس‌های ثابت را اصلاح کنید: چاپگرها، ذخیره‌سازی شبکه، هر چیزی با دروازه ثابت‌شده.
- در پایان کلاینت VPN را دوباره وصل کنید و تأیید کنید که آدرس تونل دیگر با LAN برخورد ندارد.
آدرس‌ها را به همین ترتیب پیش ببرید نه همه با هم، و بازه قدیمی را مدتی مستند نگه دارید تا دستگاه کهنه شناخته‌شده باشد نه مرموز. دستگاهی که هرگز تمدید نمی‌کند با نرسیدن به دروازه خود را اعلام می‌کند، که سرنخ بسیار بهتری از یک تماس با پشتیبانی است. اگر روتر اجاره‌هایی بیش از یک روز می‌دهد، آنها را برای مدت پنجره کوتاه کنید.
یک نام مستعار چه می‌تواند بکند و چه نمی‌تواند
وقتی سرور مال شماست، ترجمه آدرس‌ها روی کلاینت می‌تواند پیشوند دوردست را درون یک بازه محلی آزاد آشکار کند، به‌گونه‌ای که همان میزبان روی آدرس دومی پاسخ می‌دهد. OpenVPN جامعه از این دستور استفاده می‌کند: client-nat، و این دستور مخصوص همان کلاینت است و در کلاینت‌های تجاری و موبایلی که معمولا با آن مقایسه می‌شود وجود ندارد. این ترتیب به مسیری منطبق با ترجمه، بازه‌ای آزاد برای نام مستعار و سروری نیاز دارد که حاضر باشد به آدرس ترجمه‌نشده کلاینت پاسخ دهد. هیچ‌یک از اینها وقتی کلاینت به ارائه‌دهنده مدیریت‌شده‌ای تعلق دارد که نمی‌توانید پیکربندی کنید کمکی نمی‌کند.
وقتی تغییر اعمال شد، ابتدا با آدرس و سپس با نام به یک میزبان محلی و یک میزبان دوردست برسید و مسیری را که سیستم هر بار انتخاب می‌کند یادداشت کنید. یک نام ممکن است هنوز به بازه قدیمی تجزیه شود، پس آدرس‌ها و نام‌ها بررسی‌های جداگانه می‌خواهند. اگر یکی از آنها در طول تغییر روشن ماند، یک کلاینت و یک دستگاه سمت سرور را دوباره راه‌اندازی کنید، چون ورودی‌های همسایه کش‌شده از ویرایش بیشتر عمر می‌کنند.
پیشوندهایی که بر آنها توافق کرده‌اید را جایی بنویسید که مردم واقعا نگاه می‌کنند: یادداشت‌های شبکه، فیلد کامنت خود روتر، صفحه آشنایی. کسی دوباره 192.168.1.0/24 را انتخاب می‌کند، و برخورد با او برمی‌گردد.