چگونه سیاست انتقال خودکار VPN روی روتر را بدون نشت بسازیم
تصمیم بگیرید ترافیک وقتی تونل ترجیحی قطع می‌شود چه کند: تونل پشتیبان، WAN معمولی یا مسدودسازی۔ سپس آن را روی روتر بسازید و آزمایش کنید۔
انتقال خودکار دقیقاً همان‌طور که پیکربندی شده بود کار کرد و همین مشکل بود۔ وقتی تونل اصلی قطع شد، روتر مسیر پیش‌فرض را به مودم کابلی منتقل کرد، لپ‌تاپ‌ها به مرور ادامه دادند و هیچ‌کس زنگ نزد۔ دو روز بعد کسی متوجه شد که پوشه اشتراکی مالی شش ساعت از مسیر باز اینترنت در دسترس بوده است۔ سیاست انتقال خودکار VPN روی روتر یک ترفند مسیریابی نیست؛ تصمیمی است درباره اینکه ترافیک وقتی مسیر ترجیحی رفته چه کند، و این تصمیم باید پیش از ناپدید شدن مسیر وجود داشته باشد۔
پیش از انتخاب آشکارساز، نتیجه را مشخص کنید
معمولاً سه نتیجه روی میز است: فرستادن کلاینت‌های آسیب‌دیده از تونل پشتیبان، اجازه دادن به آن‌ها برای استفاده از WAN معمولی، یا مسدود کردن کامل آن‌ها۔ بنویسید کدام برای کدام VLAN، SSID یا کلاس دستگاه اعمال می‌شود۔ یک قاعده تخت «رفتن به WAN» همان چیزی است که پوشه مالی بالا را به مسیر عمومی کشاند۔
این سه قابل جایگزینی نیستند۔ پشتیبان WAN میز پشتیبانی را پشت تلفن نگه می‌دارد اما نام‌های داخلی را به resolver محلی آشکار می‌کند۔ تونل پشتیبان سیاست را حفظ می‌کند اما ممکن است روی نشانی خروجی فرود بیاید که طرف مقابل نمی‌پذیرد۔ مسدودسازی برای VLAN حقوق و دستمزد درست و برای شبکه مهمان که هرگز از تونل استفاده نکرده غلط است۔
| نتیجه | مناسب برای | چه چیزی می‌شکند |
|---|---|---|
| تونل پشتیبان | سیاست باید برقرار بماند، دسترسی از راه دور لازم است | نشانی خروجی جدید، مسیر بازگشت، تجدید کلید کندتر |
| WAN معمولی | ترافیک مهمان یا فقط عمومی | نام‌های داخلی، افشای DNS و IPv6 |
| مسدودسازی | حقوق و دستمزد، مدیریت، هر چیز فقط-VPN | کاربران همه دسترسی را از دست می‌دهند و به شما زنگ می‌زنند |
آشکارساز را با خرابی‌ای که واقعاً از آن می‌ترسید هم‌تراز کنید
وضعیت دست‌دادن، وضعیت رابط و ارسال قابل استفاده سه سیگنال متفاوت‌اند و برای کاربر فقط آخری اهمیت دارد۔ یک همتای WireGuard می‌تواند دست‌دادن تازه نشان دهد در حالی که بالادست ارائه‌دهنده بسته‌ها را به چاه سیاه می‌ریزد۔ OpenVPN کلاینت می‌تواند پس از اینکه مسیری که هل داده بود دیگر حل نشد، روی «متصل» بماند۔
در pfSense چیدمان عملی یک گروه دروازه است که dpinger آن را تغذیه می‌کند؛ آدرس پایش را بررسی می‌کند و وقتی افت یا تأخیر از آستانه‌هایش می‌گذرد، دروازه را پایین علامت می‌زند۔ آن پایش را به چیزی فراتر از تونل نشانه بگیرید، مثل میزبان در LAN دور یا نشانی عمومی که از طریق آن به آن می‌رسید۔ نشانه گرفتن آن به نشانی همتای خود تونل، همان بخشی را می‌سنجد که می‌دانید زنده است۔
گروه را طوری بسازید که پشتیبان آخرین راه بماند
از لایه‌ها به جای یک فهرست اعضای تخت استفاده کنید۔ اصلی در لایه 1، تونل پشتیبان در لایه 2، WAN در لایه 3 فقط برای VLANهایی که سیاستشان اجازه می‌دهد۔ در pfSense این زیر System > Routing > Gateway Groups است: هر دو دروازه را اضافه کنید، لایه‌های متفاوت بدهید، Trigger Level را روی member down plus packet loss بگذارید، ذخیره کنید و سپس گروه را به عنوان پیش‌فرض رابط یا در فیلد Gateway قواعد فایروال که به آن نیاز دارند اعمال کنید۔
برای نمونه کلاینت OpenVPN در pfSense 2.5 و بالاتر، تنظیم Default Gateway نمونه تعیین می‌کند که آیا تونل اصلاً مسیر پیش‌فرض سیستم را جایگزین می‌کند۔ مسیریابی سیاستی بر اساس قاعده فقط زمانی آن‌طور که انتظار دارید رفتار می‌کند که مسیری که فرض می‌کنید وجود دارد واقعاً نصب شده باشد۔ پس از تغییر Status > Gateways را بررسی کنید، نه اینکه به نماد وضعیت تونل اعتماد کنید۔
دو تنظیم بیشترین لرزش را ایجاد می‌کنند۔ یکی فاصله پایش کوتاه‌تر از همگرایی مجدد خود ارائه‌دهنده است۔ دیگری گروهی است که اصلی و پشتیبان لایه را شریک می‌شوند، پس هر دو همیشه واجد شرایط می‌مانند۔ پیش از آنکه کاربران‌تان گذارها را به جای شما حس کنند، با آستانه‌های افت و تأخیر هیسترزیس اضافه کنید۔
مسیرهایی را ببندید که تونل هرگز مالک آن‌ها نبود
ابتدا نشت‌های DNS۔ resolver همچنان روی WAN پاسخ می‌دهد و از آن بیرون می‌فرستد، پس نام‌ها همچنان از طریق ISP حل می‌شوند در حالی که ترافیک به تونل سنجاق شده است۔ رابط‌های خروجی resolver را محدود کنید، resolver داخلی را به کلاینت‌ها بفرستید و پورت 53 را برای هر چیز دیگری در VLANهای فقط-VPN ببندید۔
IPv6 تصمیم خودش را می‌خواهد۔ یک LAN دوپشته می‌تواند تونل را از دست بدهد و یک مسیر پیش‌فرض جهانی IPv6 کارا نگه دارد، پس مرورگرها IPv6 را ترجیح می‌دهند و از WAN بیرون می‌روند در حالی که IPv4 کاملاً مهارشده به نظر می‌رسد۔ یا IPv6 را به تونل مسیریابی کنید یا تا وقتی تونل پایین است تبلیغ پیشوند جهانی را متوقف کنید۔ نیمی از سیاست از هیچ بدتر است، چون به نظر می‌رسد کار می‌کند۔
سپس مسیر بازگشت۔ اگر خروجی پشتیبان نشانی مبدأ متفاوتی داشته باشد، طرف مقابل باید بداند چگونه ترافیک را به آن بازگرداند، و هر وضعیتی که به نشانی قدیمی گره خورده باشد از قبل مرده است۔ نشست‌هایی که هنگام افتادن اصلی باز بودند مهاجرت نمی‌کنند؛ تا وقتی منقضی شوند متوقف می‌مانند و برنامه تصمیم می‌گیرد چه کند۔
افتادن، لرزش و راه بازگشت را آزمایش کنید
اصلی را با ترافیک بی‌خطر در حال اجرا بکشید، سپس چهار چیز بخوانید: Status > Gateways برای وضعیت اعضای گروه، pfctl -ss برای وضعیت‌هایی که هنوز به دروازه قدیمی سنجاق شده‌اند، یک traceroute از کلاینت برای مسیر خروج، و یک پرس‌وجوی resolver برای دیدن اینکه کدام سرور پاسخ داد۔
حالا آن را بلرزانید۔ اصلی را سی ثانیه بالا، سی ثانیه پایین، دو بار۔ اگر ترافیک هر گذار را دنبال می‌کند، آستانه‌ها خیلی تنگ‌اند یا لایه‌ها غلط‌اند۔ این را طبق برنامه خودتان درست کنید، چون در غیر این صورت ارائه‌دهنده طبق برنامه خودش این کار را می‌کند۔
آخر، تأیید کنید که هنوز می‌توانید روتر را مدیریت کنید۔ یک مسیر خارج از باند مثل کابل کنسول، VLAN مدیریت یا مودم سلولی نگه دارید۔ آزمون انتقالی که شما را بیرون قفل می‌کند آزمونی است که نمی‌توانید تمام کنید، و روتر دسترس‌ناپذیر نمی‌تواند خودبه‌خود بازگردد۔
پیش از اینکه سیاست را تمام‌شده بنامید، باید بدون باز کردن ترمینال به چهار پرسش پاسخ دهید: کدام VLANها می‌توانند تا وقتی تونل پایین است از WAN استفاده کنند، آشکارساز چه چیزی را می‌پاید و چه مدت صبر می‌کند، کدام سرورهای نام و مسیرهای IPv6 با مسیر جابه‌جا می‌شوند، و اگر پشتیبان هم شکست بخورد چگونه برمی‌گردید۔ اگر هر پاسخی «هر چه پیش‌فرض بود» باشد، سیاست هنوز به روتر تعلق دارد نه به شما۔