Dwa tunele OpenVPN na jednym hoście Linux: do kogo należy trasa?

Dwa profile są połączone, a jeden z nich po cichu przenosi ruch przeznaczony dla drugiego. Host Linux może uruchomić oba OpenVPN klienty jednocześnie bez trudu. Czego nie potrafi, to zdecydować za ciebie, który proces może rościć sobie który prefiks. Ta decyzja musi zapaść, zanim wstanie drugi tunel, a nie po tym, jak zasób przestanie odpowiadać.

Zacznij od pracy, którą musi wykonać drugie łącze

Biuro dostępne przez jeden profil i laboratorium dostępne przez drugi wymagają obu tuneli w górze i tego, by żaden nie rościł sobie wszystkiego. Jedna uparta aplikacja, która musi wyjść przez drugi profil, potrzebuje reguły polityki, a nie drugiej trasy domyślnej. Łącze zapasowe potrzebuje tylko jednego działającego tunelu naraz, więc zapas nie powinien startować razem z maszyną.

To trzy różne konfiguracje i mylą się, bo wszystkie trzy zaczynają się tak samo: drugi profil i udane połączenie. Najpierw zapisz zamierzony układ, potem konfiguruj w jego stronę. Jedno zdanie o zamiarze oszczędza godzinę przechwytywania pakietów.

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

Pierwsze polecenie wyświetla działające instancje, w tym te uruchomione ręcznie poza menedżerem. Drugie wypisuje bieżące roszczenie domyślnej trasy, a to stan, który później będziesz musiał wyjaśnić.

Nakładające się pule psują się przed routingiem

Dwa serwery chętnie przydzielą adresy z tej samej puli 10.8.0.0/24. Klient trzyma wtedy dwa interfejsy w jednym prefiksie i nic nie mówi, która destinacja należy do którego, a wynikowe zachowanie wygląda jak awaria routingu, ale w rzeczywistości jest awarią numeracji. Przenumerowanie puli kosztuje jedną zmianę konfiguracji; każde późniejsze obejście routingu kosztuje weekend. Sprawdź pulę, zanim dodasz dla niej trasę.

Spójrz też na lokalną sieć LAN. Domowa sieć LAN o numerze 192.168.1.0/24, którą jeden tunel również udostępnia, daje tę samą niejednoznaczność, a objawem jest nazwa hosta, która się rozwiązuje, podczas gdy połączenie nigdy się nie kończy. Wygląda to jak awaria rozwiązywania nazw, dopóki nie wypiszesz tras.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

Porównaj oba wyniki z obiema konfiguracjami serwera, zanim dotkniesz klienta. Jeśli prefiksy się nakładają, zatrzymaj się i przenumeruj, bo żadna liczba restartów ich nie rozdzieli.

Daj każdemu profilowi własną jednostkę, a każdemu prefiksowi właściciela

Każdy profil ma własną nazwę instancji i własny plik konfiguracyjny, więc instancja o nazwie office ładuje office.conf, a ta o nazwie lab ładuje lab.conf. Potwierdź to mapowanie przez menedżera usług, zamiast ufać listingowi katalogu, ponieważ drop-in może zmienić, który plik jest ładowany. Błędne mapowanie oznacza, że dostrajasz profil, który nie działa.

Potem ustal, kto instaluje trasy. Gdy serwery wypychają niezgodne zestawy, albo odrzuć wypychanie i sam wypisz prefiksy, albo pozwól jednemu profilowi zachować domyślną trasę, a drugi prowadź regułami polityki. Dwa procesy, które oba instalują trasę domyślną, kończą z cichym zwycięzcą i bez pisemnego zapisu decyzji.

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

Pierwsze pokazuje jednostkę z każdym nadpisaniem, które zmienia jej argumenty. Drugie pokazuje, czy profil w ogóle akceptuje wypychane trasy, i to jest przełącznik, który decyduje o wszystkim dalej.

Znaczniki utrzymują odpowiedzi na interfejsie, z którego przyszły

Gdy każdy tunel obsługuje inne źródła, odpowiedź może wyjść niewłaściwym łączem i połączenie umiera po pierwszym pakiecie. Wzorzec, który się trzyma, to oznaczanie przychodzących pakietów według interfejsu wejściowego, przywracanie tego znacznika na odpowiedzi i danie każdemu znacznikowi tabeli z własną bramą domyślną.

Luźne filtrowanie odwrotnej ścieżki zwykle trzeba poluzować dla dotkniętych interfejsów, ponieważ odpowiedź legalnie przychodzi łączem, którego główna tabela nigdy by nie wybrała. Trzymaj znaczniki wąskie, aby nigdy nie przechwytywały własnego zaszyfrowanego ruchu tuneli, co wysłałoby tunel przez niego samego.

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

Przeczytaj istniejące reguły, zanim dodasz kolejną. Zduplikowane priorytety i zapomniane tabele to zwykły powód, dla którego polityka znaczników wydaje się w ogóle nie działać.

Udowodnij izolację, zatrzymując jedno łącze

Przy obu tunelach w górze zapisz adres każdego interfejsu, trasę do jednego hosta za każdym tunelem i ścieżkę, którą obiera niepowiązany cel. Zapytaj jądro o wyszukiwanie, zamiast czytać jedną tabelę, ponieważ jedna tabela nigdy nie pokazuje ostatecznej decyzji.

Potem zatrzymaj jedną instancję i obserwuj, jak jej interfejs i trasy znikają, podczas gdy druga działa dalej. Przerwa w ocalałej oznacza, że obie wciąż dzielą nazwę urządzenia, trasę lub regułę firewalla, której nikt nie rozdzielił.

Przywróć zatrzymany profil i powtórz te same kontrole. Gdy tunel przeżywa tylko pierwszy start po restarcie, patrzysz na defekt cyklu życia, a nie na projekt routingu.