Tutorial
MikroTik dubbel-WAN-oorskakeling vir ISP'e
Hoe om betroubare MikroTik dubbel-WAN-oorskakeling vir 'n ISP-vloot te bou: rekursiewe roetering, Netwatch, NAT per WAN, oorskakeltyd en afstandverifikasie.
Opsomming MikroTik dubbel-WAN-oorskakeling hou ‘n terrein aanlyn deur verkeer outomaties na ‘n rugsteun-uplink te skuif wanneer die primêre skakel misluk. RouterOS gee jou drie boustene — rekursiewe roetering met check-gateway, Netwatch en NAT per WAN — en die regte kombinasie hang af van hoe vinnig en hoe slim jou opsporing moet wees. Vir ISP-vlote is die moeiliker probleem nie die konfigurasie-brokkie nie, maar om oor honderde afgeleë terreine agter CGNAT te bevestig dat die oorskakeling werklik gewerk het. Hierdie gids dek albei.
Wat Is MikroTik dubbel-WAN-oorskakeling?
MikroTik dubbel-WAN-oorskakeling is ‘n RouterOS-konfigurasie wat ‘n roeteerder twee internet-uplinks gee — ‘n primêre en ‘n rugsteun — en verkeer outomaties na die rugsteun skuif wanneer die primêre ophou om pakkette deur te gee, en dan terugskuif wanneer dit herstel. Dit is nie dieselfde as lasverdeling nie: oorskakeling hou een skakel as versekering ledig, terwyl lasverdeling verkeer oor albei versprei. Die doel is kontinuïteit, nie ekstra bandwydte nie, en daarom is dit die standaard-redundansiepatroon vir terreine wat eenvoudig nie donker kan word nie.
Die meganisme berus op roete-keuse. RouterOS kies die aktiewe verstekroete volgens die laagste administratiewe afstand, dus gee jy die primêre ‘n kleiner afstand en die rugsteun ‘n groter een. Die hele ontwerp verminder dan tot een vraag: hoe besluit die roeteerder dat die primêre “af” is en gradeer sy roete af? Kry daardie besluit reg — vinnig genoeg, maar nie senuweeagtig nie — en oorskakeling is betroubaar. Kry dit verkeerd en jy skakel óf te stadig oor óf flikker tussen skakels by elke pakkie wat verlore gaan.
Stap 1 — Karteer die twee WAN’s voordat jy aan ‘n roete raak
Begin deur neer te skryf wat elke uplink werklik is. ‘n Vaste vesel- of PPPoE-primêre met ‘n statiese of PPP-toegekende gateway gedra anders as ‘n Starlink- of LTE-rugsteun wat agter Carrier-Grade NAT sit en jou ‘n dinamiese adres gee. Dit maak saak omdat rekursiewe roetering net met stabiele IP-gateways werk, nie met dinamiese interface-tipes soos PPPoE of DHCP waar die adres kan verander nie (MikroTik-dokumentasie — Failover (WAN Backup)). Besluit watter skakel primêr is, watter rugsteun is, en of enigeen sy IP verander met herverbinding — daardie enkele feit bepaal watter opsporingsmetode jy kan gebruik.
Stap 2 — Voeg rekursiewe verstekroetes met check-gateway by
Die klassieke benadering gebruik rekursiewe roetering: in plaas daarvan om die verstekroete direk na ‘n volgende hop te wys, wys jy dit na ‘n probe-teiken (byvoorbeeld ‘n bekende publieke resolver) en voeg ‘n statiese roete by wat RouterOS vertel om daardie teiken net deur ‘n spesifieke WAN-gateway te bereik. Jy skep dan twee verstekroetes wat rekursief oor daardie teikens opgelos word — die primêre met ‘n kleiner afstand en check-gateway=ping geaktiveer, die rugsteun met ‘n groter afstand (Scoop — Basic ISP Failover with MikroTik).
Die gedrag waarom beplan moet word, is tydsberekening. Check-gateway deaktiveer ‘n roete na twee opeenvolgende mislukte kontroles, en kontroles loop ongeveer elke 10 sekondes, sodat die werklike oorskakeling rondom 20 tot 30 sekondes land — en dit reageer nie op intermitterende pakkieverlies nie, net op ‘n volledig dooie gateway (MikroTik-dokumentasie — Failover (WAN Backup)). Vir baie ISP-kliëntterreine is dit aanvaarbaar. Vir stem- of betaalterminale dikwels nie, en dit is waar Stap 4 inkom.
Stap 3 — Stel NAT vir albei uplinks op
‘n Dubbel-WAN-roeteerder benodig ‘n afsonderlike masquerade- (of src-nat-)reël per WAN-interface sodat watter skakel ook al aktief is, uitgaande verkeer korrek vertaal; ‘n enkele reël wat aan een interface gebind is, sal konnektiwiteit stilweg breek die oomblik wanneer oorskakeling verkeer na die ander skakel skuif. Voeg een masquerade-reël in die srcnat-ketting vir die primêre out-interface by en ‘n tweede vir die rugsteun. As jy enige inkomende dienste publiseer, onthou dat dst-nat-reëls wat aan die primêre se adres gekoppel is, ophou werk sodra daardie skakel — en sy publieke IP — verdwyn. Daardie inkomende broosheid is dieselfde argitektoniese strik wat in ons Starlink-IP-veranderinge geval behandel word, en dit is hoekom uitgaande-verankerde toegang beter skaal as poort-aanstuur. Vir die NAT-grondbeginsels, sien ons gids om NAT op MikroTik op te stel.
Stap 4 — Gebruik Netwatch wanneer jy vinniger of slimmer opsporing nodig het
Wanneer 20–30 sekondes te stadig is of jy moet optree op gedegradeerde-maar-lewende skakels, is Netwatch die buigsamer hulpmiddel. In RouterOS v7 het Netwatch ‘n type-parameter gekry wat met icmp, tcp-conn, http-get, https-get of simple kan probe, en jy kan jou eie kontrole-interval stel eerder as om met check-gateway se vaste kadens te leef (MikroTik-dokumentasie — Failover (WAN Backup)). Elke gasheer het ‘n up- en ‘n down-skrip, sodat jy die primêre verstekroete kan deaktiveer, ‘n waarskuwing kan oplig of die gebeurtenis by oorgang kan log.
Baie operateurs kombineer die twee: rekursiewe roetering hanteer skoon skakel-dood, terwyl Netwatch die rommeliger gevalle dek en kennisgewings stuur. ‘n Langlopende gemeenskapsdraad debatteer presies hierdie afruil en is die moeite werd om te lees voordat jy op een metode oor ‘n vloot standaardiseer (MikroTik-forum — netwatch instead of recursive routing). Wat jy ook al kies, hou die konfigurasie op elke terrein identies — ‘n vloot pasgemaakte oorskakelingskripte is self ‘n onderbreking wat net wag om te gebeur.
Stap 5 — Verifieer oorskakeling op elke afgeleë terrein
Hier is die deel wat die konfigurasie-tutoriale oorslaan. Om die roetes op een werkbank-roeteerder by te voeg is maklik; om te bewys dat oorskakeling op honderde ontplooide CPE’s werk, is die werklike ISP-probleem — en dit word moeiliker wanneer die rugsteunskakel Starlink of LTE agter CGNAT is, omdat die toestel dikwels geen bereikbare publieke IP het om dit deur te bestuur na dit oorgeskakel het nie. As jy oorskakeling net kan bevestig deur te wag vir ‘n kliënt om te bel, het jy nie werklik oorskakeling nie; jy het ‘n skrip waarvan jy hoop dat dit loop.
Hier verander gesentraliseerde bestuur die ekonomie. MKController hou elke roeteerder bereikbaar deur ‘n geverifieerde uitgaande tonnel, sodat jy kan bevestig dat die rugsteunpad verkeer dra, die oorskakeling-oorgang in monitering kan dophou, en ‘n reggestelde konfigurasie kan uitstoot — sonder om afhanklik te wees van ‘n publieke IP wat dalk nie op die rugsteunskakel bestaan nie. Paar dit met telemetrie: ons gidse oor afstandmonitering van MikroTik met Zabbix en SNMP-monitering vir MikroTik wys hoe om op die oorskakeling-gebeurtenis self te waarsku, sodat ‘n stille skakeling na die duur rugsteunskakel nooit ongemerk verbygaan nie.
Wenke
- Hou die rugsteunskakel se
check-gateway-probe gerig op ‘n teiken wat jy deur daardie skakel bereik, nie deur die primêre nie, anders is jou toets betekenisloos. - Merk oorskakeling-oorgange in jou monitering sodat ‘n terrein wat dae lank op sy rugsteun-uplink loop ‘n kaartjie oplig — oorskakeling wat niemand opmerk nie, is ‘n herhalende koste, nie ‘n redding nie.
- Toets die werklike kabel, nie net die roete nie: trek die primêre se konnektor uit en meet die werklike oorskakeltyd.
Bring oorskakeling onder een beheervlak
Dubbel-WAN-oorskakeling op ‘n enkele MikroTik is ‘n opgeloste probleem. Om dit betroubaar oor ‘n vloot te doen — met konsekwente konfigurasie en die vermoë om te bewys dat die rugsteun werk op ‘n roeteerder wat jy nie per publieke IP kan bereik nie — is waar die meeste operateurs geld verloor. Gesentraliseerde, uitgaande-verankerde bestuur sluit daardie gaping.