Failover dual-WAN MikroTik pentru ISP

Rezumat Failover-ul dual-WAN MikroTik menține un sit online mutând automat traficul pe o legătură de rezervă atunci când legătura principală cedează. RouterOS îți oferă trei componente — rutare recursivă cu check-gateway, Netwatch și NAT pe WAN — iar combinația potrivită depinde de cât de rapidă și cât de inteligentă trebuie să fie detecția ta. Pentru flotele ISP, problema mai grea nu este fragmentul de configurare, ci confirmarea, pe sute de situri la distanță în spatele CGNAT, că failover-ul a funcționat cu adevărat. Acest ghid acoperă ambele.

Ce este failover-ul dual-WAN MikroTik?

Failover-ul dual-WAN MikroTik este o configurație RouterOS care oferă unui router două legături de internet — una principală și una de rezervă — și mută automat traficul pe cea de rezervă atunci când cea principală nu mai transmite pachete, apoi îl mută înapoi când aceasta se reface. Nu este același lucru cu echilibrarea sarcinii: failover-ul ține o legătură inactivă ca asigurare, în timp ce echilibrarea sarcinii distribuie traficul pe ambele. Scopul este continuitatea, nu lățime de bandă suplimentară, motiv pentru care este modelul implicit de redundanță pentru situri care pur și simplu nu pot rămâne fără conexiune.

Mecanismul se bazează pe selecția rutei. RouterOS alege ruta implicită activă după cea mai mică distanță administrativă, deci îi dai principalei o distanță mai mică și celei de rezervă una mai mare. Întregul design se reduce atunci la o singură întrebare: cum decide routerul că legătura principală este „căzută” și îi retrogradează ruta? Ia această decizie corect — suficient de rapid, dar nu nervos — și failover-ul este fiabil. Greșește-o, și fie comuți prea lent, fie oscilezi între legături la fiecare pachet pierdut.

Pasul 1 — Cartografiază cele două WAN-uri înainte de a atinge o rută

Începe prin a nota ce este de fapt fiecare legătură. O legătură principală fibră fixă sau PPPoE cu un gateway static sau atribuit prin PPP se comportă diferit de o rezervă Starlink sau LTE care stă în spatele Carrier-Grade NAT și îți oferă o adresă dinamică. Acest lucru contează deoarece rutarea recursivă funcționează doar cu gateway-uri IP stabile, nu cu tipuri de interfețe dinamice precum PPPoE sau DHCP, unde adresa se poate schimba (Documentația MikroTik — Failover (WAN Backup)). Decide care legătură este principală, care de rezervă și dacă vreuna își schimbă IP-ul la reconectare — acest singur fapt dictează ce metodă de detecție poți folosi.

Pasul 2 — Adaugă rute implicite recursive cu check-gateway

Abordarea clasică folosește rutarea recursivă: în loc să îndrepți ruta implicită direct către un next hop, o îndrepți către o țintă de sondare (de exemplu, un resolver public bine cunoscut) și adaugi o rută statică care îi spune RouterOS să ajungă la acea țintă doar printr-un anumit gateway WAN. Apoi creezi două rute implicite rezolvate recursiv prin acele ținte — cea principală cu o distanță mai mică și check-gateway=ping activat, cea de rezervă cu o distanță mai mare (Scoop — Basic ISP Failover with MikroTik).

Comportamentul în jurul căruia trebuie să planifici este sincronizarea. Check-gateway dezactivează o rută după două verificări eșuate consecutive, iar verificările rulează aproximativ la fiecare 10 secunde, deci comutarea reală ajunge în jur de 20 până la 30 de secunde — și nu reacționează la pierderea intermitentă de pachete, ci doar la un gateway complet mort (Documentația MikroTik — Failover (WAN Backup)). Pentru multe situri de clienți ISP acest lucru este acceptabil. Pentru terminale de voce sau de plată adesea nu, și aici intervine pasul 4.

Pasul 3 — Configurează NAT pentru ambele legături

Un router dual-WAN are nevoie de o regulă masquerade (sau src-nat) separată pentru fiecare interfață WAN, astfel încât legătura activă la momentul respectiv să traducă corect traficul de ieșire; o singură regulă legată de o singură interfață va întrerupe tăcut conectivitatea în momentul în care failover-ul mută traficul pe cealaltă legătură. Adaugă o regulă masquerade în lanțul srcnat pentru out-interface principal și o a doua pentru cea de rezervă. Dacă publici servicii de intrare, ține minte că regulile dst-nat legate de adresa celei principale încetează să funcționeze imediat ce acea legătură — și IP-ul ei public — dispare. Această fragilitate de intrare este aceeași capcană arhitecturală tratată în cazul nostru despre schimbările de IP Starlink, și de aceea accesul ancorat pe ieșire scalează mai bine decât redirecționarea de porturi. Pentru elementele de bază NAT, vezi ghidul nostru de configurare a NAT pe MikroTik.

Pasul 4 — Folosește Netwatch când ai nevoie de detecție mai rapidă sau mai inteligentă

Când 20–30 de secunde sunt prea lente sau trebuie să acționezi pe legături degradate-dar-vii, Netwatch este instrumentul mai flexibil. În RouterOS v7, Netwatch a primit un parametru type care poate sonda cu icmp, tcp-conn, http-get, https-get sau simple, și îți poți seta propriul interval de verificare în loc să trăiești cu cadența fixă a check-gateway (Documentația MikroTik — Failover (WAN Backup)). Fiecare gazdă are un script up și unul down, astfel încât la tranziție poți dezactiva ruta implicită principală, declanșa o alertă sau înregistra evenimentul.

Mulți operatori combină cele două: rutarea recursivă gestionează moartea curată a legăturii, în timp ce Netwatch acoperă cazurile mai dezordonate și trimite notificări. Un fir de discuție comunitar de lungă durată dezbate exact acest compromis și merită citit înainte de a standardiza o singură metodă pe o întreagă flotă (Forumul MikroTik — netwatch instead of recursive routing). Orice ai alege, păstrează configurația identică la fiecare sit — o flotă de scripturi failover personalizate este ea însăși o pană care așteaptă să se întâmple.

Pasul 5 — Verifică failover-ul la fiecare sit la distanță

Iată partea pe care tutorialele de configurare o omit. Adăugarea rutelor pe un singur router de bancă este ușoară; a dovedi că failover-ul funcționează pe sute de CPE-uri implementate este adevărata problemă ISP — și devine mai greu când legătura de rezervă este Starlink sau LTE în spatele CGNAT, deoarece dispozitivul adesea nu are niciun IP public accesibil prin care să fie administrat după ce comută. Dacă poți confirma failover-ul doar așteptând ca un client să sune, de fapt nu ai failover; ai un script despre care speri că rulează.

Aici administrarea centralizată schimbă economia. MKController menține fiecare router accesibil printr-un tunel de ieșire autentificat, astfel încât poți confirma că ruta de rezervă transportă trafic, urmări tranziția failover în monitorizare și împinge o configurație corectată — fără a depinde de un IP public care s-ar putea să nu existe pe legătura de rezervă. Combină asta cu telemetria: ghidurile noastre despre monitorizarea MikroTik la distanță cu Zabbix și monitorizarea SNMP pentru MikroTik arată cum să alertezi pe însuși evenimentul de failover, astfel încât o comutare tăcută pe legătura de rezervă scumpă să nu treacă niciodată neobservată.

Sfaturi

• Păstrează sonda check-gateway a legăturii de rezervă îndreptată către o țintă pe care o atingi prin acea legătură, nu prin cea principală, altfel testul tău este lipsit de sens.
• Etichetează tranzițiile de failover în monitorizare, astfel încât un sit care rulează zile întregi pe legătura sa de rezervă să genereze un tichet — un failover pe care nimeni nu îl observă este un cost recurent, nu o salvare.
• Testează cablul real, nu doar ruta: scoate conectorul legăturii principale și cronometrează comutarea reală.

Adu failover-ul sub un singur plan de control

Failover-ul dual-WAN pe un singur MikroTik este o problemă rezolvată. Să faci asta fiabil pe o întreagă flotă — cu configurație consecventă și capacitatea de a dovedi că rezerva funcționează pe un router pe care nu îl poți atinge prin IP public — este locul în care majoritatea operatorilor pierd bani. Administrarea centralizată, ancorată pe ieșire, închide acest decalaj.

Începe perioada ta de probă gratuită MKController