Source-based routing w Linuksie w 5 minut

Vyatta, której namiętnie używamy na naszych głównych, jak i mniej głównych routerach nie obsługuje tzw. "source-based routingu", czyli routingu, który inaczej traktuje klientów pochodzących z różnych adresów IP. Temat ten wałkowany jest od lat na forach Vyatty i od lat jej producent obiecuje, że implementacja SBR pojawi się w końcu w kolejnej wersji. Niestety tak się nie dzieje... Można się z tym pogodzić albo... pogrzebać trochę w bebechach leżącego u podstaw Vyatty Debiana. Okazuje się to bardzo proste.

Na początek słówko wstępu: czyli jak, co i po co? Routing wbrew pozorom dotyczy każdego z nas, nawet jeśli nasze obcowanie z Internetem ogranicza się do rozmów na komunikatorze i wrzucania fotek na Facebooka. Każdy system, także Wasz Windows, posiada swoją własną tablicę routingu, czyli drogowskaz dla połączeń sieciowych. Najprawdopodobniej Wasza tablica routingu jest nieskomplikowana - ruch do innych komputerów w sieci lokalnej, jeśli jakieś w ogóle są, przesyłany jest bezpośrednio do tych komputerów (bo są podłączone fizycznie do tej samej sieci co Wasz komputer), zaś cały pozostały ruch wysyłany jest do Waszego dostawcy usług internetowych za pośrednictwem tzw. bramy domyślnej. Adres tej bramy to tzw. default route, domyślna ścieżka dla wszystkich połączeń, dla których nie ma ścieżek bardziej szczegółowych. Często określa się ją jako 0.0.0.0/0 albo default.

Wszystko co przechodzi przez Wasz system, przechodzi też przez tę tablicę routingu. Jedną i tę samą. Source-based routing to zmienia. Dzięki niemu możemy zdecydować: komputer A będzie obsługiwany przez tablicę X, zaś komputer B przez tablicę Y. Pozostałe komputery obsłuży tablica Z. Oczywiście możemy to rozciągnąć na całe sieci komputerów, według potrzeby. Z podobnym problemem zetknęliśmy się niedawno podczas zmiany konfiguracji routingu w biurze redakcji. Vyatta stanęła przed trudnym zadaniem: ruch do Internetu z części serwerów powinien być przekazywany do Warszawy (gdzie znajduje się nasza podstawowa serwerownia) i dopiero stamtąd wypychany do świata, zaś pozostałe komputery - w tym na przykład notebooki redaktorów - zwyczajnie powinny wychodzić na zewnątrz przez naszego wrocławskiego operatora, najkrótszą drogą.

Na szczęście okazało się, że mechanizmy sieciowe Vyatty nie wchodzą w konflikt ze standardowymi narzędziami sieciowymi Debiana, w tym przypadku pakietem iproute2. Bez większych problemów można stworzyć w systemie kolejne tablice routingu, o których co prawda interfejs Vyatty nie będzie nic wiedzieć, ale będą działać tak jak trzeba ;)

root@VYATTA04:/home/vyatta# ip route add default dev vtun1 table 1
root@VYATTA04:/home/vyatta# ip route add 10.0.0.0/24 dev eth0 table 1
root@VYATTA04:/home/vyatta# ip route add 194.0.171.64/26 dev eth0 table 1

Wykonanie powyższych poleceń (oczywiście jako root) sprawi, że Linux stworzy nową tablicę routingu o numerze 1 (domyślna tablica nie ma numeru, nazywa się main). Według tej tablicy ruch do sieci lokalnej 10.0.0.0/24 oraz podsieci 194.0.171.64/26 będzie przekazywany lokalnie przez podłączony interfejs eth0, zaś cały pozostały ruch - w tym ruch do Internetu - wychodzić będzie przez tunel OpenVPN o nazwie vtun1 - w naszym przypadku jest to tunel łączący siedzibę redakcji we Wrocławiu z serwerownią w Warszawie.

Możemy sprawdzić efekt powyższych poleceń wywołując listing obu tablic:

vyatta@VYATTA04:~$ ip route list table 1
default dev vtun1  scope link
10.0.0.0/24 dev eth0  scope link
194.0.171.64/26 dev eth0  scope link

vyatta@VYATTA04:~$ ip route list table main
default via 78.x.x.x dev eth1  proto zebra
10.0.0.0/24 dev eth0  proto kernel  scope link  src 10.0.0.254
78.x.x.x/29 dev eth1  proto kernel  scope link  src 78.x.x.x
127.0.0.0/8 dev lo  proto kernel  scope link  src 127.0.0.1

Jest to prawdziwa tablica routingu na jednym z naszych routerów, ale niektóre trasy które nie są związane z tematem tego posta usunąłem dla poprawy czytelności ;) Jak widać, nowa tablica 1 została dodana zgodnie z zamierzeniami. To jednak jeszcze nie wszystko. Teraz musimy dodać reguły, za pomocą których system zdecyduje, którą tablicę stosować dla których klientów.

root@VYATTA04:/home/vyatta# ip rule add from 194.0.171.64/26 table 1

Powyższe polecenie sprawi, że ruch pochodzący z podsieci 194.0.171.64/26 będzie obsługiwany przez dodaną przed momentem tablicę 1. Pozostały ruch trafi do domyślnej tablicy main. Na koniec trzeba jeszcze tylko odświeżyć cache routingu:

root@VYATTA04:/home/vyatta# ip route flush cache

I gotowe - działa od razu, nie trzeba niczego restartować etc. - to nie Windows ;) Jest niestety jeden problem: Vyatta całą konfigurację systemu ma zapisaną w swoim specjalnym pliku config.boot, a ponieważ zrobiliśmy właśnie coś, czego Vyatta sama w sobie nie rozumie, po restarcie routera stracimy nasza nową tablicę routingu oraz regułę. Na szczęście najnowsza wersja Vyatty 6.3 posiada specjalny skrypt przewidziany właśnie do umieszczenia w nim konfiguracji, która wykracza poza oficjalnie wspierane scenariusze. Plik ten to /config/scripts/vyatta-postconfig-bootup.script. Wystarczy, że umieścimy w nim powyższe polecenia jedno po drugim.

Na koniec muszę dodać, że podobny efekt można uzyskać też stosując wbudowany w Vyattę mechanizm WAN Load Balancing, niemniej jest to niestandardowy zestaw binarek opracowany przez zespół Vyatty (a więc tylko przez nich może być supportowany), na dodatek niepozbawiony wad - korzystaliśmy z niego kiedyś do dzielenia ruchu wychodzącego do Internetu na kilka łączy DSL i niestety bywało różnie... Lepiej moim zdaniem skorzystać tutaj z natywnego, linuksowego routingu, niż z narzędzia, które de facto stworzone zostało do równoważenia obciążenia, czyli czegoś zupełnie innego, niż chcemy w tym przypadku osiągnąć.