Tutorial
MikroTik dual-WAN feladatátvétel ISP
Hogyan építsen megbízható MikroTik dual-WAN feladatátvételt ISP-flottához: rekurzív útválasztás, Netwatch, WAN-onkénti NAT, átkapcsolási idő, távoli ellenőrzés.
Összefoglaló A MikroTik dual-WAN feladatátvétel online tartja a telephelyet azáltal, hogy a forgalmat automatikusan átviszi egy tartalék feltöltésre, amikor az elsődleges kapcsolat meghibásodik. A RouterOS három építőelemet ad — rekurzív útválasztás check-gateway-jel, Netwatch és WAN-onkénti NAT —, és a megfelelő kombináció attól függ, mennyire gyors és mennyire okos kell legyen az észlelése. ISP-flották esetén a nehezebb probléma nem a konfigurációs részlet, hanem több száz, CGNAT mögötti távoli telephelyen megerősíteni, hogy a feladatátvétel tényleg működött. Ez az útmutató mindkettőt lefedi.

Mi Az A MikroTik Dual-WAN Feladatátvétel?
A MikroTik dual-WAN feladatátvétel egy RouterOS-konfiguráció, amely két internet-feltöltést — egy elsődlegest és egy tartalékot — ad egy routernek, és automatikusan átviszi a forgalmat a tartalékra, amikor az elsődleges leáll a csomagok továbbításával, majd visszaviszi, amikor helyreáll. Ez nem ugyanaz, mint a terheléselosztás: a feladatátvétel egy kapcsolatot tétlenül, biztosításként tart, míg a terheléselosztás mindkettő között osztja el a forgalmat. A cél a folytonosság, nem a többletsávszélesség, és pontosan ezért ez az alapértelmezett redundanciaminta azoknál a telephelyeknél, amelyek egyszerűen nem sötétülhetnek el.
A mechanizmus az útvonalválasztáson nyugszik. A RouterOS a legalacsonyabb adminisztratív távolság alapján választja ki az aktív alapértelmezett útvonalat, így az elsődlegesnek kisebb, a tartaléknak nagyobb távolságot ad. Az egész tervezés ekkor egyetlen kérdésre szűkül: hogyan dönti el a router, hogy az elsődleges „lent van”, és minősíti le az útvonalát? Hozza meg jól ezt a döntést — elég gyorsan, de nem idegesen — és a feladatátvétel megbízható. Rontsa el, és vagy túl lassan vált át, vagy minden elvesztett csomagnál a kapcsolatok között ugrál.
1. Lépés — Térképezze fel mindkét WAN-t, mielőtt útvonalhoz nyúlna
Kezdje azzal, hogy leírja, mi is valójában az egyes feltöltések. Egy rögzített optikai vagy PPPoE elsődleges, statikus vagy PPP-vel kiosztott átjáróval, másképp viselkedik, mint egy Starlink vagy LTE tartalék, amely Carrier-Grade NAT mögött ül, és dinamikus címet ad. Ez azért számít, mert a rekurzív útválasztás csak stabil IP-átjárókkal működik, nem dinamikus interfésztípusokkal, mint a PPPoE vagy DHCP, ahol a cím megváltozhat (MikroTik dokumentáció — Failover (WAN Backup)). Döntse el, melyik kapcsolat elsődleges, melyik tartalék, és vajon valamelyik újracsatlakozáskor lecseréli-e az IP-jét — ez az egyetlen tény dönti el, melyik észlelési módszert használhatja.
2. Lépés — Adjon hozzá rekurzív alapértelmezett útvonalakat check-gateway-jel
A klasszikus megközelítés rekurzív útválasztást használ: ahelyett, hogy az alapértelmezett útvonalat közvetlenül a következő ugrásra irányítaná, egy próbacélra (például egy jól ismert nyilvános feloldóra) irányítja, és hozzáad egy statikus útvonalat, amely arra utasítja a RouterOS-t, hogy ezt a célt csak egy adott WAN-átjárón át érje el. Ezután két alapértelmezett útvonalat hoz létre, amelyeket rekurzívan oldanak fel ezeken a célokon át — az elsődlegest kisebb távolsággal és engedélyezett check-gateway=ping-gel, a tartalékot nagyobb távolsággal (Scoop — Basic ISP Failover with MikroTik).
A viselkedés, amely köré tervezni kell, az időzítés. A check-gateway két egymást követő sikertelen ellenőrzés után deaktiválja az útvonalat, és az ellenőrzések nagyjából 10 másodpercenként futnak, így a valós átkapcsolás körülbelül 20–30 másodpercnél landol — és nem reagál az időszakos csomagvesztésre, csak egy teljesen halott átjáróra (MikroTik dokumentáció — Failover (WAN Backup)). Sok ISP-ügyféltelephely esetén ez elfogadható. Hang- vagy fizetési terminálok esetén gyakran nem, és itt jön be a 4. lépés.
3. Lépés — Állítsa be a NAT-ot mindkét feltöltéshez
Egy dual-WAN routernek WAN-interfészenként külön masquerade (vagy src-nat) szabályra van szüksége, hogy az éppen aktív kapcsolat helyesen fordítsa le a kimenő forgalmat; egyetlen, egy interfészhez kötött szabály csendben megszakítja a kapcsolatot abban a pillanatban, amikor a feladatátvétel a másik kapcsolatra viszi a forgalmat. Adjon hozzá egy masquerade szabályt a srcnat láncba az elsődleges out-interface-hez és egy másodikat a tartalékhoz. Ha bejövő szolgáltatásokat tesz közzé, ne feledje, hogy az elsődleges címéhez kötött dst-nat szabályok leállnak, amikor az a kapcsolat — és annak nyilvános IP-je — eltűnik. Ez a bejövő törékenység ugyanaz az architekturális csapda, amelyet a Starlink IP-változások esetünkben tárgyaltunk, és ezért skálázódik jobban a kimenethez horgonyzott hozzáférés, mint a portátirányítás. A NAT alapjaihoz lásd útmutatónkat a NAT konfigurálásához MikroTikon.
4. Lépés — Használjon Netwatch-ot, ha gyorsabb vagy okosabb észlelésre van szüksége
Amikor 20–30 másodperc túl lassú, vagy degradált-de-élő kapcsolatokra kell reagálnia, a Netwatch a rugalmasabb eszköz. A RouterOS v7-ben a Netwatch egy type paramétert kapott, amely icmp, tcp-conn, http-get, https-get vagy simple módon képes próbálni, és saját ellenőrzési intervallumot állíthat be ahelyett, hogy a check-gateway rögzített ütemével élne (MikroTik dokumentáció — Failover (WAN Backup)). Minden hosztnak van up és down szkriptje, így átmenetkor letilthatja az elsődleges alapértelmezett útvonalat, riasztást indíthat vagy naplózhatja az eseményt.
Sok üzemeltető kombinálja a kettőt: a rekurzív útválasztás kezeli a tiszta kapcsolat-halált, míg a Netwatch lefedi a rendezetlenebb eseteket és értesítéseket küld. Egy hosszú ideje futó közösségi szál pontosan ezt a kompromisszumot vitatja, és érdemes elolvasni, mielőtt egy módszert flotta szerte szabványosít (MikroTik fórum — netwatch instead of recursive routing). Bármelyiket választja, tartsa a konfigurációt minden telephelyen azonosnak — egyedi feladatátvételi szkriptek flottája maga is egy kimaradás, amely csak arra vár, hogy bekövetkezzen.
5. Lépés — Ellenőrizze a feladatátvételt minden távoli telephelyen
Itt van az a rész, amelyet a konfigurációs útmutatók kihagynak. Az útvonalak hozzáadása egyetlen labor-routerhez könnyű; bebizonyítani, hogy a feladatátvétel több száz telepített CPE-n működik, az igazi ISP-probléma — és nehezebbé válik, amikor a tartalék kapcsolat Starlink vagy LTE CGNAT mögött, mert az eszköznek átkapcsolás után gyakran nincs elérhető nyilvános IP-je a menedzseléshez. Ha a feladatátvételt csak úgy tudja megerősíteni, hogy megvárja, amíg egy ügyfél telefonál, akkor valójában nincs feladatátvétele; van egy szkriptje, amelyről reméli, hogy fut.
Itt a központosított menedzsment megváltoztatja a gazdaságot. Az MKController minden routert elérhetően tart egy hitelesített kimenő alagúton át, így megerősítheti, hogy a tartalék útvonal visz forgalmat, megfigyelheti a feladatátvételi átmenetet a monitorozásban, és javított konfigurációt küldhet — anélkül, hogy egy nyilvános IP-től függne, amely a tartalék kapcsolaton talán nem is létezik. Párosítsa ezt telemetriával: a MikroTik távoli monitorozásáról Zabbix-szal és a MikroTik SNMP-monitorozásáról szóló útmutatóink megmutatják, hogyan riaszthat magára a feladatátvételi eseményre, hogy egy csendes váltás a drága tartalék kapcsolatra soha ne maradjon észrevétlen.
Tippek
- Tartsa a tartalék kapcsolat
check-gatewaypróbáját egy olyan célra irányítva, amelyet azon a kapcsolaton át ér el, nem az elsődlegesen át, különben a tesztje értelmetlen. - Címkézze a feladatátvételi átmeneteket a monitorozásában, hogy egy napokig a tartalék feltöltésén futó telephely jegyet nyisson — egy feladatátvétel, amelyet senki sem vesz észre, visszatérő költség, nem megmentés.
- Tesztelje a valódi kábelt, ne csak az útvonalat: húzza ki az elsődleges csatlakozóját, és mérje meg a valós átkapcsolási időt.
Hozza a feladatátvételt egyetlen vezérlősík alá
A dual-WAN feladatátvétel egyetlen MikroTikon megoldott probléma. Megbízhatóan megvalósítani flotta szerte — következetes konfigurációval és azzal a képességgel, hogy bebizonyítsa, a tartalék működik egy olyan routeren, amelyet nyilvános IP-n nem ér el — ott van, ahol a legtöbb üzemeltető pénzt veszít. A központosított, kimenethez horgonyzott menedzsment bezárja ezt a rést.