MikroTik dubultā WAN rezerve ISP

Kopsavilkums MikroTik dubultā WAN rezerve uztur objektu tiešsaistē, automātiski pārvietojot trafiku uz rezerves pieslēgumu, kad primārais pieslēgums sabojājas. RouterOS sniedz trīs būvelementus — rekursīvo maršrutēšanu ar check-gateway, Netwatch un NAT katram WAN — un pareizā kombinācija atkarīga no tā, cik ātri un cik gudri jūsu noteikšanai jādarbojas. ISP parkiem grūtākā problēma ir nevis konfigurācijas fragments, bet apstiprināt, ka rezerve patiešām nostrādāja simtos attālu objektu aiz CGNAT. Šī rokasgrāmata aptver abus.

Kas ir MikroTik dubultā WAN rezerve?

MikroTik dubultā WAN rezerve ir RouterOS konfigurācija, kas sniedz maršrutētājam divus interneta pieslēgumus — primāro un rezerves — un automātiski pārvieto trafiku uz rezerves, kad primārais pārstāj laist paketes, un pēc atjaunošanās pārvieto atpakaļ. Tas nav tas pats, kas slodzes balansēšana: rezerve uztur vienu pieslēgumu dīkstāvē kā apdrošināšanu, savukārt slodzes balansēšana izkliedē trafiku pār abiem. Mērķis ir nepārtrauktība, nevis papildu joslas platums, un tieši tāpēc tas ir noklusējuma rezerves modelis objektiem, kuri vienkārši nedrīkst nodziest.

Mehānisms balstās uz maršruta izvēli. RouterOS izvēlas aktīvo noklusējuma maršrutu pēc zemākā administratīvā attāluma, tāpēc primārajam piešķirat mazāku attālumu, bet rezervei lielāku. Tad viss dizains noslēdzas vienā jautājumā: kā maršrutētājs izlemj, ka primārais ir „nost”, un pazemina tā maršrutu? Pieņemiet šo lēmumu pareizi — pietiekami ātri, bet ne nervozi — un rezerve būs uzticama. Izdariet to nepareizi, un jūs vai nu pārslēgsieties pārāk lēni, vai svārstīsieties starp pieslēgumiem ik pēc katras zaudētās paketes.

1. solis — Aprakstiet abus WAN, pirms pieskaraties maršrutam

Sāciet ar to, ka pierakstāt, kas patiesībā ir katrs pieslēgums. Fiksēts optiskās šķiedras vai PPPoE primārais ar statisku vai PPP piešķirtu vārteju uzvedas atšķirīgi no Starlink vai LTE rezerves, kas atrodas aiz Carrier-Grade NAT un piešķir jums dinamisku adresi. Tas ir svarīgi, jo rekursīvā maršrutēšana darbojas tikai ar stabiliem IP vārtejām, nevis ar dinamiskiem saskarņu tipiem kā PPPoE vai DHCP, kur adrese var mainīties (MikroTik dokumentācija — Failover (WAN Backup)). Izlemiet, kurš pieslēgums ir primārais, kurš rezerves, un vai kāds maina savu IP, atkārtoti savienojoties — šis viens fakts nosaka, kuru noteikšanas metodi varat izmantot.

2. solis — Pievienojiet rekursīvos noklusējuma maršrutus ar check-gateway

Klasiskā pieeja izmanto rekursīvo maršrutēšanu: tā vietā, lai noklusējuma maršrutu vērstu tieši uz nākamo pāreju, jūs to vēršat uz zondēšanas mērķi (piemēram, labi pazīstamu publisku risinātāju) un pievienojat statisku maršrutu, kas norāda RouterOS sasniegt šo mērķi tikai caur konkrētu WAN vārteju. Tad jūs izveidojat divus noklusējuma maršrutus, kas rekursīvi atrisināti pār šiem mērķiem — primāro ar mazāku attālumu un iespējotu check-gateway=ping, rezerves ar lielāku attālumu (Scoop — Basic ISP Failover with MikroTik).

Uzvedība, ap kuru jāplāno, ir laiks. Check-gateway atspējo maršrutu pēc divām secīgām neizdevušamies pārbaudēm, un pārbaudes notiek aptuveni ik pēc 10 sekundēm, tāpēc reālā pārslēgšanās notiek aptuveni 20–30 sekunžu laikā — un tā nereaģē uz periodisku pakešu zudumu, tikai uz pilnībā mirušu vārteju (MikroTik dokumentācija — Failover (WAN Backup)). Daudziem ISP klientu objektiem tas ir pieņemami. Balss vai maksājumu termināļiem bieži nav, un tieši šeit parādās 4. solis.

3. solis — Konfigurējiet NAT abiem pieslēgumiem

Dubultā WAN maršrutētājam ir nepieciešams atsevišķs masquerade (vai src-nat) noteikums katrai WAN saskarnei, lai jebkurš aktīvais pieslēgums pareizi tulkotu izejošo trafiku; viens pie vienas saskarnes piesaistīts noteikums klusi pārtrauks savienojamību brīdī, kad rezerve pārvieto trafiku uz otru pieslēgumu. Pievienojiet vienu masquerade noteikumu srcnat ķēdē primārajai out-interface un otru rezervei. Ja publicējat kādus ienākošos pakalpojumus, atcerieties, ka dst-nat noteikumi, kas piesaistīti primārā adresei, pārstāj darboties, tiklīdz šis pieslēgums — un tā publiskais IP — pazūd. Šī ienākošā trauslums ir tā pati arhitektūras lamatas, kas aplūkotas mūsu Starlink IP izmaiņu gadījumā, un tāpēc izejošā virzienā balstīta piekļuve mērogojas labāk nekā portu pāradresācija. NAT pamatiem skatiet mūsu NAT konfigurēšanas rokasgrāmatu MikroTik.

4. solis — Izmantojiet Netwatch, kad nepieciešama ātrāka vai gudrāka noteikšana

Kad 20–30 sekundes ir pārāk lēni vai jums jāreaģē uz degradētiem, bet dzīviem pieslēgumiem, Netwatch ir elastīgāks rīks. RouterOS v7 Netwatch ieguva type parametru, kas var zondēt ar icmp, tcp-conn, http-get, https-get vai simple, un jūs varat iestatīt savu pārbaudes intervālu, nevis dzīvot ar fiksēto check-gateway ritmu (MikroTik dokumentācija — Failover (WAN Backup)). Katram resursdatoram ir up un down skripts, tāpēc pārejas laikā varat atspējot primāro noklusējuma maršrutu, izsaukt brīdinājumu vai reģistrēt notikumu.

Daudzi operatori apvieno abus: rekursīvā maršrutēšana apstrādā tīru pieslēguma nāvi, savukārt Netwatch sedz nekārtīgākos gadījumus un sūta paziņojumus. Sen darbojošās kopienas tēma apspriež tieši šo kompromisu un ir vērts izlasīt, pirms standartizējat vienu metodi visam parkam (MikroTik forums — netwatch instead of recursive routing). Lai ko jūs izvēlētos, uzturiet konfigurāciju identisku katrā objektā — pielāgotu rezerves skriptu parks pats par sevi ir avārija, kas gaida notikšanu.

5. solis — Pārbaudiet rezervi katrā attālajā objektā

Lūk, daļa, ko konfigurācijas pamācības izlaiž. Pievienot maršrutus vienam stenda maršrutētājam ir viegli; pierādīt, ka rezerve darbojas simtos izvietotu CPE, ir patiesā ISP problēma — un tas kļūst grūtāk, kad rezerves pieslēgums ir Starlink vai LTE aiz CGNAT, jo ierīcei pēc pārslēgšanās bieži nav sasniedzama publiskā IP, lai to pārvaldītu. Ja rezervi varat apstiprināt tikai gaidot klienta zvanu, jums patiesībā nav rezerves; jums ir skripts, par kuru cerat, ka tas darbojas.

Šeit centralizētā pārvaldība maina ekonomiku. MKController uztur katru maršrutētāju sasniedzamu caur autentificētu izejošo tuneli, tāpēc varat apstiprināt, ka rezerves ceļš nes trafiku, vērot pārslēgšanās pāreju monitoringā un nosūtīt izlabotu konfigurāciju — neatkarīgi no publiskā IP, kura rezerves pieslēgumā varbūt nav. Apvienojiet to ar telemetriju: mūsu rokasgrāmatas par MikroTik attālo monitorēšanu ar Zabbix un SNMP monitorēšanu MikroTik parāda, kā brīdināt par pašu rezerves notikumu, lai klusa pārslēgšanās uz dārgo rezerves pieslēgumu nekad nepaliktu nepamanīta.

Padomi

• Uzturiet rezerves pieslēguma check-gateway zondi vērstu uz mērķi, ko sasniedzat caur šo pieslēgumu, nevis caur primāro, citādi jūsu tests ir bezjēdzīgs.
• Atzīmējiet rezerves pārejas savā monitoringā, lai objekts, kas dienām darbojas ar savu rezerves pieslēgumu, izraisītu pieteikumu — rezerve, ko neviens nepamana, ir atkārtotas izmaksas, nevis glābiņš.
• Testējiet īsto kabeli, ne tikai maršrutu: izvelciet primārā savienotāju un mēriet reālo pārslēgšanās laiku.

Apvienojiet rezervi zem vienas vadības plaknes

Dubultā WAN rezerve vienā MikroTik ir atrisināta problēma. To uzticami darīt visā parkā — ar konsekventu konfigurāciju un spēju pierādīt, ka rezerve darbojas maršrutētājā, kuru nevarat sasniegt pa publisko IP — ir tur, kur lielākā daļa operatoru zaudē naudu. Centralizēta, izejošā virzienā balstīta pārvaldība aizpilda šo plaisu.

Sāciet savu bezmaksas MKController izmēģinājumu