MikroTik kahden WANin vikasietos ISP

Yhteenveto MikroTik-kahden WANin vikasietos pitää toimipaikan verkossa siirtämällä liikenteen automaattisesti vara-uplinkille, kun ensisijainen yhteys pettää. RouterOS antaa kolme rakennuspalikkaa — rekursiivisen reitityksen check-gatewaylla, Netwatchin ja WAN-kohtaisen NATin — ja oikea yhdistelmä riippuu siitä, kuinka nopea ja kuinka älykäs tunnistuksesi on oltava. ISP-laitteistoille vaikeampi ongelma ei ole konfiguraatiopätkä, vaan sen vahvistaminen sadoissa etätoimipaikoissa CGNATin takana, että vikasietos todella toimi. Tämä opas käsittelee molemmat.

Mikä On MikroTik-kahden WANin Vikasietos?

MikroTik-kahden WANin vikasietos on RouterOS-konfiguraatio, joka antaa reitittimelle kaksi internet-uplinkkiä — ensisijaisen ja varan — ja siirtää liikenteen automaattisesti varalle, kun ensisijainen lakkaa päästämästä paketteja läpi, ja siirtää sen takaisin, kun se toipuu. Se ei ole sama asia kuin kuormantasaus: vikasietos pitää yhden yhteyden vakuutuksena joutilaana, kun taas kuormantasaus jakaa liikenteen molempien kesken. Tavoitteena on jatkuvuus, ei lisäkaistanleveys, minkä vuoksi se on oletusarvoinen redundanssimalli toimipaikoille, jotka eivät yksinkertaisesti saa pimentyä.

Mekanismi nojaa reitin valintaan. RouterOS valitsee aktiivisen oletusreitin pienimmän hallinnollisen etäisyyden mukaan, joten annat ensisijaiselle pienemmän etäisyyden ja varalle suuremman. Koko suunnittelu pelkistyy silloin yhteen kysymykseen: miten reititin päättää, että ensisijainen on “alhaalla”, ja alentaa sen reitin? Tee tämä päätös oikein — riittävän nopeasti, mutta ei hermostuneesti — ja vikasietos on luotettava. Tee se väärin, niin joko vaihdat liian hitaasti tai heilut yhteyksien välillä joka hukatun paketin kohdalla.

Vaihe 1 — Kartoita molemmat WANit ennen kuin kosket reittiin

Aloita kirjaamalla ylös, mitä kukin uplinkki todella on. Kiinteä kuitu- tai PPPoE-ensisijainen staattisella tai PPP:n määräämällä yhdyskäytävällä käyttäytyy eri tavalla kuin Starlink- tai LTE-vara, joka istuu Carrier-Grade NATin takana ja antaa sinulle dynaamisen osoitteen. Tällä on väliä, koska rekursiivinen reititys toimii vain vakaiden IP-yhdyskäytävien kanssa, ei dynaamisten rajapintatyyppien kuten PPPoE:n tai DHCP:n kanssa, joissa osoite voi muuttua (MikroTik-dokumentaatio — Failover (WAN Backup)). Päätä, mikä yhteys on ensisijainen, mikä vara ja vaihtaako jompikumpi IP:nsä uudelleenyhdistäessä — tämä yksi tosiasia sanelee, mitä tunnistusmenetelmää voit käyttää.

Vaihe 2 — Lisää rekursiiviset oletusreitit check-gatewaylla

Klassinen lähestymistapa käyttää rekursiivista reititystä: sen sijaan että osoittaisit oletusreitin suoraan seuraavaan hyppyyn, osoitat sen mittauskohteeseen (esimerkiksi tunnettuun julkiseen resolveriin) ja lisäät staattisen reitin, joka käskee RouterOSia tavoittamaan tämän kohteen vain tietyn WAN-yhdyskäytävän kautta. Sitten luot kaksi oletusreittiä, jotka ratkaistaan rekursiivisesti näiden kohteiden kautta — ensisijaisen pienemmällä etäisyydellä ja käytössä olevalla check-gateway=pingillä, varan suuremmalla etäisyydellä (Scoop — Basic ISP Failover with MikroTik).

Käyttäytyminen, jonka ympärille on suunniteltava, on ajoitus. Check-gateway poistaa reitin käytöstä kahden peräkkäisen epäonnistuneen tarkistuksen jälkeen, ja tarkistukset suoritetaan noin 10 sekunnin välein, joten todellinen vaihto osuu noin 20–30 sekuntiin — eikä se reagoi ajoittaiseen pakettihäviöön, vain täysin kuolleeseen yhdyskäytävään (MikroTik-dokumentaatio — Failover (WAN Backup)). Monille ISP:n asiakastoimipaikoille se on hyväksyttävää. Puhe- tai maksupäätteille usein ei, ja juuri tässä vaihe 4 tulee mukaan.

Vaihe 3 — Määritä NAT molemmille uplinkeille

Kahden WANin reititin tarvitsee erillisen masquerade- (tai src-nat-) säännön kutakin WAN-rajapintaa kohden, jotta kulloinkin aktiivinen yhteys kääntää lähtevän liikenteen oikein; yksittäinen yhteen rajapintaan sidottu sääntö rikkoo yhteyden hiljaisesti sillä hetkellä, kun vikasietos siirtää liikenteen toiselle yhteydelle. Lisää yksi masquerade-sääntö srcnat-ketjuun ensisijaiselle out-interfacelle ja toinen varalle. Jos julkaiset saapuvia palveluja, muista, että ensisijaisen osoitteeseen sidotut dst-nat-säännöt lakkaavat toimimasta, kun tuo yhteys — ja sen julkinen IP — katoaa. Tämä saapuvan liikenteen hauraus on sama arkkitehtoninen ansa, joka käsiteltiin Starlinkin IP-muutosten tapauksessamme, ja siksi lähtevyysankkuroitu pääsy skaalautuu paremmin kuin porttiohjaus. NATin perusteista katso opas NATin määrittämiseen MikroTikissa.

Vaihe 4 — Käytä Netwatchia, kun tarvitset nopeampaa tai älykkäämpää tunnistusta

Kun 20–30 sekuntia on liian hidasta tai sinun on reagoitava heikentyneisiin-mutta-eläviin yhteyksiin, Netwatch on joustavampi työkalu. RouterOS v7:ssä Netwatch sai type-parametrin, joka voi mitata icmp-, tcp-conn-, http-get-, https-get- tai simple-menetelmällä, ja voit asettaa oman tarkistusvälisi sen sijaan, että eläisit check-gatewayn kiinteän tahdin kanssa (MikroTik-dokumentaatio — Failover (WAN Backup)). Jokaisella isännällä on up- ja down-skripti, joten voit siirtymässä poistaa ensisijaisen oletusreitin käytöstä, nostaa hälytyksen tai kirjata tapahtuman lokiin.

Monet operaattorit yhdistävät molemmat: rekursiivinen reititys hoitaa puhtaan yhteyden kuoleman, kun taas Netwatch kattaa sotkuisemmat tapaukset ja lähettää ilmoituksia. Pitkään kestänyt yhteisön ketju puntaroi juuri tätä kompromissia ja kannattaa lukea ennen kuin standardoit yhden menetelmän koko laitteistolle (MikroTik-foorumi — netwatch instead of recursive routing). Minkä tahansa valitsetkin, pidä konfiguraatio identtisenä jokaisella toimipaikalla — laitteisto räätälöityjä vikasietosskriptejä on itsessään katko, joka odottaa tapahtumistaan.

Vaihe 5 — Tarkista vikasietos jokaisella etätoimipaikalla

Tässä on se osa, jonka konfiguraatio-oppaat ohittavat. Reittien lisääminen yhteen pöytäreitittimeen on helppoa; sen todistaminen, että vikasietos toimii sadoilla käyttöönotetuilla CPE-laitteilla, on todellinen ISP-ongelma — ja se vaikeutuu, kun varayhteys on Starlink tai LTE CGNATin takana, koska laitteella ei usein ole vaihdon jälkeen tavoitettavaa julkista IP:tä, jonka kautta sitä hallita. Jos voit vahvistaa vikasietoksen vain odottamalla asiakkaan soittoa, sinulla ei oikeastaan ole vikasietosta; sinulla on skripti, jonka toivot ajautuvan.

Tässä keskitetty hallinta muuttaa taloutta. MKController pitää jokaisen reitittimen tavoitettavissa todennetun lähtevän tunnelin kautta, joten voit vahvistaa, että varareitti kuljettaa liikennettä, seurata vikasietossiirtymää valvonnassa ja työntää korjatun konfiguraation — riippumatta julkisesta IP:stä, jota varayhteydellä ei ehkä ole. Yhdistä se telemetriaan: oppaamme MikroTikin etävalvonnasta Zabbixilla ja SNMP-valvonnasta MikroTikille näyttävät, miten hälyttää itse vikasietostapahtumasta, jotta hiljainen vaihto kalliille varayhteydelle ei koskaan jää huomaamatta.

Vinkit

• Pidä varayhteyden check-gateway-mittaus suunnattuna kohteeseen, jonka tavoitat tämän yhteyden kautta, et ensisijaisen kautta, muuten testisi on merkityksetön.
• Merkitse vikasietossiirtymät valvonnassasi, jotta päiviä vara-uplinkillaan toimiva toimipaikka nostaa tiketin — vikasietos, jota kukaan ei huomaa, on toistuva kustannus, ei pelastus.
• Testaa todellinen kaapeli, ei vain reitti: irrota ensisijaisen liitin ja mittaa todellinen vaihtoaika.

Tuo vikasietos yhden ohjaustason alle

Kahden WANin vikasietos yhdellä MikroTikilla on ratkaistu ongelma. Sen luotettava toteuttaminen koko laitteistossa — yhdenmukaisella konfiguraatiolla ja kyvyllä todistaa, että vara toimii reitittimellä, jota et tavoita julkisella IP:llä — on kohta, jossa useimmat operaattorit menettävät rahaa. Keskitetty, lähtevyysankkuroitu hallinta sulkee tämän aukon.

Aloita ilmainen MKController-kokeilusi