🥇Multipath i routowanie w Mikrotik RouterOS

Wprowadzenie

Podjęcie się napisania artykułu, oprócz próżności, było spowodowane niepokojącą częstością występowania pytań na ten temat w profilu grupach rosyjskojęzycznego społeczności Telegram. Artykuł jest skierowany do początkujących administratorów Mikrotik RouterOS (dalej ROS). Dotyczy jedynie multivan, koncentrując się na routingu. W bonusie znajdują się minimalne ustawienia zapewniające bezpieczną i wygodną pracę. Ci, którzy szukają omówienia tematów kolejek, balansowania obciążenia, VLAN-ów, mostków, wielostopniowej analizy stanu kanału i tym podobnych — mogą nie marnować czasu i sił na lekturę.

Dane źródłowe

Jako obiekt badawczy wybrano pięcioportowy router Mikrotik z wersją ROS 6.45.3. Będzie on routować ruch między dwiema sieciami lokalnymi (LAN1 i LAN2) oraz trzema dostawcami (ISP1, ISP2, ISP3). Kanał do ISP1 ma statyczny 'szary' adres, ISP2 — 'biały', uzyskiwany przez DHCP, ISP3 — 'biały' z autoryzacją PPPoE. Schemat połączenia przedstawiono na rysunku:

Zadanie polega na skonfigurowaniu routera 'MTK' na podstawie schematu tak, aby:

Zapewnić automatyczne przełączanie na zapasowego dostawcę. Główny dostawca — ISP2, pierwszy zapas — ISP1, drugi zapas — ISP3.
Zorganizować wyjście sieci LAN1 do Internetu tylko przez ISP1.
Przewidzieć możliwość routowania ruchu z lokalnych sieci do Internetu przez wybranego dostawcę na podstawie address-list.
Przewidzieć możliwość publikacji usług z sieci lokalnej do Internetu (DSTNAT)
Skonfigurować filtr zapory ogniowej, aby zapewnić minimalne bezpieczeństwo ze strony Internetu.
Router mógłby wypuszczać własny ruch przez dowolnego z trzech dostawców, w zależności od wybranego adresu źródłowego.
Zapewnić routowanie pakietów odpowiedzi do kanału, z którego one przyszły (w tym LAN).

Uwaga. Router będziemy konfigurować 'od zera', aby zagwarantować brak niespodzianek w zmieniających się z wersji na wersję startowych konfiguracjach 'prosto z pudełka'. Jako narzędzie konfiguracyjne wybrano Winbox, w którym będą wizualnie wyświetlane zmiany. Same ustawienia będą wprowadzane poleceniami w terminalu Winbox. Fizyczne połączenie do konfiguracji odbywa się przez bezpośrednie podłączenie do interfejsu Ether5.

Kilka przemyśleń na temat tego, czym jest multivan, czy to problem, czy może przebiegli mądrale sieci plączą spiski

Ciekawski i uważny admin, samodzielnie konfigurując taką lub podobną schemę, nagle zdaje sobie sprawę, że wszystko działa normalnie. Tak, tak, bez tych waszych użytkowników tablic routingu i innych reguł trasowania, którymi przepełnione są większość artykułów na ten temat. Sprawdźmy?

Czy możemy skonfigurować adresację na interfejsach i bramy domyślne? Tak:

Na ISP1 zapisujemy adres i bramę z distance=2 i check-gateway=ping.
Na ISP2 domyślna konfiguracja klienta dhcp - odpowiednio distance wyniesie jeden.
Na ISP3 w ustawieniach klienta pppoe przy add-default-route=yes ustawiamy default-route-distance=3.

Nie zapomnijmy skonfigurować NATu na wyjściu:

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

W rezultacie użytkownicy lokalni z radością ładują się przez głównego dostawcę ISP2, z rezerwacją pasma za pomocą mechanizmu check gateway Zob. przypis 1

Punkt 1 zadania zrealizowany. Gdzie jest multivan ze swoimi znacznikami? Nie...

Dalej. Należy wydostać konkretnych klientów z LAN przez 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

Punkty 2 i 3 zadania zrealizowane. Gdzie są znaczki, markery, reguły trasowania?!

Czy musimy zapewnić dostęp do ulubionego serwera OpenVPN z adresem 172.17.17.17 dla klientów z Internetu? Proszę bardzo:

/ip cloud set ddns-enabled=yes

Klientom jako peer podajemy wynik polecenia: “:put [ip cloud get dns-name]”

Konfigurujemy przekierowanie 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

Punkt 4 gotowy.

Konfigurujemy zaporę i inne zabezpieczenia dla punktu 5, równocześnie ciesząc się, że u użytkowników już wszystko działa i sięgamy po pojemnik z ulubionym napojem…
A! Zapomnieliśmy o tunelach.

Klient l2tp, skonfigurowany według znalezionego artykułu, połączył się z ulubionym holenderskim VDS? Tak.
Serwer l2tp z IPsec został uruchomiony, a klienci łączą się po nazwie DNS z IP Cloud (patrz powyżej)? Tak.
Odpoczywając na oparciu krzesła, popijając napój, leniwie oglądamy punkty 6 i 7 zadania. Myślimy - czy to naprawdę jest nam potrzebne? Przecież wszystko działa (z)... Więc jeśli to nie jest potrzebne, to na tym kończymy. Multivan zrealizowany.

Czym jest multivan? To podłączenie kilku łączy Internetu do jednego routera.

Dalej artykułu nie trzeba czytać, ponieważ co tam poza popisami wątpliwej przydatności może być?

Z tymi, którzy pozostali, zainteresowani punktami 6 i 7 zadania, a także odczuwają dreszczyk perfekcjonizmu, zagłębiamy się dalej.

Najważniejszym zadaniem realizacji multiwan jest poprawne trasowanie ruchu. A mianowicie: niezależnie od tego, w którym (lub w jakich) kanale dostawcy nasz router widzi domyślną trasę, musi on zwracać odpowiedź dokładnie do tego kanału, z którego pakiet przyszedł. Zadanie jest jasne. Gdzie tkwi problem? Przecież w zwykłej sieci lokalnej zadanie jest takie same, ale nikt nie bawi się dodatkowymi ustawieniami i nie odczuwa żadnych trudności. Różnica polega na tym, że każdy trasowany węzeł w Internecie jest dostępny przez każdy z naszych kanałów, a nie przez ściśle określony, jak w zwykłej lokalnej sieci. A „problem” polega na tym, że jeśli do nas dotarł żądanie na adres IP ISP3, to w naszym przypadku odpowiedź odejdzie przez kanał ISP2, ponieważ tam wskazany jest domyślny brama. Odejście i zostanie odrzucone przez dostawcę jako niepoprawne. Problem został zidentyfikowany. Jak go rozwiązać?

Rozwiązanie podzielimy na trzy etapy:

Wstępne ustawienia. Na tym etapie zostaną ustalone podstawowe ustawienia routera: sieć lokalna, zapora, listy adresowe, NAT hairpin itp.
Multiwan. Na tym etapie połączenia potrzebne do trasowania będą oznaczone i uporządkowane w odpowiednich tabelach.
Podłączenie do ISP. Na tym etapie skonfigurujemy interfejsy zapewniające połączenie z Internetem, zaangażujemy trasowanie i mechanizm rezerwacji kanałów Internetowych.

1. Wstępne ustawienia

1.1. Czyścimy konfigurację routera poleceniem:

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

zgadzamy się na "Dangerous! Reset anyway? [y/N]:" i po ponownym uruchomieniu łączymy się przez Winbox po MAC. Na tym etapie konfiguracja i baza użytkowników zostały wyczyszczone.

1.2. Tworzymy nowego użytkownika:

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

logujemy się na niego i usuwamy domyślnego:

/user remove admin

Uwaga. Usunięcie, a nie wyłączenie domyślnego użytkownika autor uważa za bardziej bezpieczne i zaleca jego zastosowanie.

1.3. Tworzymy podstawowe listy interfejsów dla ułatwienia operacji w zaporze, ustawieniach wykrywania i innych serwerach MAC:

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

Podpisujemy interfejsy komentarzami

/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"

i wypełniamy listy interfejsów:

/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"

Uwaga. Pisanie zrozumiałych komentarzy jest warte czasu poświęconego na nie, a także znacznie ułatwia rozwiązywanie problemów i zrozumienie konfiguracji.

Autor uznaje za konieczne, w celu bezpieczeństwa, dodać do listy interfejsów „WAN” interfejs ether3, mimo że nie będzie przez niego przechodził protokół ip.

Nie zapominajmy, że po uruchomieniu interfejsu PPP na ether3, również trzeba go dodać do listy interfejsów „WAN”.

1.4. Ukrywamy router przed wykrywaniem sąsiedztwa i zarządzaniem z sieci dostawców przez 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. Tworzymy minimalny zestaw reguł filtracji zapory ogniowej w celu ochrony routera:

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

(reguła ta zapewnia zezwolenie dla istniejących i pokrewnych połączeń, które są inicjowane zarówno z podłączonych sieci, jak i przez sam router)

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

(ping i nie tylko ping. Wszystkie połączenia ICMP są dozwolone na wejściu. Bardzo przydatne w diagnozowaniu problemów z MTU)

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

(zamykająca łańcuch reguła input zabrania wszystkiego innego, co przychodzi z Internetu)

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

(reguła zezwala na istniejące i pokrewne połączenia, które przechodzą przez router)

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

(reguła ta resetuje połączenia z connection-state=invalid, które przechodzą przez router. Jest zdecydowanie zalecana przez Mikrotik, ale w niektórych rzadkich przypadkach może blokować użyteczny ruch)

/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

(reguła ta zabrania przechodzenia przez router pakietom, które pochodzą z Internetu i nie przeszły procedury dstnat. Uchroni to lokalne sieci przed atakującymi, którzy, znajdując się w tej samej domenie rozgłoszeniowej co nasze zewnętrzne sieci, spróbują „zbadać” nasze lokalne sieci, podając nasze zewnętrzne IP jako bramę.)

Uwaga. Przyjmujemy założenie, że sieci LAN1 i LAN2 są zaufane i ruch między nimi oraz z nich nie jest filtrowany.

1.6. Tworzymy listę z wykazem nieprzekierowywanych sieci:

/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 jest lista adresów i sieci, które nie są przekierowywane do Internetu i, odpowiednio, będziemy się do tego stosować.)

Uwaga. Lista może się zmieniać, więc zalecam regularne sprawdzanie aktualności.

1.7. Konfigurujemy DNS dla samego routera:

/ip dns set servers=1.1.1.1,8.8.8.8

Uwaga. W obecnej wersji ROS dynamiczne serwery Mają priorytet nad statycznie określonymi. Żądanie rozwiązania nazwy jest wysyłane do pierwszego serwera w kolejności na liście. Przechodzi się do następnego serwera, gdy bieżący jest niedostępny. Czas oczekiwania jest długi — ponad 5 sek. Powrót do pracy "zawalonego serwera" nie następuje automatycznie po jego wznowieniu. Biorąc pod uwagę ten algorytm i obecność multiranżowania, autor zaleca unikanie serwerów dostarczanych przez dostawców.

1.8. Konfigurujemy sieć lokalną.
1.8.1. Konfigurujemy statyczne adresy IP na interfejsach sieci lokalnych:

/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. Ustalamy zasady trasowania do naszych sieci lokalnych przez główną tabelę routingu:

/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"

Uwaga. To jeden z prostych i szybkich sposobów, aby uzyskać dostęp do adresów lokalnych sieci z zasobami zewnętrznych adresów IP interfejsów routera, przez które nie prowadzi domyślny routing.

1.8.3. Włączamy Hairpin NAT dla LAN1 i 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

Uwaga. To pozwala uzyskać dostęp do swoich zasobów (dstnat) za pośrednictwem zewnętrznego IP, będąc wewnątrz sieci.

2. Właściwie, realizacja tego właściwego multiranżowania

Aby rozwiązać zadanie "odpowiadać tam, skąd zapytano", użyjemy dwóch narzędzi ROS: znaczenie połączenia i znaczenie routingu. Znaczenie połączenia pozwala na oznaczenie wymaganego połączenia i późniejsze operacje z tą etykietą jako warunkiem zastosowania znaczenie routingu. A już z znaczenie routingu można pracować w ip route i reguły trasowania. Z narzędziami się zapoznaliśmy, teraz musimy zdecydować, które połączenia oznaczać — raz, gdzie dokładnie oznaczać — dwa.

Z pierwszym jest prosto — musimy oznaczyć wszystkie połączenia, które przychodzą do routera z Internetu przez odpowiedni kanał. W naszym przypadku będą to trzy etykiety (zgodnie z ilością kanałów): "conn_isp1", "conn_isp2" i "conn_isp3".

Sytuacja z drugim polega na tym, że przychodzące połączenia będą dwóch rodzajów: tranzytowe i takie, które są przeznaczone dla samego routera. Mechanizm znaku połączenia działa w tabeli mangle. Rozważmy ruch pakietów na uproszczonym schemacie, uprzejmie złożonym przez specjalistów z zasobu mikrotik-trainings.com (nie jest to reklama):

Podążając za strzałkami, widzimy, że pakiet, przychodzący na "input interface", przechodzi przez łańcuch "Prerouting" i dopiero potem dzieli się na tranzytowy i lokalny w bloku "Routing Decision". Dlatego, aby zabić dwa zające, zaangażujemy Connection Mark w tabeli Mangle Prerouting łańcuchy Prerouting.

Uwagi. W ROS etykiety „Routing mark” są wskazane w sekcji Ip/Routes/Rules jako „Table”, a w innych sekcjach jako „Routing Mark”. Może to wprowadzać pewne zamieszanie w zrozumieniu, ale w zasadzie są to te same rzeczy i odpowiadają rt_tables w iproute2 na linuxie.

2.1. Oznaczamy przychodzące połączenia od każdego z dostawców:

/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

Uwaga. Aby nie oznaczać już oznaczonych połączeń, używam warunku connection-mark=no-mark zamiast connection-state=new, ponieważ uważam to za bardziej poprawne, podobnie jak rezygnacja z odrzucania invalid połączeń w filtrze input.

passthrough=no — ponieważ w tym sposobie realizacji ponowne oznaczanie jest wykluczone, a dla przyspieszenia można przerwać przeszukiwanie reguł po pierwszym przyporządkowaniu.

Należy pamiętać, że na razie nie ingerujemy w routowanie. Obecnie trwają tylko etapy przygotowawcze. Następnym etapem realizacji będzie przetwarzanie ruchu tranzytowego, który wraca przez ustanowione połączenie od adresata w lokalnej sieci. Tzn. tych pakietów, które (patrz diagram) przeszły przez router w drodze:

„Input Interface”=>„Prerouting”=>„Routing Decision”=>„Forward”=>„Post Routing”=>„Output Interface” i dotarły do swojego adresata w lokalnej sieci.

WAŻNE! W ROS nie ma logicznego podziału na zewnętrzne i wewnętrzne interfejsy. Jeśli prześledzisz drogę pakietu odpowiedzi na podanym diagramie, przejdzie on tą samą logiczną drogą, co żądanie:

„Input Interface”=>„Prerouting”=>„Routing Decision”=>„Forward”=>„Post Routing”=>„Output Interface” po prostu dla żądania „Input Interface” był interfejs ISP, a dla odpowiedzi — LAN.

2.2. Kierujemy odpowiedni ruch tranzytowy zgodnie z odpowiednimi tabelami routingu:

/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

Uwaga. in-interface-list=!WAN — działamy tylko z ruchem z lokalnej sieci i dst-address-type=!local, który nie ma adresu docelowego interfejsów samego routera.

To samo dotyczy lokalnych pakietów, które dotarły do routera w drodze:

„Input Interface”=>„Prerouting”=>„Routing Decision”=>„Input”=>„Local Process”

WAŻNE! Odpowiedź pójdzie następującą drogą:

„Local Process”=>„Routing Decision”=>„Output”=>„Post Routing”=>„Output Interface”

2.3. Kierujemy odpowiedni lokalny ruch zgodnie z odpowiednimi tabelami routingu:

/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

Na tym etapie zadanie przygotowania do wysłania odpowiedzi do tego kanału Internet, z którego przyszło żądanie można uznać za rozwiązane. Wszystko jest oznaczone, oznakowane i gotowe do routingu.
Ciekawym „efektem ubocznym” tej konfiguracji jest możliwość jednoczesnej pracy DSNAT z obu providerów (ISP2, ISP3). Nie na wszystkich jednak, ponieważ na ISP1 mamy adres niemapowalny. Ten efekt jest ważny, na przykład, dla serwera pocztowego z dwoma MX, które kierują do różnych kanałów internetowych.

Aby rozwiązać problemy z lokalnymi sieciami korzystającymi z zewnętrznych IP routera, stosujemy rozwiązania z punktów 1.8.2 oraz 3.1.2.6.

Ponadto można wykorzystać narzędzie z oznaczeniami także do realizacji punktu 3 zadania. Osiągamy to w sposób następujący:

2.4. Kierujemy ruch od lokalnych klientów z list tras routingu do odpowiednich tabel:

/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

Na końcu wygląda to mniej więcej tak:

3. Konfigurujemy połączenie z ISP i włączamy routingu według oznaczeń.

3.1. Konfigurujemy połączenie z ISP1:
3.1.1. Konfigurujemy statyczny adres IP:

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

3.1.2. Ustalamy statyczne routowanie:
3.1.2.1. Dodajemy domyślną trasę „awaryjną”:

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

Uwaga. Ta trasa pozwala na ruch pochodzący z lokalnych procesów przechodzić przez etap Decyzji Trasowania, niezależnie od stanu kanałów któregokolwiek z providerów. Kluczowym elementem wychodzącego lokalnego ruchu jest to, że aby pakiet mógł gdziekolwiek trafić, w głównej tabeli routingu musi być aktywna trasa do bramy domyślnej. Jeśli jej nie ma, pakiet po prostu zostanie zniszczony.

Jako rozszerzenie narzędzia check gateway do głębszej analizy stanu kanału proponuję zastosować metodę tras rekurencyjnych. Istotą metody jest to, że wskazujemy routerowi, aby szukał drogi do swojej bramy nie bezpośrednio, lecz przez pośrednią bramę. Jako takie „sprawdzające” bramy zostaną wybrane 4.2.2.1, 4.2.2.2 oraz 4.2.2.3 odpowiednio dla ISP1, ISP2 i ISP3.

3.1.2.2. Trasa do „sprawdzanego” adresu:

/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

Uwaga. Wartość scope obniżamy do domyślnego w ROS target scope, aby w przyszłości wykorzystać 4.2.2.1 jako rekurencyjną bramę. Podkreślam: zakres trasy do „sprawdzanego” adresu musi być mniejszy lub równy target scope tej trasy, która będzie odwoływała się do adresu kontrolnego.

3.1.2.3. Domyślna trasa rekurencyjna dla ruchu bez znaku routingu:

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

Uwaga. Wartość distance=2 jest używana, ponieważ ISP1 w warunkach zadania jest określony jako pierwszy rezerwowy.

3.1.2.4. Domyślna trasa rekurencyjna dla ruchu z oznaczeniem routingu „to_isp1”:

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

Uwaga. Właściwie tutaj w końcu zaczynamy korzystać z owoców tej pracy przygotowawczej, która została wykonana w punkcie 2.

Na tym szlaku cały ruch, który ma znacznik trasy "to_isp1", będzie kierowany do bramy pierwszego dostawcy, niezależnie od tego, który brama jest aktualnie aktywna jako domyślna dla tabeli głównej.

3.1.2.5. Pierwsza rezerwowa trasa rekurencyjna domyślna dla oznaczonego ruchu dostawców ISP2 i 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

Uwaga. Te trasy są potrzebne, w tym do rezerwacji ruchu z lokalnych sieci, które składają się z członków listy adresowej "to_isp*".

3.1.2.6. Określamy trasę dla lokalnego ruchu routera do internetu przez ISP1:

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

Uwaga. W połączeniu z zasadami z punktu 1.8.2, zapewnia wyjście do odpowiedniego kanału z określonym źródłem. Jest to krytyczne dla budowy tuneli, w których określany jest adres IP lokalnej strony (EoIP, IP-IP, GRE). Ponieważ zasady w regułach tras ip są wykonywane od góry do dołu, aż do pierwszego spełnienia warunków, ta zasada powinna być po zasadach z punktu 1.8.2.

3.1.3. Określamy regułę NAT dla wychodzącego ruchu:

/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

Uwaga. NAT dla całego wychodzącego, z wyjątkiem tego, co wpada w polityki IPsec. Staram się nie używać action=masquerade bez konieczności. Działa wolniej i jest bardziej zasobożerne niż src-nat, ponieważ dla każdego nowego połączenia oblicza adres do NAT.

3.1.4. Kierujemy klientów z listy, którym zabroniono wyjścia przez innych dostawców, od razu na bramę dostawcy 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

Uwaga. action=route ma wyższy priorytet i stosowane jest wcześniej niż inne reguły trasowania.

place-before=0 — umieszcza naszą regułę jako pierwszą na liście.

3.2. Konfigurujemy połączenie z ISP2.

Ponieważ dostawca ISP2 daje nam ustawienia przez DHCP, rozsądnie jest wprowadzać potrzebne zmiany za pomocą skryptu, który uruchamia się po aktywacji klienta DHCP:

/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

Sam skrypt w oknie Winbox:

Uwaga. Pierwsza część skryptu uruchamia się po pomyślnym uzyskaniu dzierżawy, druga — po zwolnieniu dzierżawy.Zob. przypis 2

3.3. Konfigurujemy połączenie z dostawcą ISP3.

Ponieważ dostawca przekazuje nam dynamiczne ustawienia, rozsądnie jest wprowadzać potrzebne zmiany za pomocą skryptów, które uruchamiają się po aktywacji i po upadku interfejsu ppp.

3.3.1. Najpierw konfigurujemy 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"

Sam skrypt w oknie Winbox:

Uwaga. Ciąg
/ip firewall mangle set [find comment=«Connmark in from ISP3»] in-interface=$«interface»;
umożliwia prawidłową obsługę zmiany nazwy interfejsu, ponieważ działa z jego kodem, a nie nazwą wyświetlaną.

3.3.2. Teraz, używając profilu, tworzymy połączenie ppp:

/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 zakończenie skonfigurujemy zegary:

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

Dla tych, którzy dotarli do końca

Proponowany sposób realizacji multipath to osobiste preferencje autora i nie jest jedyną możliwą opcją. Narzędzia w ROS są obszerne i elastyczne, co z jednej strony stwarza trudności dla początkujących, a z drugiej — jest powodem popularności. Uczcie się, eksperymentujcie, odkrywajcie nowe narzędzia i rozwiązania. Na przykład, w tej realizacji multipath można zastąpić narzędzie Check-gateway z rekursywnymi trasami na Netwatch.

Uwagi

Check-gateway — to mechanizm, który pozwala dezaktywować trasę po dwóch kolejnych nieudanych próbach sprawdzenia dostępności bramy. Sprawdzanie odbywa się co 10 sekund, plus timeout odpowiedzi. Tak więc, rzeczywisty czas przełączania wynosi od 20 do 30 sekund. Jeśli taki czas przełączania jest niewystarczający — istnieje opcja skorzystania z narzędzia Netwatch, gdzie czas sprawdzania można ustawiać ręcznie. Mechanizm Check-gateway nie działa podczas okresowych strat pakietów w kanale.
Uwaga! Dezaktywacja głównej trasy powoduje dezaktywację wszystkich innych tras, które na nią wskazują. Dlatego dla nich nie ma potrzeby wskazywania check-gateway=ping nie jest konieczne.
Czasami, w mechanizmie działania DHCP następuje awaria, która wygląda jak klient zawieszony w stanie renew. W takim przypadku druga część skryptu nie zostanie wykonana, ale prawidłowy ruch nie zostanie zakłócony, ponieważ stan jest monitorowany przez odpowiednią rekursywną trasę.
ECMP (Equal Cost Multi-Path) — w ROS istnieje możliwość ustawienia trasy z wieloma bramami o tej samej odległości. W takim przypadku połączenia będą rozdzielane między kanały, korzystając z algorytmu round robin, proporcjonalnie do liczby wskazanych bram.

Za impuls do napisania artykułu, pomoc w formowaniu jego struktury i ustalaniu akcentów — osobiste podziękowanie dla Jewgienija @jscar

Źródło: habr.com