MikroTik failover dual-WAN dla ISP

Podsumowanie Failover dual-WAN MikroTik utrzymuje lokalizację online, automatycznie przenosząc ruch na zapasowe łącze, gdy łącze podstawowe zawiedzie. RouterOS daje trzy elementy składowe — routing rekurencyjny z check-gateway, Netwatch oraz NAT na WAN — a właściwa kombinacja zależy od tego, jak szybkie i jak sprytne musi być Twoje wykrywanie. Dla flot ISP trudniejszym problemem nie jest fragment konfiguracji, lecz potwierdzenie, w setkach zdalnych lokalizacji za CGNAT, że failover rzeczywiście zadziałał. Ten przewodnik obejmuje oba.

Czym jest failover dual-WAN MikroTik?

Failover dual-WAN MikroTik to konfiguracja RouterOS, która daje routerowi dwa łącza internetowe — podstawowe i zapasowe — i automatycznie przenosi ruch na zapasowe, gdy podstawowe przestaje przepuszczać pakiety, a następnie przenosi go z powrotem po jego odzyskaniu. Nie jest to to samo co równoważenie obciążenia: failover utrzymuje jedno łącze bezczynne jako ubezpieczenie, podczas gdy równoważenie obciążenia rozkłada ruch na oba. Celem jest ciągłość, a nie dodatkowa przepustowość, i dlatego jest to domyślny wzorzec redundancji dla lokalizacji, które po prostu nie mogą zgasnąć.

Mechanizm opiera się na wyborze trasy. RouterOS wybiera aktywną trasę domyślną według najniższego dystansu administracyjnego, więc nadajesz podstawowej mniejszy dystans, a zapasowej większy. Cały projekt sprowadza się wtedy do jednego pytania: jak router decyduje, że podstawowe jest „w dół” i degraduje jego trasę? Podejmij tę decyzję poprawnie — wystarczająco szybko, ale nie nerwowo — a failover będzie niezawodny. Zrób to źle, a albo przełączysz się zbyt wolno, albo będziesz trzepotać między łączami przy każdej utracie pakietu.

Krok 1 — Zmapuj oba łącza WAN, zanim dotkniesz trasy

Zacznij od zapisania, czym faktycznie jest każde łącze. Stałe światłowodowe lub PPPoE łącze podstawowe ze statyczną lub przydzieloną przez PPP bramą zachowuje się inaczej niż zapasowe Starlink lub LTE, które siedzi za Carrier-Grade NAT i daje Ci adres dynamiczny. To ma znaczenie, ponieważ routing rekurencyjny działa tylko ze stabilnymi bramami IP, a nie z dynamicznymi typami interfejsów jak PPPoE czy DHCP, gdzie adres może się zmienić (Dokumentacja MikroTik — Failover (WAN Backup)). Zdecyduj, które łącze jest podstawowe, które zapasowe, i czy któreś zmienia swój IP przy ponownym połączeniu — ten jeden fakt dyktuje, której metody wykrywania możesz użyć.

Krok 2 — Dodaj rekurencyjne trasy domyślne z check-gateway

Klasyczne podejście używa routingu rekurencyjnego: zamiast kierować trasę domyślną bezpośrednio na następny skok, kierujesz ją na cel sondujący (na przykład znany publiczny resolver) i dodajesz trasę statyczną nakazującą RouterOS osiągać ten cel wyłącznie przez konkretną bramę WAN. Następnie tworzysz dwie trasy domyślne rozwiązywane rekurencyjnie przez te cele — podstawową z mniejszym dystansem i włączonym check-gateway=ping, zapasową z większym dystansem (Scoop — Basic ISP Failover with MikroTik).

Zachowanie, wokół którego trzeba planować, to czas. Check-gateway dezaktywuje trasę po dwóch kolejnych nieudanych sprawdzeniach, a sprawdzenia odbywają się mniej więcej co 10 sekund, więc rzeczywiste przełączenie wypada w okolicach 20 do 30 sekund — i nie reaguje na sporadyczną utratę pakietów, tylko na całkowicie martwą bramę (Dokumentacja MikroTik — Failover (WAN Backup)). Dla wielu lokalizacji klientów ISP jest to akceptowalne. Dla terminali głosowych lub płatniczych często nie, i tu właśnie wkracza krok 4.

Krok 3 — Skonfiguruj NAT dla obu łączy

Router dual-WAN potrzebuje osobnej reguły masquerade (lub src-nat) na każdy interfejs WAN, aby aktualnie aktywne łącze poprawnie tłumaczyło ruch wychodzący; pojedyncza reguła związana z jednym interfejsem po cichu zerwie łączność w momencie, gdy failover przeniesie ruch na drugie łącze. Dodaj jedną regułę masquerade w łańcuchu srcnat dla podstawowego out-interface i drugą dla zapasowego. Jeśli publikujesz jakiekolwiek usługi przychodzące, pamiętaj, że reguły dst-nat powiązane z adresem podstawowego przestają działać, gdy to łącze — i jego publiczny IP — znika. Ta podatność po stronie przychodzącej to ta sama architektoniczna pułapka opisana w naszym przypadku zmian IP Starlink, i dlatego dostęp zakotwiczony wychodząco skaluje się lepiej niż przekierowanie portów. Po podstawy NAT zajrzyj do naszego przewodnika po konfiguracji NAT na MikroTik.

Krok 4 — Użyj Netwatch, gdy potrzebujesz szybszego lub sprytniejszego wykrywania

Gdy 20–30 sekund jest za wolne lub musisz reagować na zdegradowane-ale-żywe łącza, Netwatch jest bardziej elastycznym narzędziem. W RouterOS v7 Netwatch zyskał parametr type, który potrafi sondować za pomocą icmp, tcp-conn, http-get, https-get lub simple, i możesz ustawić własny interwał sprawdzania zamiast godzić się ze stałą kadencją check-gateway (Dokumentacja MikroTik — Failover (WAN Backup)). Każdy host ma skrypt up i down, więc przy przejściu możesz wyłączyć podstawową trasę domyślną, wywołać alert lub zarejestrować zdarzenie.

Wielu operatorów łączy oba: routing rekurencyjny obsługuje czystą śmierć łącza, podczas gdy Netwatch pokrywa bardziej zagmatwane przypadki i wysyła powiadomienia. Długo działający wątek społecznościowy omawia dokładnie ten kompromis i warto go przeczytać, zanim ustandaryzujesz jedną metodę w całej flocie (Forum MikroTik — netwatch instead of recursive routing). Cokolwiek wybierzesz, utrzymuj konfigurację identyczną w każdej lokalizacji — flota niestandardowych skryptów failover sama jest awarią czekającą, by się wydarzyć.

Krok 5 — Zweryfikuj failover w każdej zdalnej lokalizacji

Oto część, którą tutoriale konfiguracyjne pomijają. Dodanie tras na jednym routerze testowym jest łatwe; udowodnienie, że failover działa na setkach wdrożonych CPE, to prawdziwy problem ISP — i staje się trudniejsze, gdy łącze zapasowe to Starlink lub LTE za CGNAT, ponieważ urządzenie po przełączeniu często nie ma osiągalnego publicznego IP, przez które można nim zarządzać. Jeśli możesz potwierdzić failover tylko czekając na telefon od klienta, to tak naprawdę nie masz failover; masz skrypt, o którym masz nadzieję, że działa.

Tutaj scentralizowane zarządzanie zmienia ekonomię. MKController utrzymuje każdy router osiągalnym przez uwierzytelniony tunel wychodzący, więc możesz potwierdzić, że ścieżka zapasowa przenosi ruch, obserwować przejście failover w monitoringu i wypchnąć poprawioną konfigurację — bez zależności od publicznego IP, którego na łączu zapasowym może nie być. Połącz to z telemetrią: nasze przewodniki o zdalnym monitorowaniu MikroTik z Zabbix i monitorowaniu SNMP dla MikroTik pokazują, jak alarmować o samym zdarzeniu failover, aby ciche przełączenie na drogie łącze zapasowe nigdy nie pozostało niezauważone.

Wskazówki

• Utrzymuj sondę check-gateway łącza zapasowego skierowaną na cel osiągany przez to łącze, a nie przez podstawowe, inaczej Twój test jest bezsensowny.
• Oznaczaj przejścia failover w monitoringu, aby lokalizacja działająca dniami na swoim zapasowym łączu generowała zgłoszenie — failover, którego nikt nie zauważa, to powtarzający się koszt, a nie ratunek.
• Testuj prawdziwy kabel, nie tylko trasę: wyciągnij złącze podstawowego i zmierz rzeczywisty czas przełączania.

Sprowadź failover pod jedną płaszczyznę sterowania

Failover dual-WAN na pojedynczym MikroTik to rozwiązany problem. Robienie tego niezawodnie w całej flocie — ze spójną konfiguracją i możliwością udowodnienia, że zapasowe działa na routerze, którego nie możesz osiągnąć przez publiczny IP — to miejsce, gdzie większość operatorów traci pieniądze. Scentralizowane, zakotwiczone wychodząco zarządzanie zamyka tę lukę.

Rozpocznij darmowy okres próbny MKController