MikroTik Failover: Как да настроите резервен интернет (WAN2) с check-gateway

Осигуряването на непрекъсната интернет връзка е от съществено значение както за домашни мрежи, така и за офиси. MikroTik RouterOS предлага изключителна гъвкавост, но понякога конфигурацията на втори доставчик (WAN2) може да изглежда сложна.

В това ръководство ще разгледаме как с няколко лесни стъпки да конфигурирате резервен интернет (Failover) чрез приоритети на маршрутите (Route Distance), използвайки втори рутер (напр. TP-Link, LTE рутер и т.н.) за резервна връзка. Освен базовата настройка, ще добавим и проверка на връзката чрез check-gateway=ping, за да сме сигурни, че превключването ще сработи дори когато кабелът е включен, но основният доставчик реално няма интернет.

Как работи тази схема?

Целта е рутерът да използва основната интернет връзка (ether1) като първостепенна. В момента, в който тя отпадне – физически или логически – MikroTik автоматично пренасочва целия трафик през резервния порт (ether2). Това се постига чрез задаване на различен Distance (приоритет) на маршрутите по подразбиране.

Main WAN (ether1): Distance = 1 (по-висок приоритет)
Backup WAN (ether2): Distance = 2 (по-нисък приоритет)

Когато и двата маршрута са активни, RouterOS използва този с по-малък Distance. Ако той стане недостъпен, автоматично се преминава към следващия по приоритет.

Важно: Distance-based failover сам по себе си реагира само при физическо падане на линка (link down) или загуба на DHCP lease. Ако доставчикът е “умрял” upstream, но интерфейсът остава up, рутерът няма да превключи. Затова в Стъпка 6 добавяме check-gateway=ping, който решава точно този проблем.

Предварителни условия

MikroTik с RouterOS v6 или v7.
Основен интернет доставчик на ether1 (в случая – DHCP client).
Втори доставчик (TP-Link, LTE рутер и т.н.), който ще свържем към ether2.
Достъп до WinBox, WebFig или SSH за конфигуриране.

Бележка: Ако основният WAN (ether1) е конфигуриран със статичен IP или PPPoE, а не с DHCP client, съответно коригирайте Стъпка 4 – идеята е просто distance-ът на default route-а към ether1 да е 1.

Постъпково ръководство

Стъпка 1: Освобождаване на ether2 от LAN Bridge-а

По подразбиране в MikroTik портове от ether2 до ether5 са обединени в общ суич/мост (bridge). За да използваме ether2 като самостоятелен WAN порт, първо трябва да го премахнем от локалния bridge.

/interface bridge port remove [find interface=ether2]

Ако искате да проверите предварително дали ether2 е в bridge:

/interface bridge port print

Внимание: Ако компютър или друго устройство е включено в порт, който е в същия bridge (например ether3), докато ether2 все още не е изваден, DHCP заявките му може погрешно да стигнат до втория доставчик през bridge-а, вместо до MikroTik DHCP сървъра. Затова тази стъпка трябва да се изпълни преди физическото свързване в Стъпка 2.

Стъпка 2: Физическо свързване

Включете Ethernet кабела от втория доставчик (или изхода на вторичния рутер/LTE устройство, напр. TP-Link) в порт ether2 на вашия MikroTik.

Уверете се, че вторият рутер е конфигуриран да раздава IP адреси по DHCP на своя LAN порт – ние ще получаваме адрес от него.

Стъпка 3: Конфигуриране на DHCP Client за ether2 (Backup WAN)

Настройваме ether2 да си получава IP адрес автоматично чрез DHCP от вторичния рутер. Задаваме му default-route-distance=2, за да го маркираме като резервен маршрут.

/ip dhcp-client add interface=ether2 use-peer-dns=no add-default-route=yes default-route-distance=2 disabled=no

Бележка: Задаването на use-peer-dns=no гарантира, че DNS сървърите от втория доставчик няма да пренаписват основните ви DNS настройки.

Изчакайте няколко секунди и проверете дали ether2 е получил адрес:

/ip dhcp-client print
/ip address print

Стъпка 4: Корекция на приоритета за ether1 (Primary WAN)

Уверяваме се, че основният интернет (ether1) е с по-висок приоритет (distance=1). Така рутерът винаги ще предпочита ether1, докато той е активен.

Използвайте търсене по интерфейс, а не по индекс – така командата е устойчива и няма да сработи по грешен DHCP client, ако имате няколко:

/ip dhcp-client set [find interface=ether1] default-route-distance=1

Защо не set 0? Индексът 0 сочи към първия DHCP client в списъка. Ако имате DHCP client на друг порт, VLAN или wifi, 0 може да не е ether1. [find interface=ether1] е експлицитно и безопасно.

Стъпка 5: Разширяване на NAT Masquerade за ether2

За да могат устройствата от вашата локална мрежа (LAN) да имат достъп до интернет през резервната връзка, трябва да добавите Masquerade (NAT) правило и за ether2.

/ip firewall nat add chain=srcnat action=masquerade out-interface=ether2 comment="masquerade WAN2 backup"

Проверете дали правилото е добавено правилно:

/ip firewall nat print

Стъпка 6: Проверка на връзката чрез check-gateway=ping (важно!)

Това е стъпката, която разграничава “работещ на хартия” failover от наистина работещ failover.

Без нея, ако доставчикът на ether1 спре да рутира трафик, но интерфейсът остане up, рутерът ще продължи да праща трафик през мъртвия маршрут. С check-gateway=ping RouterOS периодично пингува gateway-я и при загуба на отговор маркира маршрута като неактивен – така превключването става реално.

Приложете го към default route-а, който минава през ether1. Route-ове, създадени от DHCP client, съхраняват IP адреса на gateway-я, а не името на интерфейса, затова търсенето трябва да е по distance (зададен в Стъпка 4), не по интерфейс:

/ip route set [find dst-address=0.0.0.0/0 distance=1] check-gateway=ping

Ако предпочитате да сте сигурни кой точно route пипате, вижте първо списъка и приложете настройката по конкретния .id:

/ip route print
/ip route set [find dst-address=0.0.0.0/0 gateway=<реалния IP на ISP1 gateway>] check-gateway=ping

Съвет: Ако gateway-ът на доставчика не отговаря на ping (някои го блокират), използвайте netwatch към публичен адрес като 8.8.8.8 вместо check-gateway=ping.

Препоръчителни допълнителни настройки

1. Настройка на глобални DNS сървъри

Тъй като изключихме вземането на DNS от резервния доставчик, е добра практика да конфигурирате публични DNS сървъри (напр. Google или Cloudflare) директно в MikroTik:

/ip dns set servers=8.8.8.8,1.1.1.1 allow-remote-requests=yes

2. Проверка на активните маршрути

Можете да проверите дали всичко работи правилно с командата:

/ip route print

Трябва да видите два маршрута към 0.0.0.0/0:

Този през ether1 – активен (флаг A), distance=1.
Този през ether2 – неактивен (без флаг A), distance=2.

Обяснение на флаговете в RouterOS v7:

Флаг	Значение
`D`	Dynamic (маршрутът е създаден автоматично, напр. от DHCP client)
`A`	Active (маршрутът е активен в момента)
`c`	Connect (директно свързана мрежа)
`s`	Static (ръчно зададен маршрут — ползва се за route-овете, добавени от потребителя, не за DHCP-генерираните)
малка `d`	под-флаг, показващ DHCP произход на конкретния route

Важно: Dynamic и Static са взаимно изключващи се — route, създаден от DHCP client, никога няма да носи и двата флага едновременно. Типично ще видите нещо от рода на DAd за активен DHCP route (Dynamic + Active + DHCP-произход) или DS само при route-ове, генерирани динамично от друг протокол, но третирани като static default (зависи от версията) — при съмнение, разчитайте на реалния /ip route print изход пред вас, не на табличен пример.

При отпадане на ether1, вторият маршрут автоматично ще получи флаг A.

3. Автоматично известяване при превключване (по избор)

Ако искате да получавате известие, когато failover-ът се задейства, можете да използвате netwatch с on-event скрипт:

/tool netwatch add host=8.8.8.8 interval=10s \
  down-script="/log warning \"WAN1 down - failover active\"" \
  up-script="/log info \"WAN1 restored\""

Това не е задължително, но е полезно в офис среда, където искате да знаете кога основният доставчик е паднал.

Тест на failover-а

За да сте сигурни, че всичко работи реално, направете следния тест:

Отворете терминал и стартирайте:
```
/ip route print follow
```
Извадете кабела от ether1 (или изключете захранването на основния модем).
След 5–10 секунди маршрутът през ether2 трябва да получи флаг A (Active).
От LAN устройство изпълнете ping 8.8.8.8 – трябва да има отговор.
Върнете кабела обратно – след няколко секунди ether1 трябва отново да поеме трафика.

Ако използвате check-gateway=ping, тествайте и “логически” failover – блокирайте трафика към gateway-я на ether1 (напр. чрез firewall правило за тест) и вижте дали рутерът превключва.

Често срещани проблеми

Проблем: LAN устройствата нямат интернет през backup WAN. Решение: Проверете дали masquerade правилото за ether2 е добавено (Стъпка 5) и дали ether2 има получен IP адрес.

Проблем: Failover-ът не се задейства при спиране на интернета, но кабелът е включен. Решение: Това е очаквано без check-gateway=ping. Добавете Стъпка 6.

Проблем: Командата за check-gateway=ping не намира route (Стъпка 6). Решение: Не търсете по gateway=ether1 — DHCP-генерираните route-ове пазят IP адреса на gateway-я, не името на интерфейса. Търсете по distance=1 или по конкретния IP, видян в /ip route print.

Проблем: След превключване връзката е нестабилна или DNS не работи. Решение: Уверете се, че use-peer-dns=no е зададено, и че глобалните DNS сървъри са конфигурирани (вижте допълнителните настройки).

Проблем: set 0 не сработва или променя грешен интерфейс. Решение: Използвайте [find interface=ether1] вместо индекс.

Заключение

С тези стъпки си осигурихте надеждна и автоматична резервна интернет връзка, която реагира както на физическо прекъсване, така и на реална загуба на свързаност. Конфигурацията е лесна за поддръжка, не изисква сложни скриптове и решава проблема с прекъсването на мрежата бързо и ефективно.

Ключовите моменти:

Distance определя приоритета на маршрутите (1 = основен, 2 = резервен).
check-gateway=ping прави failover-а реален, а не само “на хартия” — но трябва да се приложи по distance или конкретен IP, не по име на интерфейс.
Masquerade за ether2 е задължителен, за да излезе LAN през backup-а.
use-peer-dns=no + глобални DNS сървъри предотвратяват проблеми с имената.
Освобождаването на ether2 от bridge-а (Стъпка 1) трябва да стане преди физическото свързване, иначе DHCP заявки от LAN устройства могат погрешно да минат през него.

С тези настройки мрежата ви ще остане онлайн дори когато основният доставчик ви подведе. 🚀