MikroTik kahe WAN-i tõrkesiire ISP-le

Kokkuvõte MikroTik kahe WAN-i tõrkesiire hoiab asukoha online’is, viies liikluse automaatselt varu-ülesvoolule, kui peamine ühendus tõrgub. RouterOS annab kolm ehitusplokki — rekursiivne marsruutimine koos check-gateway’ga, Netwatch ja WAN-põhine NAT — ja õige kombinatsioon sõltub sellest, kui kiire ja kui nutikas peab teie tuvastus olema. ISP-parkide jaoks ei ole keerulisem probleem mitte konfiguratsiooni katke, vaid kinnitada sadade kaugemate CGNAT-i taga olevate asukohtade lõikes, et tõrkesiire tõesti töötas. See juhend käsitleb mõlemat.

Mis On MikroTik Kahe WAN-i Tõrkesiire?

MikroTik kahe WAN-i tõrkesiire on RouterOS-i konfiguratsioon, mis annab ruuterile kaks interneti-ülesvoolu — peamise ja varu — ning viib liikluse automaatselt varule, kui peamine lakkab pakette läbi laskmast, ning lükkab selle taastumisel tagasi. See ei ole sama mis koormusjaotus: tõrkesiire hoiab ühe ühenduse kindlustusena jõude, samas kui koormusjaotus jaotab liiklust mõlema vahel. Eesmärk on pidevus, mitte lisaribalaius, ning just seetõttu on see vaikimisi liiasusmuster asukohtadele, mis lihtsalt ei tohi pimedaks minna.

Mehhanism toetub marsruudi valikule. RouterOS valib aktiivse vaikemarsruudi madalaima administratiivse kauguse järgi, seega annad peamisele väiksema kauguse ja varule suurema. Kogu disain taandub siis ühele küsimusele: kuidas otsustab ruuter, et peamine on „maas”, ja alandab selle marsruuti? Tee see otsus õigesti — piisavalt kiiresti, kuid mitte närviliselt — ja tõrkesiire on usaldusväärne. Tee see valesti ning kas lülitad ümber liiga aeglaselt või vilgud iga kaotatud paketi peale ühenduste vahel.

Samm 1 — Kaardista mõlemad WAN-id enne marsruudi puutumist

Alusta sellest, et paned kirja, mis iga ülesvool tegelikult on. Fikseeritud kiudoptika või PPPoE peamine staatilise või PPP-määratud lüüsiga käitub erinevalt kui Starlink- või LTE-varu, mis istub Carrier-Grade NAT-i taga ja annab sulle dünaamilise aadressi. See on oluline, sest rekursiivne marsruutimine töötab ainult stabiilsete IP-lüüsidega, mitte dünaamiliste liiditüüpidega nagu PPPoE või DHCP, kus aadress võib muutuda (MikroTik dokumentatsioon — Failover (WAN Backup)). Otsusta, milline ühendus on peamine, milline varu ja kas kumbki vahetab uuesti ühendumisel oma IP — see üksainus fakt määrab, millist tuvastusmeetodit saad kasutada.

Samm 2 — Lisa check-gateway’ga rekursiivsed vaikemarsruudid

Klassikaline lähenemine kasutab rekursiivset marsruutimist: selle asemel et suunata vaikemarsruut otse järgmisele hüppele, suunad selle proovisihtmärgile (näiteks tuntud avalik resolver) ja lisad staatilise marsruudi, mis käsib RouterOS-il seda sihtmärki saavutada ainult konkreetse WAN-lüüsi kaudu. Seejärel lood kaks vaikemarsruuti, mis lahendatakse rekursiivselt nende sihtmärkide kaudu — peamine väiksema kauguse ja lubatud check-gateway=ping-iga, varu suurema kaugusega (Scoop — Basic ISP Failover with MikroTik).

Käitumine, mille ümber planeerida, on ajastus. Check-gateway deaktiveerib marsruudi pärast kahte järjestikust ebaõnnestunud kontrolli ning kontrollid jooksevad umbes iga 10 sekundi tagant, seega tegelik ümberlülitus jääb umbes 20 kuni 30 sekundi juurde — ning see ei reageeri vahelduvale paketikaole, ainult täielikult surnud lüüsile (MikroTik dokumentatsioon — Failover (WAN Backup)). Paljude ISP klientide asukohtade jaoks on see vastuvõetav. Kõne- või makseterminalide jaoks sageli mitte, ning just siin tuleb mängu samm 4.

Samm 3 — Seadista NAT mõlema ülesvoolu jaoks

Kahe WAN-iga ruuter vajab eraldi masquerade- (või src-nat-) reeglit iga WAN-liidese kohta, et see ühendus, mis on parajasti aktiivne, tõlgiks väljuvat liiklust õigesti; üksainus ühe liidesega seotud reegel katkestab ühenduse vaikselt sel hetkel, kui tõrkesiire viib liikluse teisele ühendusele. Lisa üks masquerade-reegel srcnat-ahelasse peamise out-interface’i jaoks ja teine varu jaoks. Kui avaldad mõne sissetuleva teenuse, pea meeles, et peamise aadressiga seotud dst-nat-reeglid lakkavad töötamast, kui see ühendus — ja selle avalik IP — kaob. See sissetuleku haprus on sama arhitektuuriline lõks, mida käsitleti meie Starlinki IP-muudatuste juhtumis, ning seetõttu skaleerub väljundankurdatud juurdepääs paremini kui pordisuunamine. NAT-i põhitõdede kohta vaata meie juhendit NAT-i seadistamiseks MikroTikis.

Samm 4 — Kasuta Netwatch’i, kui vajad kiiremat või nutikamat tuvastust

Kui 20–30 sekundit on liiga aeglane või pead reageerima degradeerunud-aga-elusatele ühendustele, on Netwatch paindlikum tööriist. RouterOS v7-s sai Netwatch type-parameetri, mis suudab proovida icmp, tcp-conn, http-get, https-get või simple abil, ning saad määrata oma kontrolliintervalli, selle asemel et elada check-gateway fikseeritud taktiga (MikroTik dokumentatsioon — Failover (WAN Backup)). Igal hostil on up- ja down-skript, nii et saad üleminekul keelata peamise vaikemarsruudi, käivitada alarmi või logida sündmuse.

Paljud operaatorid kombineerivad mõlemat: rekursiivne marsruutimine tegeleb puhta ühenduse surmaga, samas kui Netwatch katab segasemad juhud ja saadab teateid. Pikalt kestnud kogukonna lõim arutab täpselt seda kompromissi ja seda tasub lugeda enne, kui standardiseerid ühe meetodi kogu pargi lõikes (MikroTik foorum — netwatch instead of recursive routing). Mille iganes valid, hoia konfiguratsioon igal asukohal identne — park omavalmistatud tõrkesiire-skripte on ise tõrge, mis lihtsalt ootab juhtumist.

Samm 5 — Kontrolli tõrkesiiret igal kaugel asukohal

Siin on see osa, mille konfiguratsiooni-õpetused vahele jätavad. Marsruutide lisamine ühele lauaruuterile on lihtne; tõestada, et tõrkesiire töötab sadadel paigaldatud CPE-del, on tegelik ISP-probleem — ja see muutub raskemaks, kui varuühendus on Starlink või LTE CGNAT-i taga, sest seadmel pole ümberlülituse järel sageli kättesaadavat avalikku IP-d, mille kaudu seda hallata. Kui suudad tõrkesiiret kinnitada ainult kliendi kõnet oodates, ei ole sul tegelikult tõrkesiiret; sul on skript, mille puhul loodad, et see jookseb.

Siin muudab tsentraliseeritud haldus majandust. MKController hoiab iga ruuteri kättesaadavaks autenditud väljuva tunneli kaudu, nii et saad kinnitada, et varutee kannab liiklust, jälgida tõrkesiire üleminekut monitooringus ja saata parandatud konfiguratsiooni — sõltumata avalikust IP-st, mida varuühendusel võib-olla ei eksisteeri. Ühenda see telemeetriaga: meie juhendid MikroTiki kaugmonitooringust Zabbixiga ja SNMP-monitooringust MikroTikile näitavad, kuidas alarmeerida tõrkesiire sündmuse enda kohta, nii et vaikne üleminek kallile varuühendusele ei jää kunagi märkamatuks.

Näpunäited

• Hoia varuühenduse check-gateway-proovi suunatud sihtmärgile, mille saavutad läbi selle ühenduse, mitte peamise kaudu, muidu on su test mõttetu.
• Märgista tõrkesiire üleminekud oma monitooringus, et päevi varu-ülesvoolul töötav asukoht tõstaks pileti — tõrkesiire, mida keegi ei märka, on korduv kulu, mitte päästetud olukord.
• Testi tegelikku kaablit, mitte ainult marsruuti: tõmba peamise pistik välja ja mõõda tegelik ümberlülitusaeg.

Too tõrkesiire ühe juhttasandi alla

Kahe WAN-i tõrkesiire ühel MikroTikil on lahendatud probleem. Selle usaldusväärne tegemine kogu pargi lõikes — järjepideva konfiguratsiooni ja võimega tõestada, et varu töötab ruuteril, milleni sa avaliku IP kaudu ei jõua — on koht, kus enamik operaatoreid kaotab raha. Tsentraliseeritud, väljundankurdatud haldus sulgeb selle lünga.

Alusta oma tasuta MKControlleri prooviperioodi