فِیلوور خودکار WAN در RouterOS؛ check-gateway و مسیر بازگشتی

در دفتر سایت با دو اینترنت، «قطع شده» تقریباً هیچ‌وقت یعنی لینک قطع است؛ یعنی اینترفیس WAN همچنان بالاست ولی مسیر واقعی اینترنت مرده. روتر هم خیالش راحت است که همه‌چیز سرجایش است. علاجش این است که مسیر را وادار کنید «دسترسی واقعی» را تست کند — و اگر جدی می‌خواهید، با مسیرهای بازگشتی (recursive) فِیلوور را به یک آدرس عمومی گره بزنید، نه به گیت‌وی محلی.

۱) روش ساده: دو مسیر پیش‌فرض و check-gateway

هر روتر با دو WAN باید دو مسیر پیش‌فرض داشته باشد؛ فقط distance تعیین می‌کند کدام اول بیاید. ترفند اصلی این است که روی هر دو مسیر check-gateway=ping بگذارید تا مسیر به‌محض بی‌پاسخ‌ماندن گیت‌وی غیرفعال شود:

/ip route
add dst-address=0.0.0.0/0 gateway=10.0.0.1 distance=1 check-gateway=ping comment="WAN1"
add dst-address=0.0.0.0/0 gateway=10.0.1.1 distance=2 check-gateway=ping comment="WAN2"

تا وقتی WAN1 زنده است، ترافیک از مسیر با distance=1 می‌رود؛ اگر پینگ گیت‌وی WAN1 بخورد زمین، RouterOS مسیر را غیرفعال می‌کند و همه‌چیز خودبه‌خود روی distance=2 می‌افتد. وقتی WAN1 برگشت، مسیر اول دوباره فعال می‌شود.

ضمناً check-gateway=arp برای لینک‌های PPPoE و VPN کار نمی‌کند، چون گیت‌وی آن‌جا روی یک واسط نقطه‌به‌نقطه است و ARP معنا ندارد. برای PPPoE همان ping درست است.

۲) روش حرفه‌ای: مسیرهای بازگشتی به یک آدرس عمومی

برای اینکه فِیلوور واقعاً به «زنده‌بودن اینترنت» گره بخورد، گیت‌وی مسیر پیش‌فرض را خودِ گیت‌وی محلی نگذارید؛ یک آدرس عمومی پایدار بگذارید (مثلاً DNS عمومی) و به روتر بگویید آن آدرس را از هر ISP چطور می‌رسد:

/ip route
# "server" routes: how to reach the public address via each ISP
add dst-address=1.1.1.1/32 gateway=10.0.0.1 scope=10 target-scope=10 comment="server via WAN1"
add dst-address=1.0.0.1/32 gateway=10.0.1.1 scope=10 target-scope=10 comment="server via WAN2"

# default routes that use those public addresses as their gateway
add dst-address=0.0.0.0/0 gateway=1.1.1.1 distance=1 scope=30 target-scope=11 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=1.0.0.1 distance=2 scope=30 target-scope=11 check-gateway=ping

حالا check-gateway یک آدرس بیرونی را پینگ می‌کند، نه گیت‌وی محلی. اگر ISP1 با اینکه گیت‌وی‌اش جواب می‌دهد به 1.1.1.1 نرسد، مسیر پیش‌فرض اول غیرفعال می‌شود و ترافیک از WAN2 می‌رود.

۳) قبل از رفتن روی سایت، تست کنید

فقط پیاده‌سازی نکنید و بروید؛ همان‌جا با چند دستور رفتار واقعی را ببینید:

/ip route print where dst-address=0.0.0.0/0
# status باید A S باشد؛ اگر c هم دیدید یعنی check فعال است
/ip route check 1.1.1.1
/ping 1.1.1.1 count=4

برای تست واقعی، کابل WAN1 را بکشید (یا در PPPoE اینترفیس را دستی disable کنید) و ببینید مسیر دوم چقدر سریع فعال می‌شود. اگر فِیلوور کند است، بازه‌ی check و تعداد تلاش‌ها را با /ip settings تنظیم کنید.

۴) گزینه‌ی جایگزین: Netwatch

اگر بخواهید فِیلوور را با منطق دلخواه ترکیب کنید — چند مقصد، ارسال هشدار، تغییر routing-mark — Netwatch به کار می‌آید:

/tool netwatch
add host=1.1.1.1 interval=10s down-script="/ip route disable [find comment=\"WAN1\"]" up-script="/ip route enable [find comment=\"WAN1\"]"

ولی برای صرفاً «فِیلوور خودکار»، همان check-gateway=ping روی مسیر بازگشتی ساده‌تر و سبک‌تر است و اسکریپت نمی‌خواهد. Netwatch را جایی بگذارید که واقعاً منطق اضافه لازم دارید.

جمع‌بندی

سه قدم: اول دو مسیر پیش‌فرض با distance مختلف بسازید؛ دوم روی هر دو check-gateway=ping بگذارید؛ سوم اگر گیت‌وی‌ها «دروغ می‌گویند»، مسیر پیش‌فرض را به یک آدرس عمومی بازگشتی ببندید و scope/target-scope را رعایت کنید. همین ترکیب، فِیلووری می‌سازد که در عمل کار می‌کند.

اگر هدف‌تان توزیع بار بین چند ISP است نه صرفاً فِیلوور، یادداشت لود بالانسینگ و فیلترهای پیشرفته در MikroTik را ببینید؛ و برای نگاه راهبردی‌تر به پایداری، پنج درس شبکه‌ای در سایت صنعتی.

سوالات متداول