Wstęp

Artykuł jest o tym jak poradzić sobie z sytuacją, kiedy mamy w firmie/domu dwa łącza internetowe, z których jedno służy jako łącze zapasowe. Na wypadek awarii naszego routera zabezpieczamy się drugim takim samym, który jednak nie leży na półce i czeka na gorsze czasy, lecz łączymy oba za pomocą Virtual Router Redundancy Protocol. Zatem mamy dwóch różnych ISP oraz 2 routery, które asekurują siebie na wzajem w razie gdyby jeden z nich uległ awarii lub padło łącze od jednego z dostawców.

Sednem projektu jest doprowadzenie do sytuacji, w której awaria któregoś z routerów lub łącza internetowego będzie prawie niezauważalną dla użytkowników przerwą w dostępie do sieci – to znaczy będzie trwała 1-3s. Oczywiście sposób ten nie uchroni nas od sytuacji w której pada jeden router, a na drugim routerze i tak już mamy brak łączności ze światem.

Czego ten artykuł nie obejmuje?

Artykuł nie obejmuje konfiguracji serwera DHCP przy użyciu VRRP. Nie obejmuje również konfiguracji podziału sieci na VLAN’y.

Co w skrócie będziemy konfigurować?

Połączenie z operatorami, przekierowywanie ruchu w ich stronę. Ustalenie najprostszych regułek filtrujących ruch przychodzący z poza naszej sieci. Konfiguracja load-balancingu, tak aby jedno łącze działało wyłącznie jako failover w razie awarii. Następnie przejdziemy do połączenia naszych routerów w VRRP i przetestowanie działania redundancji.

Czy będzie GUI?

Nie będzie.

Poniżej trochę więcej o wykorzystanym (dla Ciebie przykładowym) sprzęcie, który umożliwi zrealizowanie tego lub podobnego scenariusza, jak i z grubsza koncepcję całego przedsięwzięcia.

Możliwości i wymagania techniczne

Każdy z naszych dwóch ISP daje nam po jednym interfejsie fizycznym, do którego możemy wpiąć nasz [tylko jeden] router, a przecież w szafie przykręcone są dwa routery? Z pomocą przychodzi przełącznik L2, aby rozdzielić naszych dwóch po cichu konkurujących ze sobą dostawców internetu na 2 VLAN’y.
Za dostawców internetu podszywał się będzie tani routerek, na którego dwóch interfejsach fizycznych zaterminujemy adresy IP i połączymy je patchcordami do konkretnych portów na przełączniku. Teraz możemy rozdzielić sygnał każdego z dostawcy do dwóch routerów. Po jednym porcie fizycznym z każdego z routerów podłączamy również do przełącznika, co będzie stanowiło stronę sieci wewnętrznej placówki.
Jeszcze jednym elementem w naszej układance będzie udostępnienie przez ISP „dodatkowego” publicznego adresu IP. Niestety podsieć /30 per operator nie wystarczy ponieważ, jeden i drugi router muszą mieć aktywną łączność po warstwie L3, aby w razie potrzeby szybko się przełączyć.

W skrócie co będzie Nam potrzebne (w nawiasie zastosowany przeze mnie sprzęt):
2x podsieć /29 [po jednej od każdego operatora]

2x router Ubiquiti (EdgeRouter ER-6P)
1x router z możliwością przypisania adresów IP do dwóch interfejsów fizycznych (Mikrotik RB941)
1x przełącznik L2/L3 (Cisco C9300-48T-E)
1x PC do konfiguracji oraz testów
9x patchcord RJ45

Schemat

Konfiguracja

Aby nasza redundancja działała prawidłowo docelowo potrzebujemy skonfigurować adresy IP na interfejsach fizycznych i stworzyć VRRP na interfejsach po stronie LAN.
Dodatkowo ustawimy load-balance’ra na interfejsach WAN oraz regułki firewall, które z kolei będą czuwał, aby nie był balansowany ruch po stronie LAN, a jedynie po stronie WAN.
Na koniec skonfigurujemy samego load-balance’ra i przetestujemy jego działanie.

PS: Proszę wziąć pod uwagę, iż zaznaczone na schemacie VLAN’y w naszej konfiguracji nie posiadają swoich interfejsów logicznych (SVI), także nie tworzymy takowych ani na routerach, ani tym bardziej na przełączniku (jeśli mamy przełącznik L3). To co nam potrzebne, to porty przełącznika w trybie access z przypisanymi odpowiednimi dlań VLAN’ami.

Przyznajemy adresy IP interfejsom fizycznym oraz konfigurujemy grupę VRRP:

R1#
set interfaces ethernet eth0 address 192.168.11.2/29
set interfaces ethernet eth1 address 192.168.12.2/29
set interfaces ethernet eth4 address 10.10.10.1/29

set interfaces ethernet eth4 vrrp vrrp-group 10 advertise-interval 1
set interfaces ethernet eth4 vrrp vrrp-group 10 preempt true
set interfaces ethernet eth4 vrrp vrrp-group 10 priority 250
set interfaces ethernet eth4 vrrp vrrp-group 10 virtual-address 10.10.10.3/29

R2#
set interfaces ethernet eth0 address 192.168.11.3/29
set interfaces ethernet eth1 address 192.168.12.3/29
set interfaces ethernet eth4 address 10.10.10.2/29

set interfaces ethernet eth4 vrrp vrrp-group 10 advertise-interval 1
set interfaces ethernet eth4 vrrp vrrp-group 10 priority 50
set interfaces ethernet eth4 vrrp vrrp-group 10 virtual-address 10.10.10.3/29

Tworzymy regułki firewall’a, które spowodują działanie load-balancer’a tylko na porty WAN. Regułki są takie same na obu routerach:

set firewall modify balance rule 10 action modify
set firewall modify balance rule 10 destination group network-group LAN
set firewall modify balance rule 10 modify table main
set firewall modify balance rule 20 action modify
set firewall modify balance rule 20 destination group address-group ADDRv4_eth0
set firewall modify balance rule 20 modify table main
set firewall modify balance rule 30 action modify
set firewall modify balance rule 30 destination group address-group ADDRv4_eth1
set firewall modify balance rule 30 modify table main
set firewall modify balance rule 110 action modify
set firewall modify balance rule 110 modify lb-group LB

Następnie dodajemy reguły load-balancing’u. Konfiguracja jest taka sama na obu urządzeniach:

set load-balance group LB interface eth0 route-test count failure 2
set load-balance group LB interface eth0 route-test count success 1
set load-balance group LB interface eth0 route-test initial-delay 2
set load-balance group LB interface eth0 route-test interval 1
set load-balance group LB interface eth0 route-test type ping target 8.8.8.8
set load-balance group LB interface eth1 failover-only
set load-balance group LB interface eth1 route-test count failure 2
set load-balance group LB interface eth1 route-test count success 1
set load-balance group LB interface eth1 route-test initial-delay 2
set load-balance group LB interface eth1 route-test interval 1
set load-balance group LB interface eth1 route-test type ping target 8.8.8.8
set load-balance group LB lb-local enable
set load-balance group LB lb-local-metric-change enable
set load-balance group LB sticky source-addr enable

Wartości parametru router-test proszę modyfikować dowolnie i zależnie co sprawdzi się lepiej u Ciebie.
Jak widać port eth1 obu routerów jest ustawiony jako failover-only, zatem jest on dla nas portem „zapasowym” w razie jakby padł ISP#1 podpięty do eth0 obu routerów.

Na koniec dodamy konfigurację firewall do portów LAN, która wskaże routerowi jakich portów dotyczą stworzone przez nas reguły modify (na obu routerach jednakowo):

set interfaces ethernet eth4 firewall in modify balance

Routing do świata.
Ustawiamy teraz routing do obu naszych bram przyznanych przez poszczególnego ISP. Proszę pamiętać, aby ustawić odpowiednią wartość distance, jeśli chcemy, aby ruch był wypuszczany w danej kolejności. Wartość distance nie może być taka sama dla jednej trasy. Ustawiamy tu kolejność wysyłania pakietów do bramy ISP. Mniejsza wartość distance to większy priorytet. Na oby routerach konfigurujemy w ten sam sposób:

set protocols static route 0.0.0.0/0 next-hop 192.168.11.1 distance 1
set protocols static route 0.0.0.0/0 next-hop 192.168.12.1 distance 10

NAT dla sieci LAN.
Pozostało nam jeszcze skonfigurowanie NATu dla sieci LAN. Będą na to dwie reguły ze względu, że na świat wychodzimy przez 2 inne interfejsy fizyczne. Reguły NAT zaczynają się od reguły numer 5000. Analogicznie na dwóch urządzeniach konfiguracja wygląda tak samo:

set service nat rule 5000 description „MASQUARADE to ISP_1 (eth0)
set service nat rule 5000 outbound-interface eth0
set service nat rule 5000 source address 10.0.0.0/24
set service nat rule 5000 type masquerade

set service nat rule 5001 description „MASQUARADE to ISP_2 (eth1)
set service nat rule 5001 outbound-interface eth1
set service nat rule 5001 source address 10.0.0.0/24
set service nat rule 5001 type masquerade

W tym momencie możemy zacząć testować naszą konfigurację oraz to jak zadziała redundancja w przypadku symulowanej awarii jednego z łącz lub jednego z routerów.

Dziękuję za uwagę i mam nadzieję, że artykuł pomoże niejednej osobie uporać się z rozwiązaniem zagadnienia, którego tak jak ja jeszcze nie robił, ani nie testował czy działa.

Link do dyskusji:
facebook.com/groups/Ubiquiti.Polska/permalink/514209018986469/