آموزش راه‌اندازی Failover اینترنت در میکروتیک RouterOS v7

سناریو و پیش‌نیازهای Failover

در نمونه زیر، لینک اول اینترنت اصلی و لینک دوم اینترنت پشتیبان است. نام Interfaceها را با نام واقعی روتر خود جایگزین کنید.

آدرس‌های بالا مستنداتی و نمونه‌اند. Gateway واقعی را از مودم، سرویس‌دهنده یا خروجی DHCP Client دریافت کنید. پیش از تغییر Route، با دستورهای /ip address print، /ip dhcp-client print detail و /ip route print detail وضعیت فعلی را ثبت کنید.

روش ساده: Check Gateway

اگر Gateway هر لینک مستقیماً وضعیت واقعی اینترنت را نشان می‌دهد، می‌توان دو Default Route با Distance متفاوت تعریف کرد:

/ip route
add dst-address=0.0.0.0/0 gateway=192.0.2.1 distance=1 check-gateway=ping comment="WAN1 primary"
add dst-address=0.0.0.0/0 gateway=198.51.100.1 distance=2 check-gateway=ping comment="WAN2 backup"

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

روش پیشنهادی: Recursive Routing

برای بررسی اینترنت بالادست، به‌جای Ping کردن فقط Gateway، دو مقصد پایدار و مستقل را از مسیر مشخص هر WAN بررسی می‌کنیم. سپس Default Route به آن مقصدهای مانیتورینگ وابسته می‌شود.

۱. مسیر Host برای Probe هر لینک

/ip route
add dst-address=1.1.1.1/32 gateway=192.0.2.1 scope=10 comment="WAN1 probe"
add dst-address=8.8.8.8/32 gateway=198.51.100.1 scope=10 comment="WAN2 probe"

۲. Default Routeهای Recursive

/ip route
add dst-address=0.0.0.0/0 gateway=1.1.1.1 distance=1 target-scope=11 check-gateway=ping comment="WAN1 recursive default"
add dst-address=0.0.0.0/0 gateway=8.8.8.8 distance=2 target-scope=11 check-gateway=ping comment="WAN2 recursive default"

scope و target-scope باید به شکلی تنظیم شوند که Next Hop بازگشتی قابل Resolve باشد. پس از ثبت Routeها، در خروجی /ip route print detail بررسی کنید Default Route اصلی Active باشد و Next Hop آن به Route میزبان مربوط به WAN1 برسد.

کاهش خطای تشخیص

اتکا به یک IP عمومی ممکن است به دلیل اختلال موقت همان مقصد، Failover کاذب ایجاد کند. در شبکه‌های حساس، برای هر WAN بیش از یک Probe و یک منطق کنترلی طراحی می‌شود. انتخاب مقصد Probe باید با سیاست امنیتی سازمان، محدودیت سرویس‌دهنده و رفتار ICMP مقصد هماهنگ باشد.

تنظیم NAT برای هر دو اینترنت

اگر WANها IP پویا دارند، برای هر Interface یک قانون Masquerade مشخص بسازید:

/ip firewall nat
add chain=srcnat out-interface=ether1-WAN1 action=masquerade comment="NAT via WAN1"
add chain=srcnat out-interface=ether2-WAN2 action=masquerade comment="NAT via WAN2"

برای IP ثابت، استفاده از src-nat با آدرس مشخص معمولاً قابل‌کنترل‌تر است. ترتیب Ruleها را بررسی کنید تا یک قانون عمومی قبل از Ruleهای WAN قرار نگرفته باشد.

DNS

Failover Route به‌تنهایی مشکل DNS را حل نمی‌کند. اگر کلاینت‌ها از DNS داخلی یا DNS روتر استفاده می‌کنند، دسترسی DNS از هر دو WAN را آزمایش کنید. برای عیب‌یابی، Ping با IP و Resolve نام دامنه را جداگانه بسنجید؛ ممکن است اینترنت برقرار باشد اما DNS پاسخ ندهد.

روش صحیح آزمایش Failover

1. قبل از قطع لینک، خروجی Routeها و Connection Tracking را ثبت کنید.
2. یک Ping مداوم به IP عمومی و یک تست Resolve نام دامنه اجرا کنید.
3. کابل WAN1 را قطع یا Interface آن را موقتاً Disable کنید.
4. زمان تغییر Route و فعال‌شدن WAN2 را اندازه بگیرید.
5. مرور وب، DNS، VPN و سرویس‌های حساس را جداگانه تست کنید.
6. WAN1 را برگردانید و بازگشت خودکار به Route اصلی را بررسی کنید.

/ip route print detail where dst-address=0.0.0.0/0
/tool ping 1.1.1.1 count=20
/tool traceroute 1.1.1.1
/ip firewall connection print count-only

چرا Sessionهای قبلی قطع می‌شوند؟

وقتی Public IP با تغییر WAN عوض می‌شود، بسیاری از Sessionهای موجود مانند VPN، تماس VoIP یا دانلود طولانی باید دوباره برقرار شوند. این رفتار الزاماً خطای Route نیست. Connection Tracking و NAT Session قبلی به مسیر و IP قبلی وابسته‌اند. طراحی High Availability بدون قطع Session نیازمند معماری متفاوت، IP مستقل یا راهکارهای سمت سرویس‌دهنده است.

خطاهای رایج

• هر دو Default Route با Distance یکسان ثبت شده‌اند و ناخواسته ECMP ایجاد شده است.
• DHCP Client یک Default Route خودکار اضافه کرده و با Routeهای دستی تداخل دارد.
• فقط Gateway مودم بررسی می‌شود، نه اینترنت بالادست.
• NAT برای WAN دوم تعریف نشده است.
• FastTrack یا Policy Routing باعث می‌شود بخشی از ترافیک مسیر مورد انتظار را طی نکند.
• برای VPN یا سرویس ورودی، مسیر برگشت متقارن نیست.

چه زمانی Netwatch یا Script لازم است؟

Recursive Route برای بسیاری از شبکه‌ها کافی و قابل‌پیش‌بینی است. Netwatch زمانی مفید است که علاوه بر تغییر مسیر، نیاز به ثبت Log، ارسال اعلان، کنترل چند Probe، تغییر DNS یا اجرای اقدام جانبی دارید. Script باید idempotent باشد؛ یعنی اجرای دوباره آن وضعیت Routeها را خراب نکند. همچنین دسترسی Script را حداقلی نگه دارید و به‌جای حذف و ایجاد مداوم Routeها، Routeهای مشخص را Enable یا Disable کنید.

برای شبکه‌های دارای چند جدول Routing، VPN، PCC یا Policy Routing، Failover باید در هر جدول و Rule مرتبط طراحی شود. Default Route در جدول main به‌تنهایی تضمین نمی‌کند ترافیک علامت‌گذاری‌شده مسیر پشتیبان داشته باشد.

چک‌لیست تحویل

• Route اصلی و پشتیبان نام‌گذاری و مستند شده‌اند.
• تست قطع Gateway و قطع اینترنت بالادست انجام شده است.
• NAT، DNS، VPN و سرویس‌های ورودی روی هر دو WAN آزمایش شده‌اند.
• زمان Failover و Failback ثبت شده است.
• نسخه پشتیبان تنظیمات و Export متنی روتر نگهداری می‌شود.

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