MikroTik двоен WAN failover за ISP

Резюме MikroTik двоен WAN failover поддържа обекта онлайн, като автоматично премества трафика към резервна връзка, когато основната връзка се повреди. RouterOS ви дава три градивни блока — рекурсивно маршрутизиране с check-gateway, Netwatch и NAT за всеки WAN — и правилната комбинация зависи от това колко бързо и колко умно трябва да е вашето откриване. За ISP флотове по-трудният проблем не е конфигурационният фрагмент, а потвърждаването, през стотици отдалечени обекти зад CGNAT, че failover наистина е сработил. Това ръководство обхваща и двете.

Какво Е MikroTik двоен WAN failover?

MikroTik двоен WAN failover е RouterOS конфигурация, която дава на рутера две интернет връзки — основна и резервна — и автоматично прехвърля трафика към резервната, когато основната спре да пропуска пакети, а след това го връща обратно при възстановяване. Това не е същото като балансиране на натоварването: failover държи едната връзка незаета като застраховка, докато балансирането разпределя трафика по двете. Целта е непрекъснатост, а не допълнителна пропускателна способност, и точно затова това е стандартният модел за резервиране за обекти, които просто не могат да изгаснат.

Механизмът се основава на избора на маршрут. RouterOS избира активния маршрут по подразбиране по най-ниската административна дистанция, така че давате на основната по-малка дистанция, а на резервната — по-голяма. Целият дизайн тогава се свежда до един въпрос: как рутерът решава, че основната е „надолу” и понижава нейния маршрут? Вземете това решение правилно — достатъчно бързо, но не нервно — и failover е надежден. Сгрешите ли, или превключвате твърде бавно, или трептите между връзките при всеки изгубен пакет.

Стъпка 1 — Картографирайте двата WAN, преди да докоснете маршрут

Започнете, като запишете какво всъщност представлява всяка връзка. Фиксирана оптична или PPPoE основна връзка със статичен или назначен чрез PPP шлюз се държи различно от Starlink или LTE резерв, който седи зад Carrier-Grade NAT и ви дава динамичен адрес. Това има значение, защото рекурсивното маршрутизиране работи само със стабилни IP шлюзове, не с динамични типове интерфейси като PPPoE или DHCP, при които адресът може да се промени (MikroTik документация — Failover (WAN Backup)). Решете коя връзка е основна, коя е резервна и дали някоя променя своя IP при повторно свързване — този единствен факт диктува кой метод за откриване можете да използвате.

Стъпка 2 — Добавете рекурсивни маршрути по подразбиране с check-gateway

Класическият подход използва рекурсивно маршрутизиране: вместо да насочвате маршрута по подразбиране директно към следващ хоп, го насочвате към цел за проверка (например добре известен публичен резолвер) и добавяте статичен маршрут, който казва на RouterOS да достига тази цел само през конкретен WAN шлюз. След това създавате два маршрута по подразбиране, разрешени рекурсивно през тези цели — основният с по-малка дистанция и активиран check-gateway=ping, резервният с по-голяма дистанция (Scoop — Basic ISP Failover with MikroTik).

Поведението, около което трябва да се планира, е таймингът. Check-gateway деактивира маршрут след две последователни неуспешни проверки, а проверките се извършват приблизително на всеки 10 секунди, така че реалното превключване попада около 20 до 30 секунди — и то не реагира на периодична загуба на пакети, само на напълно мъртъв шлюз (MikroTik документация — Failover (WAN Backup)). За много ISP клиентски обекти това е приемливо. За гласови или платежни терминали често не е, и точно тук идва Стъпка 4.

Стъпка 3 — Конфигурирайте NAT за двете връзки

Двоен WAN рутер се нуждае от отделно masquerade (или src-nat) правило за всеки WAN интерфейс, така че която и връзка да е активна, да превежда изходящия трафик правилно; едно-единствено правило, обвързано с един интерфейс, тихо ще прекъсне свързаността в момента, в който failover премести трафика към другата връзка. Добавете едно masquerade правило във веригата srcnat за основния out-interface и второ за резервния. Ако публикувате каквито и да е входящи услуги, помнете, че dst-nat правилата, обвързани с адреса на основната, спират да работят веднага щом тази връзка — и нейният публичен IP — изчезне. Тази входяща крехкост е същият архитектурен капан, разгледан в нашия случай за промени на IP при Starlink, и затова закотвеният към изхода достъп се мащабира по-добре от пренасочването на портове. За основите на NAT вижте нашето ръководство за конфигуриране на NAT на MikroTik.

Стъпка 4 — Използвайте Netwatch, когато ви трябва по-бързо или по-умно откриване

Когато 20–30 секунди са твърде бавни или трябва да действате при влошени-но-живи връзки, Netwatch е по-гъвкавият инструмент. В RouterOS v7 Netwatch получи параметър type, който може да проверява с icmp, tcp-conn, http-get, https-get или simple, и можете да зададете собствен интервал на проверка вместо да живеете с фиксирания ритъм на check-gateway (MikroTik документация — Failover (WAN Backup)). Всеки хост има up и down скрипт, така че можете да деактивирате основния маршрут по подразбиране, да вдигнете аларма или да регистрирате събитието при преход.

Много оператори комбинират двете: рекурсивното маршрутизиране се справя с чистата смърт на връзка, докато Netwatch покрива по-объркаите случаи и изпраща известия. Дълготрайна тема в общността обсъжда точно този компромис и си струва да се прочете, преди да стандартизирате един метод в целия флот (MikroTik форум — netwatch instead of recursive routing). Каквото и да изберете, дръжте конфигурацията идентична на всеки обект — флот от персонализирани failover скриптове е сам по себе си авария, която само чака да се случи.

Стъпка 5 — Проверете failover на всеки отдалечен обект

Ето частта, която конфигурационните уроци пропускат. Добавянето на маршрутите на един тестов рутер е лесно; доказването, че failover работи на стотици разгърнати CPE устройства, е истинският ISP проблем — и става по-трудно, когато резервната връзка е Starlink или LTE зад CGNAT, защото устройството често няма достъпен публичен IP, през който да се управлява, след като превключи. Ако можете да потвърдите failover само като чакате клиент да се обади, всъщност нямате failover; имате скрипт, за който се надявате, че работи.

Тук централизираното управление променя икономиката. MKController държи всеки рутер достъпен през удостоверен изходящ тунел, така че можете да потвърдите, че резервният път носи трафик, да наблюдавате failover прехода в мониторинга и да изпратите коригирана конфигурация — без да зависите от публичен IP, който може да не съществува на резервната връзка. Съчетайте това с телеметрия: нашите ръководства за отдалечен мониторинг на MikroTik със Zabbix и SNMP мониторинг за MikroTik показват как да алармирате за самото failover събитие, така че тихо превключване към скъпата резервна връзка никога да не остане незабелязано.

Съвети

• Дръжте check-gateway проверката на резервната връзка насочена към цел, която достигате през тази връзка, не през основната, иначе тестът ви е безсмислен.
• Маркирайте failover преходите в мониторинга си, така че обект, който работи дни наред на резервната си връзка, да вдигне тикет — failover, който никой не забелязва, е повтарящ се разход, а не спасение.
• Тествайте реалния кабел, не само маршрута: издърпайте конектора на основната и измерете реалното време за превключване.

Сложете failover под една контролна равнина

Двоен WAN failover на единичен MikroTik е решен проблем. Да го правите надеждно през цял флот — с последователна конфигурация и способността да докажете, че резервът работи на рутер, до който не можете да достигнете през публичен IP — е там, където повечето оператори губят пари. Централизираното, закотвено към изхода управление затваря тази празнина.

Започнете безплатния си пробен период с MKController