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.