Failover WAN dual MikroTik per a ISP

Resum El failover WAN dual de MikroTik manté un lloc en línia movent automàticament el trànsit cap a un enllaç de reserva quan l’enllaç primari falla. RouterOS us ofereix tres blocs de construcció — encaminament recursiu amb check-gateway, Netwatch i NAT per WAN — i la combinació adequada depèn de com de ràpida i com d’intel·ligent ha de ser la vostra detecció. Per a flotes d’ISP, el problema més difícil no és el fragment de configuració, sinó confirmar, a través de centenars de llocs remots darrere de CGNAT, que el failover realment ha funcionat. Aquesta guia cobreix les dues coses.

Què És el Failover WAN dual de MikroTik?

El failover WAN dual de MikroTik és una configuració de RouterOS que dona a un encaminador dos enllaços d’internet — un primari i un de reserva — i mou automàticament el trànsit cap al de reserva quan el primari deixa de passar paquets, i el torna a moure quan es recupera. No és el mateix que el balanceig de càrrega: el failover manté un enllaç inactiu com a assegurança, mentre que el balanceig reparteix el trànsit entre tots dos. L’objectiu és la continuïtat, no l’amplada de banda addicional, i per això és el patró de redundància per defecte per a llocs que simplement no es poden quedar a les fosques.

El mecanisme es basa en la selecció de ruta. RouterOS tria la ruta per defecte activa per la distància administrativa més baixa, així que doneu al primari una distància més petita i al de reserva una de més gran. Tot el disseny es redueix llavors a una pregunta: com decideix l’encaminador que el primari està «caigut» i degrada la seva ruta? Encerteu aquesta decisió — prou ràpida, però no nerviosa — i el failover serà fiable. Erreu-la i o bé commuteu massa lentament o bé osciŀleu entre enllaços a cada paquet de pèrdua.

Pas 1 — Mapa els dos WAN abans de tocar cap ruta

Comenceu anotant què és realment cada enllaç. Un primari de fibra fixa o PPPoE amb una passarel·la estàtica o assignada per PPP es comporta de manera diferent d’un de reserva Starlink o LTE que seu darrere de Carrier-Grade NAT i us dona una adreça dinàmica. Això importa perquè l’encaminament recursiu només funciona amb passarel·les IP estables, no amb tipus d’interfície dinàmics com PPPoE o DHCP on l’adreça pot canviar (Documentació de MikroTik — Failover (WAN Backup)). Decidiu quin enllaç és primari, quin és de reserva i si algun canvia la seva IP en reconnectar-se — aquest únic fet dicta quin mètode de detecció podeu usar.

Pas 2 — Afegiu rutes per defecte recursives amb check-gateway

L’enfocament clàssic usa encaminament recursiu: en lloc d’apuntar la ruta per defecte directament a un salt següent, l’apunteu a un objectiu de sondeig (per exemple un resolver públic conegut) i afegiu una ruta estàtica que diu a RouterOS que arribi a aquest objectiu només a través d’una passarel·la WAN específica. Després creeu dues rutes per defecte resoltes recursivament sobre aquests objectius — la primària amb una distància més petita i check-gateway=ping activat, la de reserva amb una distància més gran (Scoop — Basic ISP Failover with MikroTik).

El comportament al voltant del qual cal planificar és el temps. Check-gateway desactiva una ruta després de dues comprovacions fallides consecutives, i les comprovacions s’executen aproximadament cada 10 segons, de manera que la commutació real cau cap a 20 o 30 segons — i no reacciona a la pèrdua intermitent de paquets, només a una passarel·la completament morta (Documentació de MikroTik — Failover (WAN Backup)). Per a molts llocs de clients d’ISP això és acceptable. Per a terminals de veu o de pagament sovint no, i és aquí on entra el Pas 4.

Pas 3 — Configureu NAT per als dos enllaços

Un encaminador WAN dual necessita una regla masquerade (o src-nat) separada per interfície WAN perquè l’enllaç que estigui actiu tradueixi correctament el trànsit sortint; una única regla lligada a una interfície trencarà silenciosament la connectivitat en el moment que el failover mogui el trànsit cap a l’altre enllaç. Afegiu una regla masquerade a la cadena srcnat per a l’out-interface primària i una segona per a la de reserva. Si publiqueu qualsevol servei entrant, recordeu que les regles dst-nat lligades a l’adreça de la primària deixen de funcionar tan bon punt aquest enllaç — i la seva IP pública — desapareix. Aquesta fragilitat entrant és el mateix parany arquitectònic tractat al nostre cas dels canvis d’IP de Starlink, i és per això que l’accés ancorat a la sortida escala millor que el reenviament de ports. Per als fonaments de NAT, vegeu la nostra guia per configurar NAT a MikroTik.

Pas 4 — Useu Netwatch quan necessiteu una detecció més ràpida o intel·ligent

Quan 20–30 segons són massa lents o heu d’actuar sobre enllaços degradats-però-vius, Netwatch és l’eina més flexible. A RouterOS v7, Netwatch va guanyar un paràmetre type que pot sondejar amb icmp, tcp-conn, http-get, https-get o simple, i podeu establir el vostre propi interval de comprovació en lloc de viure amb la cadència fixa de check-gateway (Documentació de MikroTik — Failover (WAN Backup)). Cada amfitrió té un script up i un down, així que podeu desactivar la ruta per defecte primària, aixecar una alerta o registrar l’esdeveniment en la transició.

Molts operadors combinen les dues: l’encaminament recursiu gestiona la mort neta de l’enllaç, mentre que Netwatch cobreix els casos més desordenats i envia notificacions. Un fil de comunitat de llarga durada debat exactament aquesta compensació i val la pena llegir-lo abans d’estandarditzar un mètode a tota una flota (Fòrum de MikroTik — netwatch instead of recursive routing). Trieu el que trieu, mantingueu la configuració idèntica a cada lloc — una flota d’scripts de failover a mida és en si mateixa una interrupció que només espera a passar.

Pas 5 — Verifiqueu el failover a cada lloc remot

Aquí teniu la part que els tutorials de configuració s’salten. Afegir les rutes en un encaminador de laboratori és fàcil; demostrar que el failover funciona en centenars de CPE desplegats és el veritable problema d’ISP — i es fa més difícil quan l’enllaç de reserva és Starlink o LTE darrere de CGNAT, perquè el dispositiu sovint no té cap IP pública accessible per gestionar-lo després de commutar. Si només podeu confirmar el failover esperant que un client truqui, no teniu realment failover; teniu un script que espereu que s’executi.

Aquí la gestió centralitzada canvia l’economia. MKController manté cada encaminador accessible a través d’un túnel sortint autenticat, de manera que podeu confirmar que el camí de reserva porta trànsit, observar la transició de failover a la monitorització i enviar una configuració corregida — sense dependre d’una IP pública que potser no existeix a l’enllaç de reserva. Combineu-ho amb telemetria: les nostres guies sobre monitoritzar MikroTik remotament amb Zabbix i monitorització SNMP per a MikroTik mostren com alertar sobre el mateix esdeveniment de failover, perquè una commutació silenciosa cap a l’enllaç de reserva car mai no passi desapercebuda.

Consells

• Mantingueu el sondeig check-gateway de l’enllaç de reserva apuntat a un objectiu que arribeu a través d’aquest enllaç, no a través del primari, o la vostra prova no tindrà sentit.
• Etiqueteu les transicions de failover a la vostra monitorització perquè un lloc que funcioni dies sencers en el seu enllaç de reserva aixequi un tiquet — un failover que ningú nota és un cost recurrent, no un rescat.
• Proveu el cable real, no només la ruta: estireu el connector del primari i cronometreu la commutació real.

Poseu el failover sota un únic pla de control

El failover WAN dual en un sol MikroTik és un problema resolt. Fer-ho de manera fiable a tota una flota — amb una configuració coherent i la capacitat de demostrar que la reserva funciona en un encaminador que no podeu arribar per IP pública — és on la majoria d’operadors perden diners. La gestió centralitzada i ancorada a la sortida tanca aquesta bretxa.

Comenceu la vostra prova gratuïta de MKController