Konfiguracja kilku portów WAN przy pomocy mwan3 (failover, loadbalancer)

Może się zdarzyć tak, że będziemy mieli kiedyś dostęp do łącz kilku różnych ISP. Jeśli chcielibyśmy skorzystać z internetu w pewnej określonej chwili, trzeba się zdecydować na jednego z nich, co oczywiście sprawia, że ten drugi ISP w tej chwili jest niewykorzystywany, a przecie nie za to mu płacimy. Jeśli mamy router z wgranym OpenWRT i skonfigurowaliśmy przy tym switch tak by mieć kilka portów WAN, możemy korzystać z usług obu ISP w tym samym czasie i do tego używać ich łącz w pełni. Zatem jeśli ISP_1 daje nam 15/1 mbit, a ISP_2 35/4 mbit, w sumie będziemy mieli do wykorzystania 50/5mbit. Z tym, że to jest do dyspozycji wszystkich połączeń. Jeśli pobieramy jeden plik z internetu, to poleci on w dalszym ciągu pierwszym albo drugim kanałem, dając w rezultacie będzie 15 lub 35 mbitów transferu. Jeśli natomiast uruchomimy kilka jednoczesnych połączeń przy pobieraniu tego pliku, wtedy część pliku będzie pobierana przez jednego ISP, a pozostała część przez drugiego. W przypadku stron www, każde wejście na jakąś stronę, generuje wiele połączeń, zatem będą one wysyłane do różnych ISP.

Minimalna konfiguracja, jaka będzie nam potrzebna, to trzy interfejsy -- jednen LAN i 2 WAN. Musimy także upewnić się, że nie korzystamy z DNS żadnego ISP, którzy będą brać udział w konfiguracji mwan3. Chodzi o to, że jeśli byśmy korzystali z serwera DNS jednego ISP, to po przełączeniu się na drugie łącze, w przypadku awarii pierwszego lub zwyczajnie podczas balansowania ruchu, zapytania DNS będą blokowane przez któregoś ISP, bo będą pochodzić spoza jego sieci i dlatego musimy korzystać z globalnych DNS-providerów, np. google czy opendns. Podobnie z pozostałymi usługami konkretnych ISP, np. email -- nie możemy korzystać z nich jeśli zamierzamy robić loadbalancing czy network failover.

Metryki

Mając już przygotowanego switcha i VLANy, musimy ustawić metryki dla tras wszystkich interfejsów WAN. Domyślnie mają one sprecyzowane 0 i możemy w systemie posiadać tylko jedną domyślną bramę. Jako, że w tym przypadku są dwa interfejsy WAN, musimy posiadać informacje o obu bramach domyślnych. Edytujemy zatem plik /etc/config/network i dodajemy linijki z metric do każdego bloku WAN:

...
config interface 'wan'
	...
	option ifname 'eth0'
	option metric '5'
...
config interface 'wan2'
	...
	option ifname 'eth1.3'
	option metric '10'
...

Im niższa wartość metryki, tym brama ma większy priorytet. W ten sposób określimy pożądaną przez nas kolejność bramek domyślnych. Poniżej listingi poleceń route i ip:

root@the-mountain:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         130.50.124.253  0.0.0.0         UG    5      0        0 eth0
default         20.1.255.253    0.0.0.0         UG    10     0        0 eth1.3
20.1.0.0        *               255.255.0.0     U     10     0        0 eth1.3
130.50.124.0    *               255.255.255.0   U     5      0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
root@the-mountain:~# ip route show
default via 130.50.124.253 dev eth0  proto static  metric 5 
default via 20.1.255.253 dev eth1.3  proto static  metric 10 
20.1.0.0/16 dev eth1.3  proto static  scope link  metric 10 
130.50.124.0/24 dev eth0  proto static  scope link  metric 5 
192.168.1.0/24 dev br-lan  proto kernel  scope link  src 192.168.1.1

Instalacja mwan3

Jeśli do tego miejsca udało nam się uzyskać wyniki podobne do powyższych i po zresetowaniu routera mamy internet, który wychodzi przez główną bramę (tę z niższą metryką), oznacza to, że możemy przejść do instalowania pakietu mwan3 :

root@the-mountain:~# opkg update
root@the-mountain:~# opkg install mwan3

Konfiguracja pakietu odbywa się przez plik /etc/config/mwan3 i całość działa, można by rzec, OOTB, przynajmniej w przypadku dwóch interfejsów WAN -- wystarczy włączyć ten drugi w konfiguracji:

...
config interface 'wan2'
	option enabled '1'
	...

Po resecie routera, oba linki powinny zostać aktywowane i całość powinna działać. Oczywiście, nie musimy resetować urządzenia, możemy wpisać w terminalu poniższe polecenia i konfiguracja także zostanie przeładowana:

root@the-mountain:~# mwan3 stop
root@the-mountain:~# mwan3 start

Sprawdzamy, czy oba interfejsy działają przesyłając przez każdy z nich ping do serwerów gógla:

root@the-mountain:~# ping -c 5 -I eth1.3 www.google.com
PING www.google.com (94.40.70.16): 56 data bytes
64 bytes from 94.40.70.16: seq=0 ttl=61 time=15.587 ms
64 bytes from 94.40.70.16: seq=1 ttl=61 time=17.993 ms
64 bytes from 94.40.70.16: seq=2 ttl=61 time=14.063 ms
64 bytes from 94.40.70.16: seq=3 ttl=61 time=15.362 ms
64 bytes from 94.40.70.16: seq=4 ttl=61 time=15.188 ms

--- www.google.com ping statistics

5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 14.063/15.638/17.993 ms
root@the-mountain:~# ping -c 5 -I eth0 www.google.com
PING www.google.com (94.40.70.37): 56 data bytes
64 bytes from 94.40.70.37: seq=0 ttl=61 time=12.421 ms
64 bytes from 94.40.70.37: seq=1 ttl=61 time=14.592 ms
64 bytes from 94.40.70.37: seq=2 ttl=61 time=15.717 ms
64 bytes from 94.40.70.37: seq=3 ttl=61 time=15.299 ms
64 bytes from 94.40.70.37: seq=4 ttl=61 time=15.383 ms

--- www.google.com ping statistics

5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 12.421/14.682/15.717 ms

Zatem pakiety mają wyjście na świat zarówno przez pierwszy WAN jak i przez drugi.

Konfiguracja mwan3

Plik konfiguracyjny mwan3 zawiera dość sporo parametrów i przydałoby się je omówić. Opcja interface wskazuje nazwę interfejsu, która jest określona w pliku /etc/config/network , w tym przypadku są to wan i wan2 . Opcja enabled określa czy mwan3 ma brać pod uwagę ten interfejs. Dalej mamy list track_ip , który to definiuje adres hosta i to w oparciu o niego będzie przeprowadzany test łącza. Można sprecyzować kilka takich opcji, jak i również można ten parametr całkowicie pominąć i w takim przypadku interfejs będzie uznawany zawsze za działający. Kolejna opcja w pliku to reliability i przyjmuje ona wartość liczbową określająca ile hostów, z tych sprecyzowanych w track_ip , musi udzielić odpowiedzi, by traktować dany interfejs jako działający. Następnie mamy count , który określa ilość żądań ping wysyłanych do hostów podczas testów. Z kolei timeout definiuje ile czasu (w sekundach) system będzie czekał na odpowiedź na wysłane żądanie pingu po czym da sobie spokój i zgłosi błąd. Opcja interval określa częstotliwość próbkowania łącza, czyli co ile sekund zostanie wysłany ping. Ostatnie dwie opcje w bloku interface , czyli up i down definiują ile testów musi przejść interfejs by został uznany odpowiednio za działający i padnięty.

Dobrze jest przemyśleć dobór wartości w powyższych parametrach, by czasem interfejs nie był zbyt często przez pomyłkę uznawany za trupa. Podobnie trzeba rozważyć podniesienie niektórych wartości w przypadku łącz o słabszej jakości.
Kolejne dwie sekcje w pliku, tj. config member i config policy są ze sobą powiązane. To tutaj, na podstawie metryk (metric) i wag (weight), będzie zapadać decyzja o konfiguracji ruchu. Każdy interfejs wymaga do prawidłowego działania minimum dwóch sekcji config member , przynajmniej ma to zastosowanie przy porównywaniu dwóch interfejsów, w przypadku 3 i więcej trzeba dopisać odpowiednie bloki. W każdym razie, tutaj mamy tylko dwa interfejsy, zatem potrzebne nam są dwie sekcje config member dla każdego z nich, łącznie 4. W każdej z tych 4 zwrotek definiujemy różne metryki -- im mniejszy numer tym większy priorytet. W blokach config policy będą określone różne polityki zachowań się łącza w przypadku gdy zostaną spełnione określone warunki i to na podstawie sprecyzowanych metryk będzie podejmowana decyzja czy używać jednego łącza czy też drugiego. W przypadku gdy metryka ma taki sam numerek w obu przypadkach, wtedy nastąpi podział łącza w stosunku określonym przez parametr weight, w tym przypadku 2/3 czyli 40%/60%.
Jako, że mamy 2 interfejsy WAN, możemy ustawić następujące polityki zachowań:

  • korzystamy tylko z pierwszego interfejsu WAN
  • korzystamy tylko z drugiego interfejsu WAN
  • korzystamy z obu interfejsów do równoważenia obciążenia
  • preferujemy korzystanie z pierwszego interfejsu WAN, gdy ten zawiedzie, pakiety lecą przez drugi interfejs WAN
  • preferujemy korzystanie z drugiego interfejsu WAN, gdy ten zawiedzie, pakiety lecą przez pierwszy interfejs WAN

I te powyższe przypadki zostały ujęte w bloki config policy .
Zdefiniowanie polityki nic jeszcze nie oznacza -- trzeba do nich dorobić reguły, a te są określane przez zwrotki z config rule . Reguły można aplikować do portów źródłowych (src_port) i docelowych (dest_port), adresów źródłowych (src_ip) i docelowych (dest_ip), oraz do protokołów (proto). Kolejność w jakiej zostały określone reguły ma znaczenie. Dlatego też najlepiej na samym końcu umieścić domyślną regułę, a powyżej niej te mniej restrykcyjne.

Jeśli chcemy aby nasz router zachowywał się jak loadbalancer, czyli równoważył ruch między dwóch ISP, ustawiamy:

config rule 'default_rule'
	option dest_ip '0.0.0.0/0'
	option use_policy 'balanced

W opcji use_policy podajemy jedną z nazw określonych w blokach config policy .

Jeśli do tego chcemy by ruch z/do jednego hosta z naszej sieci zawsze szedł przez interfejs WAN2, dodajemy poniższy blok:

config rule 'host_wan2'
        option src_ip '192.168.1.150'
        option use_policy 'wan2_wan

W ten sposób możemy decydować o tym gdzie przesłać określony ruch przechodzący przez router, np. gdy chcemy posłać protokół https i http przez jednego IPS, a resztę, np. torrenty, przez drugiego. W każdej regule może być określony jeden protokół, jeden port źródłowy i docelowy, oraz jeden adres źródłowy i docelowy.

Statystyki

W przypadku ustawienia odpowiedniego podziału łącza, możemy sprawdzić jak wyglądają statystyki:

root@the-mountain:~# mwan3 status
Interface status:
Interface wan is online (tracking active)
Interface wan2 is online (tracking active)
Policy balanced:
 wan2 (40%)
 wan (60%)
Policy wan2_only:
 wan2 (100%)
Policy wan2_wan:
 wan2 (100%)
Policy wan_only:
 wan (100%)
Policy wan_wan2:
 wan (100%)
Known networks:
destination        policy             hits
-----------------------------------------------
127.0.0.0/8        default            5
224.0.0.0/3        default            22
20.1.0.0/16        default            1427
130.50.124.0/24    default            2219
192.168.1.0/24     default            18
Active rules:
source             destination        proto  src-port      dest-port     policy          hits
--------------------------------------------------------------------------------------------------
0.0.0.0/0          0.0.0.0/0          tcp    0:65535       443           wan_wan2        27
0.0.0.0/0          0.0.0.0/0          tcp    0:65535       80            wan2_wan        86
0.0.0.0/0          0.0.0.0/0          all                                balanced        344

Z powyższego logu wynika, że mam dwa interfejsy podzielone w proporcji 2/3 oraz oba interfejsy są aktywne i działają. Ruch na port 443/tcp, czyli https jest kierowany przez interfejs WAN, natomiast nieszyfrowane strony www (port 80/tcp) są kierowane na interfejs WAN2. Obie opcje mają uwzględniony failover, tj. w przypadku padu któregoś z interfejsów, ruch poleci drugim kanałem. Domyślna polityka dla ruchu innego niż www, wszystko jedno czy szyfrowanego czy też nie, będzie równoważyć obciążenie i rozsyłać pakiety na oba interfejsy w proporcjach określonych wyżej.