MikroTik dvigubo WAN perjungimas ISP

Santrauka MikroTik dvigubo WAN perjungimas išlaiko objektą prisijungusį, automatiškai perkeldamas srautą į atsarginę jungtį, kai pagrindinė jungtis sugenda. RouterOS suteikia tris statybinius blokus — rekursinį maršrutizavimą su check-gateway, Netwatch ir NAT kiekvienam WAN — o tinkamas derinys priklauso nuo to, kaip greitai ir kaip protingai turi veikti jūsų aptikimas. ISP parkams sunkesnė problema yra ne konfigūracijos fragmentas, o patvirtinti, kad perjungimas tikrai suveikė šimtuose nutolusių objektų už CGNAT. Šiame vadove aptariama abi.

Kas yra MikroTik dvigubo WAN perjungimas?

MikroTik dvigubo WAN perjungimas yra RouterOS konfigūracija, suteikianti maršrutizatoriui dvi interneto jungtis — pagrindinę ir atsarginę — ir automatiškai perkelianti srautą į atsarginę, kai pagrindinė nustoja perduoti paketus, o po atsigavimo perkelia atgal. Tai nėra tas pats kas apkrovos balansavimas: perjungimas vieną jungtį laiko neveiklią kaip draudimą, o apkrovos balansavimas paskirsto srautą tarp abiejų. Tikslas yra tęstinumas, o ne papildomas pralaidumas, todėl tai yra numatytasis atsparumo modelis objektams, kurie tiesiog negali nutrūkti.

Mechanizmas remiasi maršruto pasirinkimu. RouterOS pasirenka aktyvų numatytąjį maršrutą pagal mažiausią administracinį atstumą, todėl pagrindinei suteikiate mažesnį atstumą, o atsarginei didesnį. Tada visas dizainas susiveda į vieną klausimą: kaip maršrutizatorius nusprendžia, kad pagrindinė yra „neveikianti”, ir pažemina jos maršrutą? Priimkite šį sprendimą teisingai — pakankamai greitai, bet ne nervingai — ir perjungimas bus patikimas. Padarykite tai neteisingai, ir arba perjungsite per lėtai, arba blaškysitės tarp jungčių kiekvienam paketo praradimui.

1 žingsnis — Aprašykite abu WAN prieš liesdami maršrutą

Pradėkite užrašydami, kas iš tikrųjų yra kiekviena jungtis. Fiksuotas optinis arba PPPoE pagrindinis ryšys su statiniu arba PPP priskirtu šliuzu elgiasi kitaip nei Starlink arba LTE atsarginis ryšys, kuris yra už Carrier-Grade NAT ir suteikia jums dinaminį adresą. Tai svarbu, nes rekursinis maršrutizavimas veikia tik su stabiliais IP šliuzais, o ne su dinaminiais sąsajų tipais kaip PPPoE arba DHCP, kuriuose adresas gali keistis (MikroTik dokumentacija — Failover (WAN Backup)). Nuspręskite, kuri jungtis yra pagrindinė, kuri atsarginė, ir ar kuri nors keičia savo IP prisijungiant iš naujo — šis vienas faktas lemia, kurį aptikimo metodą galite naudoti.

2 žingsnis — Pridėkite rekursinius numatytuosius maršrutus su check-gateway

Klasikinis būdas naudoja rekursinį maršrutizavimą: užuot nukreipus numatytąjį maršrutą tiesiai į kitą šuolį, nukreipiate jį į zondavimo taikinį (pavyzdžiui, gerai žinomą viešąjį skiriklį) ir pridedate statinį maršrutą, nurodantį RouterOS pasiekti tą taikinį tik per konkretų WAN šliuzą. Tada sukuriate du numatytuosius maršrutus, rekursyviai sprendžiamus per tuos taikinius — pagrindinį su mažesniu atstumu ir įjungtu check-gateway=ping, o atsarginį su didesniu atstumu (Scoop — Basic ISP Failover with MikroTik).

Elgsena, kurią reikia planuoti, yra laikas. Check-gateway išjungia maršrutą po dviejų iš eilės nepavykusių patikrinimų, o patikrinimai vyksta maždaug kas 10 sekundžių, todėl realus perjungimas įvyksta maždaug per 20–30 sekundžių — ir jis nereaguoja į pertrūkius paketų praradime, tik į visiškai neveikiantį šliuzą (MikroTik dokumentacija — Failover (WAN Backup)). Daugeliui ISP klientų objektų tai priimtina. Balso arba mokėjimo terminalams dažnai ne, ir būtent čia atsiranda 4 žingsnis.

3 žingsnis — Sukonfigūruokite NAT abiem jungtims

Dvigubo WAN maršrutizatoriui reikia atskiros masquerade (arba src-nat) taisyklės kiekvienai WAN sąsajai, kad bet kuri aktyvi jungtis teisingai transliuotų išeinantį srautą; viena prie vienos sąsajos pririšta taisyklė tyliai nutrauks ryšį tą akimirką, kai perjungimas perkels srautą į kitą jungtį. Pridėkite vieną masquerade taisyklę srcnat grandinėje pagrindinei out-interface ir antrą atsarginei. Jei publikuojate kokias nors įeinančias paslaugas, atminkite, kad dst-nat taisyklės, susietos su pagrindinės adresu, nustoja veikti, kai ta jungtis — ir jos viešasis IP — dingsta. Šis įeinantis trapumas yra ta pati architektūrinė spąstų vieta, aptarta mūsų Starlink IP pokyčių atvejyje, ir todėl išeinančia kryptimi pagrįsta prieiga keičiasi mastu geriau nei prievadų peradresavimas. NAT pagrindams žiūrėkite mūsų NAT konfigūravimo MikroTik vadovą.

4 žingsnis — Naudokite Netwatch, kai reikia greitesnio ar protingesnio aptikimo

Kai 20–30 sekundžių per lėta arba reikia reaguoti į pablogėjusias, bet gyvas jungtis, Netwatch yra lankstesnis įrankis. RouterOS v7 Netwatch gavo type parametrą, kuris gali zonduoti su icmp, tcp-conn, http-get, https-get arba simple, ir galite nustatyti savo patikrinimo intervalą, užuot gyvenę su fiksuota check-gateway sparta (MikroTik dokumentacija — Failover (WAN Backup)). Kiekvienas mazgas turi up ir down scenarijų, todėl perėjimo metu galite išjungti pagrindinį numatytąjį maršrutą, sukelti įspėjimą arba užregistruoti įvykį.

Daugelis operatorių derina abu: rekursinis maršrutizavimas tvarko švarią jungties mirtį, o Netwatch dengia netvarkingesnius atvejus ir siunčia pranešimus. Ilgai trunkanti bendruomenės gija aptaria būtent šį kompromisą ir verta perskaityti prieš standartizuojant vieną metodą visam parkui (MikroTik forumas — netwatch instead of recursive routing). Kad ir ką pasirinktumėte, laikykite konfigūraciją identišką kiekviename objekte — pritaikytų perjungimo scenarijų parkas pats yra avarija, laukianti įvykti.

5 žingsnis — Patikrinkite perjungimą kiekviename nutolusiame objekte

Štai dalis, kurią konfigūracijos vadovėliai praleidžia. Pridėti maršrutus viename stendo maršrutizatoriuje yra lengva; įrodyti, kad perjungimas veikia šimtuose įdiegtų CPE, yra tikroji ISP problema — ir tai tampa sunkiau, kai atsarginė jungtis yra Starlink arba LTE už CGNAT, nes įrenginys po perjungimo dažnai neturi pasiekiamo viešojo IP, per kurį jį valdyti. Jei perjungimą galite patvirtinti tik laukdami kliento skambučio, jūs iš tikrųjų neturite perjungimo; turite scenarijų, kurį tikitės, kad veikia.

Štai kur centralizuotas valdymas keičia ekonomiką. MKController išlaiko kiekvieną maršrutizatorių pasiekiamą per autentifikuotą išeinantį tunelį, todėl galite patvirtinti, kad atsarginis kelias perduoda srautą, stebėti perjungimo perėjimą monitoringe ir įdiegti pataisytą konfigūraciją — nepriklausydami nuo viešojo IP, kurio atsarginėje jungtyje gali nebūti. Suderinkite tai su telemetrija: mūsų vadovai apie nuotolinį MikroTik stebėjimą su Zabbix ir SNMP stebėjimą MikroTik parodo, kaip įspėti apie patį perjungimo įvykį, kad tylus perėjimas prie brangios atsarginės jungties niekada neliktų nepastebėtas.

Patarimai

• Laikykite atsarginės jungties check-gateway zondą nukreiptą į taikinį, kurį pasiekiate per tą jungtį, o ne per pagrindinę, kitaip jūsų testas yra beprasmis.
• Pažymėkite perjungimo perėjimus savo monitoringe, kad objektas, dienų dienas veikiantis atsargine jungtimi, sukeltų bilietą — perjungimas, kurio niekas nepastebi, yra pasikartojanti išlaida, o ne išgelbėjimas.
• Testuokite tikrą kabelį, ne tik maršrutą: ištraukite pagrindinės jungiklį ir matuokite realų perjungimo laiką.

Suburkite perjungimą po viena valdymo plokštuma

Dvigubo WAN perjungimas viename MikroTik yra išspręsta problema. Patikimai tai daryti visame parke — su nuoseklia konfigūracija ir galimybe įrodyti, kad atsarginė veikia maršrutizatoriuje, kurio negalite pasiekti per viešąjį IP — yra ten, kur dauguma operatorių praranda pinigus. Centralizuotas, išeinančia kryptimi pagrįstas valdymas užpildo šią spragą.

Pradėkite nemokamą MKController bandymą