Dwa klienty OpenVPN na jednej bramie Linux: podziel politykę

Dwa demony OpenVPN mogą oba zgłosić udany tunel, podczas gdy brama wysyła każdego klienta przez ten sam. Nic w uścisku dłoni nie decyduje, którego tunelu używa klient; decyduje o tym jądro, pakiet po pakiecie, przechodząc przez reguły polityki, a potem przez tabelę, którą nazywa każda reguła. Patrząc tak, konfiguracja przestaje dotyczyć opcji OpenVPN i staje się macierzą routingu z dwoma właścicielami.

Decyduje jądro, nie demon

Przekazywany pakiet trafia na interfejs LAN, a kod routingu ocenia listę reguł w kolejności priorytetów. Pierwsza reguła, której selektor pasuje, nazywa tabelę, a trasy tej tabeli wybierają urządzenie wyjściowe. Jeśli w tabeli nie ma pasującej trasy, wyszukiwanie przechodzi do następnej reguły, i właśnie ten szczegół sprawia, że niedokończona konfiguracja zawodzi cicho, a nie głośno.

Proces tunelu nie ma nic do powiedzenia w tym przejściu. Tworzy interfejs i może instalować trasy, ale to, czy pakiet konkretnego klienta wejdzie do tego interfejsu, zależy wyłącznie od tabeli, do której go wysłano. Dlatego dwa tunele z identycznymi zaimportowanymi trasami konkurują, a ostatni zapisujący wygrywa dla wszystkich. To dlatego konfiguracja może wyglądać w plikach na zrównoważoną, a mimo to wysyłać wszystkich klientów przez jeden demon.

Daj każdej instancji jej własny zestaw zasobów

Zacznij od nazw, bo ponownie użyte nazwy to droga, na której dwie instancje przypadkowo zaczynają dzielić stan. Przydziel osobne urządzenia tunelu, osobne pliki konfiguracji, osobne dane logowania i osobne jednostki usług. Zapisz zewnętrzny punkt końcowy i adres tunelu każdej instancji w tej samej tabeli co macierz polityki, aby późniejsza zmiana miała jedno miejsce do zajrzenia.

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull trzyma trasy wypychane przez serwer poza tabelą lokalną, i dokładnie tego chcesz, gdy tabele polityki mają być jawne. To, czy dany serwer wypycha także opcję redirect-gateway i czy twoja wersja klienta obsługuje formę filtru, warto sprawdzić w podręczniku, a nie zakładać.

Napisz macierz: źródło, tabela, urządzenie

Dla każdej grupy klientów dodaj regułę, która wybiera tabelę według adresu źródłowego, a potem umieść zamierzoną drogę w tej tabeli:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

Tabela potrzebuje tras docelowych, które grupa powinna mieć, plus wszelkich lokalnych lub zarządczych wyjątków, które utrzymują bramę w użyciu. Tabela zawierająca tylko trasę domyślną to polityka pełnego tunelu dla tej grupy, co może być dokładnie słuszne, ale powinno być decyzją, a nie przeoczeniem.

Własny transport tunelu nie jest w grupie klientów

Zaszyfrowane pakiety każdego demona powstają na samej bramie i są adresowane do zewnętrznego peera. Reguła pasująca tylko do prefiksu źródła klienta zostawia te pakiety w spokoju, dlatego reguły ograniczone źródłem są bezpieczniejsze niż reguły pasujące do wszystkiego. Reguła bez selektora może przechwycić własny transport tunelu i odesłać go przez tunel, a wtedy połączenie zawodzi w sposób, który wygląda jak problem dostawcy.

Trzymaj lokalną sesję zarządzania i ścieżkę warstwy dolnej wyraźnie poza tabelami polityki. Zapisz te wyjątki obok macierzy; są częścią projektu, a nie obejściem, które trzeba odkryć na nowo podczas incydentu.

Wybór drogi jej nie zezwala

Zezwolenie na przekazywanie to druga decyzja podejmowana później na ścieżce. Reguła zapory, która akceptuje pakiety wychodzące przez drugi tunel, nie sprawia, że kod routingu go wybierze, a poprawna tabela nie daje zgody na przekazywanie. Oba muszą istnieć, a test, który dowodzi tylko jednego, wprowadzi cię w błąd co do drugiego. Kiedy jedna grupa działa, a druga nie, sprawdź te dwa kroki osobno, zamiast przepisywać tabele.

Tłumaczenie źródła to trzecia decyzja i powinno być ograniczone do grupy źródłowej i urządzenia tunelu, które naprawdę je niesie. Dodaj osobny łańcuch dla dwóch instancji, zamiast czyścić łańcuch postrouting, bo niepowiązane usługi mogą mieć tam wpisy, a czyszczenie usuwa je po cichu.

Co się dzieje, gdy jeden tunel padnie

Zdecyduj zachowanie przy awarii z góry. Gdy tabela tunelu traci swoją trasę, wyszukiwanie spada do następnej reguły, a ruch grupy płynie dalej przez drugi tunel lub zwykłe łącze w górę bez żadnego błędu. Jeśli to nie jest akceptowalne, dodaj regułę kończącą o niższym numerze priorytetu, która dla tego źródła zwraca wynik nieosiągalny, aby utrata była widoczna, a nie wchłonięta.

Wyślij nowe żądanie z każdej grupy źródłowej i zapisz cztery fakty: wybraną tabelę, urządzenie wyjściowe, przetłumaczone źródło i to, czy odpowiedź wróciła tą samą drogą. Potem wyłącz jeden tunel i powtórz. Dwa urządzenia TUN na liście interfejsów dowodzą, że oba demony wystartowały; nie mówią nic o tym, którego użył dany klient. Drugi przebieg, z jednym tunelem mniej, jest tym, który pokazuje, czy twoja reguła zapasowa robi to, co zamierzałeś.