Multivan a směrování na Mikrotik RouterOS

Úvod

Napsat článek mě k tomu vedla nejen pýcha, ale i znepokojující frekvence otázek na toto téma v zaměřených skupinách ruského komunitního Telegramu. Článek je určen pro začínající správce Mikrotik RouterOS (dále jen ROS). Zaměříme se pouze na multitasking, s důrazem na routování. Jako bonus přináší minimálně nutná nastavení pro zajištění bezpečné a pohodlné práce. Ti, kteří hledají rozpracování témat front, vyvažování zatížení, VLAN, mosty, vícestupňovou analýzu stavu kanálu a podobně - mohou šetřit čas a síly na čtení.

Vstupní data

Jako zkušební zařízení byl vybrán pětportový router Mikrotik s ROS verze 6.45.3. Bude routovat provoz mezi dvěma lokálními sítěmi (LAN1 a LAN2) a třemi poskytovateli (ISP1, ISP2, ISP3). Kanál k ISP1 má statickou 'šedou' adresu, ISP2 - 'bílou', získanou pomocí DHCP, ISP3 - 'bílou' s PPPoE autorizací. Schéma připojení je zobrazeno na obrázku:

Multivan a směrování na Mikrotik RouterOS

Úkolem je nastavit router 'MTK' na základě schématu tak, aby:

  1. Zajistit automatické přepínání na záložního poskytovatele. Hlavní poskytovatel - ISP2, první záloha - ISP1, druhá záloha - ISP3.
  2. Organizovat přístup sítě LAN1 na Internet pouze přes ISP1.
  3. Předpokládat možnost routování provozu z lokálních sítí na Internet přes vybraného poskytovatele na základě address-list.
  4. Předpokládat možnost publikace služeb z lokální sítě na Internet (DSTNAT).
  5. Nastavit filtr firewallu pro zajištění minimální potřebné bezpečnosti ze strany Internetu.
  6. Router mohl odesílat vlastní provoz prostřednictvím jakéhokoli z těchto tří poskytovatelů v závislosti na vybrané adrese zdroje.
  7. Zajistit routování odpovědních paketů do kanálu, ze kterého přišly (včetně LAN).

Poznámka. Nastavovat router budeme 'od nuly', abychom zajistili absenci překvapení ve měnících se od verze k verzi výchozích konfiguracích 'z krabice'. Jako nástroj pro nastavení byl vybrán Winbox, kde budou názorně zobrazeny změny. Samotná nastavení budou zadávána příkazy v terminálu Winbox. Fyzické připojení pro nastavení se provede přímým spojení s rozhraním Ether5.

Něco úvah o tom, co je to multivan, zda je to problém, nebo chytří lidé kolem pletou sítě konspirací

Zvídavý a pozorný administrátor, nastavující takovou nebo podobnou schéma, náhle zjistí, že to vlastně funguje. Ano, bez těch vašich uživatelských tabulek směrování a dalších pravidel routování, jimiž se hemží většina článků na toto téma. Ověřme to?

Můžeme nakonfigurovat adresaci na rozhraních a výchozí brány? Ano:

Na ISP1 jsme napsali adresu a bránu s distance=2 a check-gateway=ping.
Na ISP2 je výchozí nastavení DHCP klienta, takže distance bude rovno jedné.
Na ISP3 v nastavení PPPoE klienta při add-default-route=yes nastavit default-route-distance=3.

Nezapomínejme napsat NAT pro odchozí spojení:

/ip firewall nat add action=masquerade chain=srcnat out-interface-list=WAN

Na závěr, uživatelé lokálních sítí se radostně připojují přes hlavního poskytovatele ISP2 a dochází k rezervaci kanálu pomocí mechanismu check gateway Viz poznámka 1

Položka 1 úkolu byla splněna. Kde je ten multivan se svými značkami? Ne...

Dále. Je potřeba uvolnit konkrétní klienty z LAN přes ISP1:

/ip firewall mangle add action=route chain=prerouting dst-address-list=!BOGONS
passthrough=yes route-dst=100.66.66.1 src-address-list=Via_ISP1
/ip firewall mangle add action=route chain=prerouting dst-address-list=!BOGONS
passthrough=no route-dst=100.66.66.1 src-address=192.168.88.0/24

Položky 2 a 3 úkolu byly splněny. Kde jsou značky, značkování, pravidla směrování?!

Je potřeba poskytnout přístup k oblíbenému serveru OpenVPN s adresou 172.17.17.17 pro klienty z internetu? Prosím:

/ip cloud set ddns-enabled=yes

Klientům jako peer poskytujeme výstup: ":put [ip cloud get dns-name]”

Nastavujeme přesměrování portu z internetu:

/ip firewall nat add action=dst-nat chain=dstnat dst-port=1194
in-interface-list=WAN protocol=udp to-addresses=172.17.17.17

Položka 4 je hotová.

Nastavujeme firewall a další zabezpečení pro položku 5, zatímco se radujeme, že uživatelé již vše funguje a saháme po nádobě s oblíbeným nápojem…
A! Tunnely jsme ještě zapomněli.

l2tp klient, nastavený podle vygoogleného článku, se připojil k oblíbenému nizozemskému VDS? Ano.
l2tp server s IPsec se připojil a klienti přes DNS jméno z IP Cloud (viz výše) se napojili? Ano.
Opřený o opěradlo židle, usrkávající nápoj, líně prohlížíme položky 6 a 7 úkolu. Přemýšlíme — potřebujeme to? Všechno přece funguje (s)… Tak pokud to vážně nepotřebujeme, tady to končí. Multivan je realizován.

Co je to multivan? To je připojení několika internetových kanálů k jednomu routeru.

Dále článku už nemusíte číst, protože co tam kromě chlubení pochybné použitelnosti může být?

S těmi, kdo zůstali, kdo se zajímají o body 6 a 7 úkolu a také cítí touhu po dokonalosti, se ponoříme hlouběji.

Nejdůležitějším úkolem realizace multivanu je správné směrování provozu. A to konkrétně: bez ohledu na to, na který (nebo které) viz. poznámka 3 kanál(y) poskytovatele se dívá výchozí trasa na našem routeru, musí vracet odpověď právě na ten kanál, ze kterého paket přišel. Úkol je jasný. Kde je problém? Vždyť ve jednoduché lokální síti je úkol stejný, ale nikdo se s dodatečným nastavením nezabývá a žádné potíže nepocítí. Rozdíl spočívá v tom, že každý směrovatelný uzel na internetu je dostupný přes každý z našich kanálů, a ne přes striktně konkrétní, jako v jednoduché lokální síti. A "potíž" spočívá v tom, že pokud k nám přišel požadavek na IP adresu ISP3, pak v našem případě odpověď odejde přes kanál ISP2, protože tam je směrován výchozí brána. Odpověď odejde a bude poskytovatelem odmítnuta jako nesprávná. Problém jsme identifikovali. Jak ho vyřešit?

Řešení rozdělíme do tří etap:

  1. Předběžné nastavení. V této fázi budou nastavena základní nastavení routeru: lokální síť, firewall, adresní seznamy, hairpin NAT atd.
  2. Multivan. V této fázi budou označena a seřazena potřebná spojení podle směrovacích tabulek.
  3. Připojení k ISP. V této fázi budou nakonfigurovány rozhraní, která zajišťují připojení k internetu, aktivováno směrování a mechanismus zálohování internetových kanálů.

1. Předběžné nastavení

1.1. Vymažeme konfiguraci routeru příkazem:

/system reset-configuration skip-backup=yes no-defaults=yes

souhlasíme s "Dangerous! Reset anyway? [y/N]:" a po restartu se připojíme pomocí Winboxu přes MAC. V této fázi byla konfigurace a databáze uživatelů vymazána.

1.2. Vytvoříme nového uživatele:

/user add group=full name=knight password=ultrasecret comment=”Not horse”

přihlásíme se pod ním a odstraníme výchozího uživatele:

/user remove admin

Poznámka. Autor považuje odstranění, ne pouze deaktivaci výchozího uživatele za bezpečnější a doporučuje jej použít.

1.3. Vytvoříme základní seznamy rozhraní pro usnadnění manipulace ve firewallu, nastaveních objevování a ostatních MAC serverech:

/interface list add name=WAN comment="For Internet"
/interface list add name=LAN comment="For Local Area"

Podepisujeme komentáři rozhraní

/interface ethernet set ether1 comment="to ISP1"
/interface ethernet set ether2 comment="to ISP2"
/interface ethernet set ether3 comment="to ISP3"
/interface ethernet set ether4 comment="to LAN1"
/interface ethernet set ether5 comment="to LAN2"

a vyplňujeme seznamy rozhraní:

/interface list member add interface=ether1 list=WAN comment=ISP1
/interface list member add interface=ether2 list=WAN comment=ISP2 
/interface list member add interface=ether3 list=WAN comment="to ISP3"
/interface list member add interface=ether4 list=LAN  comment="LAN1"
/interface list member add interface=ether5 list=LAN  comment="LAN2"

Poznámka. Stojí za to psát srozumitelné komentáře, což výrazně usnadňuje troubleshooting a pochopení konfigurace.

Autor považuje za nezbytné z bezpečnostních důvodů přidat do seznamu rozhraní „WAN“ rozhraní ether3, i když přes něj nebude probíhat protokol ip.

Nezapomínejme, že jakmile bude na ether3 spuštěno rozhraní PPP, bude ho také nutné přidat do seznamu rozhraní „WAN“.

1.4. Skrýváme router před odhalením sousedství a správy ze sítí poskytovatelů pomocí MAC:

/ip neighbor discovery-settings set discover-interface-list=!WAN
/tool mac-server set allowed-interface-list=LAN
/tool mac-server mac-winbox set allowed-interface-list=LAN

1.5. Vytváříme minimální sadu pravidel filtru firewallu pro ochranu routeru:

/ip firewall filter add action=accept chain=input comment="Related Established Untracked Allow" 
connection-state=established,related,untracked

(pravidlo umožňuje připojené a příbuzné spojení, která byla iniciována jak z připojených sítí, tak samotným routerem)

/ip firewall filter add action=accept chain=input comment="ICMP from ALL" protocol=icmp

(ping a nejen ping. Všechny icmp jsou povoleny na vstupu. Velmi užitečné pro zjišťování problémů s MTU)

/ip firewall filter add action=drop chain=input comment="All other WAN Drop" in-interface-list=WAN

(uzavírající řetězec pravidlo zakazuje vše ostatní, co přichází z Internetu)

/ip firewall filter add action=accept chain=forward 
comment="Established, Related, Untracked allow" 
connection-state=established,related,untracked

(pravidlo povoluje připojené a příbuzné spojení, která procházejí routerem)

/ip firewall filter add action=drop chain=forward comment="Invalid drop" connection-state=invalid

(pravidlo resetuje spojení s connection-state=invalid, procházející routerem. Je důrazně doporučeno Mikrotik, ale v některých vzácných situacích může způsobit blokaci užitečného provozu)

/ip firewall filter add action=drop chain=forward comment="Drop all from WAN not DSTNATed"  
connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

(pravidlo zakazuje procházení routerem paketu, které přicházejí z Internetu a neprošly postupem dstnat. To ochrání místní sítě před útočníky, kteří se nacházejí ve stejné vysílací doméně s našimi externími sítěmi a zaregistrují naše externí IP jako bránu, a tím se pokusí „zkoumat“ naše místní sítě.)

Poznámka. Předpokládáme, že sítě LAN1 a LAN2 jsou důvěryhodné a provoz mezi nimi a z nich není filtrován.

1.6. Vytváříme seznam s přehledem nemaršrutizovatelných sítí:

/ip firewall address-list
add address=0.0.0.0/8 comment=""This" Network" list=BOGONS
add address=10.0.0.0/8 comment="Private-Use Networks" list=BOGONS
add address=100.64.0.0/10 comment="Shared Address Space. RFC 6598" list=BOGONS
add address=127.0.0.0/8 comment=Loopback list=BOGONS
add address=169.254.0.0/16 comment="Link Local" list=BOGONS
add address=172.16.0.0/12 comment="Private-Use Networks" list=BOGONS
add address=192.0.0.0/24 comment="IETF Protocol Assignments" list=BOGONS
add address=192.0.2.0/24 comment=TEST-NET-1 list=BOGONS
add address=192.168.0.0/16 comment="Private-Use Networks" list=BOGONS
add address=198.18.0.0/15 comment="Network Interconnect Device Benchmark Testing"
 list=BOGONS
add address=198.51.100.0/24 comment=TEST-NET-2 list=BOGONS
add address=203.0.113.0/24 comment=TEST-NET-3 list=BOGONS
add address=224.0.0.0/4 comment=Multicast list=BOGONS
add address=192.88.99.0/24 comment="6to4 Relay Anycast" list=BOGONS
add address=240.0.0.0/4 comment="Reserved for Future Use" list=BOGONS
add address=255.255.255.255 comment="Limited Broadcast" list=BOGONS

(To je seznam adres a sítí, které nejsou maršrutizovány do Internetu a my se jím také budeme řídit.)

Poznámka. Seznam se může měnit, proto doporučuji pravidelně kontrolovat aktuálnost.

1.7. Konfigurujeme DNS pro samotný router:

/ip dns set servers=1.1.1.1,8.8.8.8

Poznámka. V aktuální verzi ROS dynamické servery mají prioritu před staticky nastavenými. Žádost o překladu názvu se posílá prvnímu serveru v pořadí v seznamu. Na další server se přechází v případě, že je aktuální nedostupný. Časový limit je velký - více než 5 sekund. Návrat zpět, při obnovení funkce "zhrouceného serveru", automaticky nenastává. S ohledem na tento algoritmus a existenci multipath, autor doporučuje nepoužívat servery poskytované poskytovateli.

1.8. Nastavení lokální sítě.
1.8.1. Konfigurace statických IP adres na rozhraních lokálních sítí:

/ip address add interface=ether4 address=192.168.88.254/24 comment="LAN1 IP"
/ip address add interface=ether5 address=172.16.1.0/23 comment="LAN2 IP"

1.8.2. Stanovení pravidel pro směrování k našim lokálním sítím přes hlavní směrovací tabulku:

/ip route rule add dst-address=192.168.88.0/24 table=main comment=”to LAN1”
/ip route rule add dst-address=172.16.0.0/23 table=main comment="to LAN2"

Poznámka. To je jeden z jednoduchých a rychlých způsobů, jak získat přístup k adresám lokálních sítí z externí IP adresy rozhraní routeru, přes které neprochází výchozí směrování.

1.8.3. Aktivace Hairpin NAT pro LAN1 a LAN2:

/ip firewall nat add action=src-nat chain=srcnat comment="Hairpin to LAN1" 
out-interface=ether4 src-address=192.168.88.0/24 to-addresses=192.168.88.254
/ip firewall nat add action=src-nat chain=srcnat comment="Hairpin to LAN2" 
out-interface=ether5 src-address=172.16.0.0/23 to-addresses=172.16.1.0

Poznámka. To umožňuje přístup přes externí IP k našim zdrojům (dstnat), když se nacházíme uvnitř sítě.

2. Takže, implementace toho správného multipath.

Pro řešení úkolu "odpovídat tam, odkud se ptali" budeme používat dva nástroje ROS: connection mark a routing mark. Connection mark umožňuje označit potřebné spojení a následně pracovat s touto značkou jako podmínkou pro použití routing mark. A už s routing mark je možné pracovat v ip route a route rules. S nástroji jsme se seznámili, nyní musíme rozhodnout, která spojení označit — za prvé, a kde přesně značit — za druhé.

S prvním je to jednoduché — musíme označit všechna spojení, která přicházejí na router z Internetu přes odpovídající kanál. V našem případě budou tři značky (podle počtu kanálů): "conn_isp1", "conn_isp2" a "conn_isp3".

Nuance se druhým otázkou spočívá v tom, že přicházející spojení budou dvou typů: tranzitní a ta, která jsou určena samotnému routeru. Mechanismus connection mark funguje v tabulce mangle. Podívejme se na pohyb paketu na zjednodušené diagramu, laskavě sestaveném specialisty z mikrotik-trainings.com (není reklama):

Multivan a směrování na Mikrotik RouterOS

Podle šipek vidíme, že paket přicházející do "input interface" prochází řetězcem "Prerouting" a teprve poté se rozděluje na tranzitní a lokální v bloku "Routing Decision". Proto, abychom zabili dvě mouchy jednou ranou, využijeme Connection Mark v tabulce Mangle Prerouting řetězce Prerouting.

Poznámka. V ROS jsou značky "Routing mark" uvedeny v části Ip/Routes/Rules jako "Table", a v ostatních sekcích jako "Routing Mark". To může způsobit určité zmatení v pochopení, ale v podstatě se jedná o to samé a je to ekvivalent rt_tables v iproute2 na linuxu.

2.1. Označujeme příchozí spojení od každého z providerů:

/ip firewall mangle add action=mark-connection chain=prerouting 
comment="Connmark in from ISP1" connection-mark=no-mark in-interface=ether1  new-connection-mark=conn_isp1 passthrough=no

/ip firewall mangle add action=mark-connection chain=prerouting 
comment="Connmark in from ISP2" connection-mark=no-mark in-interface=ether2  new-connection-mark=conn_isp2 passthrough=no

/ip firewall mangle add action=mark-connection chain=prerouting 
comment="Connmark in from ISP3" connection-mark=no-mark in-interface=pppoe-isp3  new-connection-mark=conn_isp3 passthrough=no

Poznámka. Abychom neoznačovali již označená spojení, používám podmínku connection-mark=no-mark místo connection-state=new, protože to považuji za správnější, stejně jako odmítání drop invalid spojení ve filtru input.


passthrough=no — protože v tomto realizaci je změna značení vyloučena a pro urychlení můžeme přerušit procházení pravidel po prvním shodě.

Je třeba mít na paměti, že se prozatím nijak nezapojíme do routování. Nyní probíhají pouze přípravné etapy. Dalším krokem realizace bude zpracování tranzitního provozu, který se vrací po ustaveném spojení od adresáta v místní síti. Tedy těch paketů, které (viz diagram) prošly routerem po cestě:

"Input Interface"=>"Prerouting"=>"Routing Decision"=>"Forward"=>"Post Routing"=>"Output Interface" a dostaly se ke svému adresátovi v místní síti.

Důležité! V ROS neexistuje logické dělení na externí a interní rozhraní. Pokud sledujeme cestu odpovědního paketu podle uvedeného diagramu, projde stejnou logickou cestou, jako požadavek:

"Input Interface"=>"Prerouting"=>"Routing Decision"=>"Forward"=>"Post Routing"=>"Output Interface" jednoduše pro požadavek "Input Interface" bylo rozhraní ISP, a pro odpověď — LAN

2.2. Směřujeme odpovědní tranzitní provoz podle příslušných routovacích tabulek:

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Routemark transit out via ISP1" connection-mark=conn_isp1 
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp1 passthrough=no

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Routemark transit out via ISP2" connection-mark=conn_isp2 
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp2 passthrough=no

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Routemark transit out via ISP3" connection-mark=conn_isp3 
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp3 passthrough=no

Poznámka. in-interface-list=!WAN — pracujeme pouze s provozem z místní sítě a dst-address-type=!local nemajícím cílovou adresu adres rozhraní samotného routeru.

Totéž platí pro místní pakety, které přišly na router po cestě:

"Input Interface"=>"Prerouting"=>"Routing Decision"=>"Input"=>"Local Process"

Důležité! Odpověď půjde následující cestou:

"Local Process"=>"Routing Decision"=>"Output"=>"Post Routing"=>"Output Interface"

2.3. Směřujeme odpovědní lokální provoz podle příslušných routovacích tabulek:

/ip firewall mangle add action=mark-routing chain=output 
comment="Routemark local out via ISP1" connection-mark=conn_isp1 dst-address-type=!local 
new-routing-mark=to_isp1 passthrough=no

/ip firewall mangle add action=mark-routing chain=output 
comment="Routemark local out via ISP2" connection-mark=conn_isp2 dst-address-type=!local 
new-routing-mark=to_isp2 passthrough=no

/ip firewall mangle add action=mark-routing chain=output 
comment="Routemark local out via ISP3" connection-mark=conn_isp3 dst-address-type=!local 
new-routing-mark=to_isp3 passthrough=no

V této fázi můžeme považovat úkol přípravy k odeslání odpovědi do toho kanálu Internetu, ze kterého přišel požadavek, za vyřešený. Všechno je označeno, promarkováno a připraveno k routování.
Skvělým „vedlejším“ efektem této konfigurace je možnost práce s port forwardingem DSNAT od obou (ISP2, ISP3) poskytovatelů současně. Ne na všech, protože u ISP1 máme nemapovatelnou adresu. Tento efekt je důležitý například pro poštovní server se dvěma MX záznamy, které směřují do různých internetových kanálů.

K odstranění nuancí fungování místních sítí s externími IP routeru využíváme řešení z bodů 1.8.2 a 3.1.2.6.

Dále lze použít nástroj s označením i pro řešení bodu 3 úkolu. Realizujeme to následujícím způsobem:

2.4. Směřujeme provoz od místních klientů z routovacích seznamů do odpovídajících tabulek:

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Address List via ISP1" dst-address-list=!BOGONS new-routing-mark=to_isp1 
passthrough=no src-address-list=Via_ISP1

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Address List via ISP2" dst-address-list=!BOGONS new-routing-mark=to_isp2 
passthrough=no src-address-list=Via_ISP2

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Address List via ISP3" dst-address-list=!BOGONS new-routing-mark=to_isp3 
passthrough=no src-address-list=Via_ISP3

V důsledku to vypadá přibližně takto:

Multivan a směrování na Mikrotik RouterOS

3. Nastavujeme připojení k ISP a využíváme routování podle značek

3.1. Nastavujeme připojení k ISP1:
3.1.1. Konfigurujeme statickou IP adresu:

/ip address add interface=ether1 address=100.66.66.2/30 comment="ISP1 IP"

3.1.2. Nastavujeme statické routování:
3.1.2.1. Přidáváme „záložní“ výchozí routu:

/ip route add comment="Emergency route" distance=254 type=blackhole

Poznámka. Tato routa umožňuje, aby provoz od místních procesů prošel fází rozhodování o routování nezávisle na stavu kanálů jakéhokoli poskytovatele. Nuance odchozího místního provozu spočívá v tom, že aby paket kamkoli odešel, musí v hlavní routovací tabulce existovat aktivní routa k výchozímu bráně. Pokud neexistuje, paket bude jednoduše zničen.

Jako rozšíření nástroje check gateway pro hlubší analýzu stavu kanálu navrhuji použít metodu rekurzivních rout. Podstata metody spočívá v tom, že určujeme routeru, aby hledal cestu ke svému bráně nikoli přímo, ale přes mezilehlou bránu. Jako takové „testovací“ brány budou vybrány 4.2.2.1, 4.2.2.2 a 4.2.2.3 pro ISP1, ISP2 a ISP3.

3.1.2.2. Routa k „testovací“ adrese:

/ip route add check-gateway=ping comment="For recursion via ISP1"  
distance=1 dst-address=4.2.2.1 gateway=100.66.66.1 scope=10

Poznámka. Hodnotu scope snižujeme na výchozí v ROS target scope, abychom mohli dál používat 4.2.2.1 jako rekurzivní bránu. Podtrhuji: scope routy k „testovací“ adrese by měl být menší nebo roven target scope té routy, která bude odkazovat na testovací.

3.1.2.3. Rekurzivní routa pro provoz bez routing mark:

/ip route add comment="Unmarked via ISP1" distance=2 gateway=4.2.2.1

Poznámka. Hodnota distance=2 se používá, protože ISP1 je podle podmínek úkolu uveden jako první záložní.

3.1.2.4. Rekurzivní routa pro provoz s routing mark „to_isp1“:

/ip route add comment="Marked via ISP1 Main" distance=1 gateway=4.2.2.1 
routing-mark=to_isp1

Poznámka. Tady konečně začínáme správně využívat plody přípravné práce, která byla provedena v bodě 2.


Po této trase bude veškerý provoz označený jako route "to_isp1" směrován na bránu prvního poskytovatele bez ohledu na to, která brána je aktuálně aktivní pro tabulku main.

3.1.2.5. První záložní rekurzivní trasa pro označený provoz poskytovatelů ISP2 a ISP3:

/ip route add comment="Marked via ISP2 Backup1" distance=2 gateway=4.2.2.1 
routing-mark=to_isp2
/ip route add comment="Marked via ISP3 Backup1" distance=2 gateway=4.2.2.1 
routing-mark=to_isp3

Poznámka. Tyto trasy jsou nezbytné také pro zálohování provozu z lokálních sítí, které se skládají z členů address list "to_isp*".

3.1.2.6. Nastavujeme trasu pro místní provoz routeru na Internet přes ISP1:

/ip route rule add comment="From ISP1 IP to Inet" src-address=100.66.66.2 table=to_isp1

Poznámka. V kombinaci s pravidly z bodu 1.8.2 se zajišťuje výstup do požadovaného kanálu s daným zdrojem. To je kritické pro vytváření tunelů, kde se nastavuje IP adresa místní strany (EoIP, IP-IP, GRE). Protože pravidla v ip route rules se provádějí shora dolů, až do prvního splnění podmínek, musí být toto pravidlo za pravidly z bodu 1.8.2.

3.1.3. Nastavujeme pravidlo NAT pro odchozí provoz:

/ip firewall nat add action=src-nat chain=srcnat comment="NAT via ISP1"  
ipsec-policy=out,none out-interface=ether1 to-addresses=100.66.66.2

Poznámka. NATuje veškerý odchozí provoz kromě toho, co spadá do politik IPsec. Snažím se nepoužívat action=masquerade bez krajní nutnosti. Funguje pomaleji a je náročnější na zdroje než src-nat, protože pro každé nové spojení vypočítává adresu pro NAT.

3.1.4. Směřujeme klienty ze seznamu, kterým je zakázán výstup přes ostatní poskytovatele, rovnou na bránu poskytovatele ISP1.

/ip firewall mangle add action=route chain=prerouting comment="Address List via ISP1 only" 
dst-address-list=!BOGONS passthrough=no route-dst=100.66.66.1 
src-address-list=Via_only_ISP1 place-before=0

Poznámka. action=route má vyšší prioritu a aplikuje se dříve než ostatní směrovací pravidla.


place-before=0 — umístí naše pravidlo jako první v seznamu.

3.2. Konfigurujeme připojení k ISP2.

Jelikož poskytovatel ISP2 nám poskytuje nastavení přes DHCP, je rozumné provádět potřebné změny pomocí skriptu, který se spustí při aktivaci DHCP klienta:

/ip dhcp-client
add add-default-route=no disabled=no interface=ether2 script=":if ($bound=1) do={r
    n    /ip route add check-gateway=ping comment="For recursion via ISP2" distance=1 
           dst-address=4.2.2.2/32 gateway=$"gateway-address" scope=10r
    n    /ip route add comment="Unmarked via ISP2" distance=1 gateway=4.2.2.2;r
    n    /ip route add comment="Marked via ISP2 Main" distance=1 gateway=4.2.2.2 
           routing-mark=to_isp2;r
    n    /ip route add comment="Marked via ISP1 Backup1" distance=2 gateway=4.2.2.2 
           routing-mark=to_isp1;r
    n    /ip route add comment="Marked via ISP3 Backup2" distance=3 gateway=4.2.2.2 
           routing-mark=to_isp3;r
    n    /ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none 
           out-interface=$"interface" to-addresses=$"lease-address" comment="NAT via ISP2" 
           place-before=1;r
    n    if ([/ip route rule find comment="From ISP2 IP to Inet"] ="") do={r
    n        /ip route rule add comment="From ISP2 IP to Inet" 
               src-address=$"lease-address" table=to_isp2 r
    n    } else={r
    n       /ip route rule set [find comment="From ISP2 IP to Inet"] disabled=no 
              src-address=$"lease-address"r
    n    }      r
    n} else={r
    n   /ip firewall nat remove  [find comment="NAT via ISP2"];r
    n   /ip route remove [find comment="For recursion via ISP2"];r
    n   /ip route remove [find comment="Unmarked via ISP2"];r
    n   /ip route remove [find comment="Marked via ISP2 Main"];r
    n   /ip route remove [find comment="Marked via ISP1 Backup1"];r
    n   /ip route remove [find comment="Marked via ISP3 Backup2"];r
    n   /ip route rule set [find comment="From ISP2 IP to Inet"] disabled=yesr
    n}r
    n" use-peer-dns=no use-peer-ntp=no

Samotný skript ve Winboxu:

Multivan a směrování na Mikrotik RouterOS
Poznámka. První část skriptu se aktivuje při úspěšném získání pronájmu, druhá — po uvolnění pronájmu.Viz poznámka 2

3.3. Konfigurujeme připojení k poskytovateli ISP3.

Jelikož poskytovatel nám poskytuje dynamická nastavení, je rozumné provádět nezbytné změny pomocí skriptů, které se spustí po aktivaci a po pádu rozhraní ppp.

3.3.1. Nejprve konfigurujeme profil:

/ppp profile
add comment="for PPPoE to ISP3" interface-list=WAN name=isp3_client 
on-down="/ip firewall nat remove  [find comment="NAT via ISP3"];r
    n/ip route remove [find comment="For recursion via ISP3"];r
    n/ip route remove [find comment="Unmarked via ISP3"];r
    n/ip route remove [find comment="Marked via ISP3 Main"];r
    n/ip route remove [find comment="Marked via ISP1 Backup2"];r
    n/ip route remove [find comment="Marked via ISP2 Backup2"];r
    n/ip route rule set [find comment="From ISP3 IP to Inet"] disabled=yes;" 
on-up="/ip route add check-gateway=ping comment="For recursion via ISP3" distance=1 
    dst-address=4.2.2.3/32 gateway=$"remote-address" scope=10r
    n/ip route add comment="Unmarked via ISP3" distance=3 gateway=4.2.2.3;r
    n/ip route add comment="Marked via ISP3 Main" distance=1 gateway=4.2.2.3 
    routing-mark=to_isp3;r
    n/ip route add comment="Marked via ISP1 Backup2" distance=3 gateway=4.2.2.3 
    routing-mark=to_isp1;r
    n/ip route add comment="Marked via ISP2 Backup2" distance=3 gateway=4.2.2.3 
    routing-mark=to_isp2;r
    n/ip firewall mangle set [find comment="Connmark in from ISP3"] 
    in-interface=$"interface";r
    n/ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none 
    out-interface=$"interface" to-addresses=$"local-address" comment="NAT via ISP3" 
    place-before=1;r
    nif ([/ip route rule find comment="From ISP3 IP to Inet"] ="") do={r
    n   /ip route rule add comment="From ISP3 IP to Inet" src-address=$"local-address" 
    table=to_isp3 r
    n} else={r
    n   /ip route rule set [find comment="From ISP3 IP to Inet"] disabled=no 
    src-address=$"local-address"r
    n};r
    n"

Samotný skript ve Winboxu:

Multivan a směrování na Mikrotik RouterOS
Poznámka. Řádek
/ip firewall mangle set [find comment=«Connmark in from ISP3»] in-interface=$«interface»;
umožňuje správně zpracovávat přejmenování rozhraní, protože pracuje s jeho kódem, a ne s zobrazeným názvem.

3.3.2. Nyní, s využitím profilu, vytváříme PPP připojení:

/interface pppoe-client add allow=mschap2 comment="to ISP3" disabled=no 
interface=ether3 name=pppoe-isp3 password=isp3_pass profile=isp3_client user=isp3_client

Na závěr nastavíme čas:

/system ntp client set enabled=yes server-dns-names=0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org

Pro ty, kteří dočetli až do konce

Navrhovaný způsob implementace multiwan je osobní preference autora a není jedině možný. Nástroje ROS jsou rozsáhlé a flexibilní, což na jedné straně způsobuje potíže pro začátečníky, na druhé straně je to důvod jejich popularity. Studujte, zkuste, objevujte nové nástroje a řešení. Například v této implementaci multiwan lze nahradit nástroj Check-gateway s rekurzivními trasami na Netwatch.

Poznámky

  1. Check-gateway — mechanismus, který umožňuje deaktivaci trasy po dvou po sobě jdoucích neúspěšných kontrolách dostupnosti brány. Kontrola se provádí každých 10 sekund, plus časový limit odpovědi. Celkově se skutečný čas přepnutí pohybuje v rozmezí 20-30 sekund. Pokud je tento čas přepnutí nedostatečný, existuje možnost využít nástroj Netwatch, kde lze ručně nastavit časovač kontroly. Mechanismus Check-gateway nefunguje při občasných ztrátách paketů v kanálu.

    Důležité! Deaktivace hlavní trasy má za následek deaktivaci všech ostatních tras, které na ni odkazují. Proto je pro ně nutné uvést check-gateway=ping není nutné.

  2. Někdy dochází k selhání v mechanismu DHCP, které vypadá jako klient visící ve stavu renew. V takovém případě druhá část skriptu neproběhne, ale správné připojení k provozu nebude překážet, neboť stav sleduje odpovídající rekurzivní trasu.
  3. ECMP (Equal Cost Multi-Path) — v ROS je možné nastavit trasu s několika bránami a stejnou vzdáleností. V takovém případě budou spojení rozdělena podle kanálů pomocí algoritmu round robin, proporcionálně k počtu uvedených bran.

Za impuls k napsání článku, pomoc při formování jeho struktury a umístění důrazů — osobní poděkování Evgeniovi @jscar

Zdroj: habr.com

Koupit spolehlivý hosting pro webové stránky s ochranou proti DDoS, VPS VDS servery 🔥 Koupit spolehlivý hosting pro webové stránky s ochranou proti DDoS, VPS VDS servery | ProHoster