Preskočiť na obsah
InstagramYouTubeFacebook

Tutorial

MikroTik Dual-WAN failover pre ISP

Ako vybudovať spoľahlivý MikroTik dual-WAN failover pre ISP flotilu: rekurzívne smerovanie, Netwatch, NAT na WAN, čas prepnutia a vzdialené overenie.

Zhrnutie MikroTik dual-WAN failover udržiava lokalitu online tým, že automaticky presunie prevádzku na záložný uplink, keď primárny link zlyhá. RouterOS vám dáva tri stavebné bloky — rekurzívne smerovanie s check-gateway, Netwatch a NAT na WAN — a správna kombinácia závisí od toho, ako rýchla a ako múdra musí byť vaša detekcia. Pre ISP flotily nie je ťažším problémom úryvok konfigurácie, ale potvrdenie naprieč stovkami vzdialených lokalít za CGNAT, že failover skutočne fungoval. Táto príručka pokrýva oboje.

Pracovný postup MikroTik dual-WAN failover pre ISP flotilu: zmapujte oba uplinky, pridajte rekurzívne predvolené cesty s check-gateway, nakonfigurujte NAT na každý WAN, pridajte detekciu Netwatch a vzdialene overte záložnú cestu.

Čo je MikroTik Dual-WAN failover?

MikroTik dual-WAN failover je konfigurácia RouterOS, ktorá dáva routeru dva internetové uplinky — primárny a záložný — a automaticky presunie prevádzku na záložný, keď primárny prestane prepúšťať pakety, a potom ju presunie späť, keď sa zotaví. Nie je to to isté ako vyvažovanie záťaže: failover drží jeden link nečinný ako poistku, zatiaľ čo vyvažovanie záťaže rozkladá prevádzku cez oba. Cieľom je kontinuita, nie extra šírka pásma, a preto je to predvolený vzor redundancie pre lokality, ktoré jednoducho nemôžu zhasnúť.

Mechanizmus spočíva na výbere cesty. RouterOS vyberá aktívnu predvolenú cestu podľa najnižšej administratívnej vzdialenosti, takže primárnemu dáte menšiu vzdialenosť a záložnému väčšiu. Celý návrh sa potom redukuje na jednu otázku: ako sa router rozhodne, že primárny je nedostupný, a zníži jeho cestu? Urobte toto rozhodnutie správne — dostatočne rýchlo, ale nie nervózne — a failover je spoľahlivý. Urobte to zle a buď prepnete príliš pomaly, alebo budete kmitať medzi linkami pri každom strate paketu.

Krok 1 — Zmapujte obe WAN, skôr než sa dotknete cesty

Začnite tým, že si zapíšete, čím každý uplink skutočne je. Pevný optický alebo PPPoE primárny link so statickou alebo PPP-prideleou bránou sa správa inak ako Starlink alebo LTE záloha, ktorá sedí za Carrier-Grade NAT a dáva vám dynamickú adresu. Toto je dôležité, pretože rekurzívne smerovanie funguje len so stabilnými IP bránami, nie s dynamickými typmi rozhraní ako PPPoE alebo DHCP, kde sa adresa môže meniť (MikroTik dokumentácia — Failover (WAN Backup)). Rozhodnite, ktorý link je primárny, ktorý záložný a či niektorý pri opätovnom pripojení mení svoju IP — táto jediná skutočnosť určuje, ktorú metódu detekcie môžete použiť.

Krok 2 — Pridajte rekurzívne predvolené cesty s check-gateway

Klasický prístup používa rekurzívne smerovanie: namiesto smerovania predvolenej cesty priamo na ďalší skok ju nasmerujete na sondovací cieľ (napríklad známy verejný resolver) a pridáte statickú cestu, ktorá hovorí RouterOS, aby tento cieľ dosiahol len cez konkrétnu WAN bránu. Potom vytvoríte dve predvolené cesty rekurzívne rozriešené cez tieto ciele — primárnu s menšou vzdialenosťou a povoleným check-gateway=ping, záložnú s väčšou vzdialenosťou (Scoop — Basic ISP Failover with MikroTik).

Správanie, okolo ktorého treba plánovať, je časovanie. Check-gateway deaktivuje cestu po dvoch po sebe idúcich neúspešných kontrolách a kontroly bežia približne každých 10 sekúnd, takže reálne prepnutie pristane okolo 20 až 30 sekúnd — a nereaguje na občasnú stratu paketov, len na úplne mŕtvu bránu (MikroTik dokumentácia — Failover (WAN Backup)). Pre mnohé ISP zákaznícke lokality je to prijateľné. Pre hlasové alebo platobné terminály často nie, a práve tu prichádza Krok 4.

Krok 3 — Nakonfigurujte NAT pre oba uplinky

Dual-WAN router potrebuje samostatné pravidlo masquerade (alebo src-nat) na každé WAN rozhranie, aby ktorýkoľvek aktívny link správne prekladal odchádzajúcu prevádzku; jediné pravidlo viazané na jedno rozhranie ticho preruší konektivitu v okamihu, keď failover presunie prevádzku na druhý link. Pridajte jedno pravidlo masquerade v reťazci srcnat pre primárne out-interface a druhé pre záložné. Ak publikujete akékoľvek prichádzajúce služby, pamätajte, že pravidlá dst-nat viazané na adresu primárneho prestanú fungovať, keď tento link — a jeho verejná IP — zmizne. Táto krehkosť na vstupe je tá istá architektonická pasca pokrytá v našom prípade zmien IP Starlink, a preto sa prístup ukotvený na odchodzí lepšie škáluje než presmerovanie portov. Pre základy NAT pozrite našu príručku ku konfigurácii NAT na MikroTik.

Krok 4 — Použite Netwatch, keď potrebujete rýchlejšiu alebo múdrejšiu detekciu

Keď je 20–30 sekúnd príliš pomalých alebo potrebujete reagovať na degradované-ale-živé linky, Netwatch je flexibilnejší nástroj. V RouterOS v7 Netwatch získal parameter type, ktorý môže sondovať pomocou icmp, tcp-conn, http-get, https-get alebo simple, a môžete nastaviť vlastný interval kontroly namiesto toho, aby ste žili s pevnou kadenciou check-gateway (MikroTik dokumentácia — Failover (WAN Backup)). Každý hostiteľ má skript up a down, takže pri prechode môžete deaktivovať primárnu predvolenú cestu, vyvolať výstrahu alebo zaznamenať udalosť.

Mnohí operátori kombinujú oboje: rekurzívne smerovanie zvláda čistú smrť linku, zatiaľ čo Netwatch pokrýva neupratané prípady a posiela upozornenia. Dlho bežiaca komunitná diskusia rozoberá presne tento kompromis a stojí za prečítanie, skôr než si štandardizujete jednu metódu naprieč flotilou (MikroTik fórum — netwatch instead of recursive routing). Čokoľvek si vyberiete, udržujte konfiguráciu identickú na každej lokalite — flotila šitých failover skriptov je sama o sebe výpadkom, ktorý len čaká, kým nastane.

Krok 5 — Overte failover na každej vzdialenej lokalite

Tu je tá časť, ktorú konfiguračné tutoriály preskakujú. Pridať cesty na jednom laboratórnom routeri je ľahké; dokázať, že failover funguje na stovkách nasadených CPE, je skutočný ISP problém — a je to ťažšie, keď je záložný link Starlink alebo LTE za CGNAT, pretože zariadenie po prepnutí často nemá dostupnú verejnú IP na jeho správu. Ak môžete failover potvrdiť len čakaním, kým zákazník zavolá, vlastne nemáte failover; máte skript, o ktorom dúfate, že beží.

Tu centralizovaná správa mení ekonomiku. MKController udržiava každý router dostupný cez autentifikovaný odchodzí tunel, takže môžete potvrdiť, že záložná cesta nesie prevádzku, sledovať prechod failoveru v monitorovaní a poslať opravenú konfiguráciu — bez závislosti na verejnej IP, ktorá na záložnom linku nemusí existovať. Spárujte to s telemetriou: naše príručky o vzdialenom monitorovaní MikroTik so Zabbix a SNMP monitorovaní pre MikroTik ukazujú, ako upozorňovať na samotnú udalosť failoveru, aby tiché prepnutie na drahý záložný link nikdy neostalo nepovšimnuté.

Tipy

  • Udržujte sondu check-gateway záložného linku nasmerovanú na cieľ, ktorý dosiahnete cez tento link, nie cez primárny, inak je váš test bezvýznamný.
  • Označte prechody failoveru vo svojom monitorovaní, aby lokalita bežiaca dni na svojom záložnom uplinku vyvolala tiket — failover, ktorý si nikto nevšimne, je opakujúci sa náklad, nie záchrana.
  • Otestujte skutočný kábel, nielen cestu: vytiahnite konektor primárneho a odmerajte reálne prepnutie.

Dostaňte failover pod jednu riadiacu rovinu

Dual-WAN failover na jednom MikroTik je vyriešený problém. Robiť to spoľahlivo naprieč flotilou — s konzistentnou konfiguráciou a schopnosťou dokázať, že záloha funguje na routeri, ktorý nedosiahnete cez verejnú IP — je miesto, kde väčšina operátorov stráca peniaze. Centralizovaná, na odchodzí ukotvená správa túto medzeru zatvára.

Spustite svoju bezplatnú skúšobnú verziu MKController