Dlaczego trasa OpenVPN przegrywa z polityką XFRM strongSwan

Konkretna trasa OpenVPN nie nadpisuje polityki XFRM: przeczytaj trasę i selektory polityki, a następnie zawęź, zrób wyjątek lub przejdź na interfejs XFRM.

Pakiety mogą iść trasą OpenVPN i mimo to zostać przechwycone przez politykę IPsec, a ta kombinacja z każdego kąta wygląda jak błąd routingu, z wyjątkiem właściwego. Linux rozwiązuje trasę, a następnie konsultuje osobną bazę polityk bezpieczeństwa, więc bardziej szczegółowa trasa docelowa nie wypiera pasującej polityki XFRM. Widocznym objawem jest ruch, który opuszcza host i nigdy nie dociera, podczas gdy oba tunele zgłaszają się jako zdrowe. Trzy opcje to rozwiązują, a którą wybierzesz, zależy od tego, która z dwóch ścieżek ma przenosić ten prefiks.

Dwie decyzje, nie jedna

Wybór trasy odpowiada na wąskie pytanie: który następny skok i adres źródłowy mają nieść ten pakiet. Baza polityk bezpieczeństwa odpowiada na inne: czy ten pakiet wymaga ochrony IPsec i pod jakimi selektorami. Oba działają dla tego samego pakietu, i spełnienie pierwszego nic nie mówi o drugim. Dlatego zmiana metryki lub dodanie trasy statycznej może pozostawić objaw nietknięty.

Szeroki selektor IPsec jest zwykłą przyczyną. Polityka chroniąca 172.16.0.0/12 obejmuje także 172.20.8.0/24, do którego administrator może chcieć dotrzeć tunelem OpenVPN. Zamiar istnieje tylko w tabeli routingu, a baza polityk nigdy się o nim nie dowiedziała.

Traktuj to jako konflikt między dwiema skonfigurowanymi ścieżkami ochrony, a nie jako rywalizację dwóch metryk. Poprawka należy do komponentu, który został skonfigurowany z niewłaściwym zakresem.

Przeczytaj trasę, którą jądro naprawdę wybiera

Zacznij od wyszukiwania, którego dokonuje jądro, wraz z adresem źródłowym i każdą regułą polityki, która może skierować pakiet do innej tabeli. Trasa w tabeli głównej może nigdy nie zostać sprawdzona, jeśli wcześniejsza reguła wybierze inną tabelę, a dopasowanie najdłuższego prefiksu obowiązuje tylko w tabeli wybranej przez regułę.

ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15

Ostatnie polecenie jest tym, które się liczy, bo wypisuje wybraną trasę wraz z adresem źródłowym, którego użyłoby jądro. Porównaj ten wynik z selektorem, z którym pasuje polityka IPsec. Gdy trasa wskazuje interfejs OpenVPN, a polityka nadal pasuje do tej samej pary, odtworzyłeś konflikt bez zgadywania.

Trzymaj zrzuty wolne od niepowiązanych adresów, zanim trafią do zgłoszenia. Tabela routingu z hosta produkcyjnego niesie topologię wewnętrzną i tylko wiersze odpowiadające na pytanie warto wklejać.

Przeczytaj także politykę, która obowiązuje

Lista polityk pokazuje kierunek, selektory i szablon, który decyduje, co dzieje się z pasującym pakietem. Czytaj najpierw kierunek wychodzący, potem stronę wejściową dla ruchu powrotnego, bo wyjątek jednokierunkowy daje połączenie, które zaczyna się i nigdy nie kończy.

ip -s xfrm policy
swanctl --list-sas

Porównaj selektory z listy z prefiksami wynegocjowanymi przez połączenie. Wyłączenie instalacji tras w strongSwan nie usuwa tych polityk, a zmiana metryki nie zmienia tego, którą parę źródło-cel chroni polityka. Te dwie pozorne poprawki warto wykluczyć wcześnie, bo ludzie próbują ich najpierw.

Jeśli lista nie zawiera polityki dla oczekiwanego prefiksu, problem jest gdzie indziej i tabela routingu prawdopodobnie mówi prawdę. Jeśli zawiera szerszą politykę obejmującą ten prefiks, znalazłeś przechwycenie.

Trzy opcje, gdy obie ścieżki są uzasadnione

Zawężenie selektora IPsec to najczystsza opcja, gdy szeroki prefiks był wygodą, a nie wymogiem. Zmniejszenie selektora ruchu zdalnego do podsieci, które naprawdę należą za IPsec, usuwa konflikt dla każdego hosta naraz, a kosztuje ponowne wynegocjowanie kluczy, nie nowy komponent.

Wyjątek passthrough to opcja chirurgiczna, gdy szeroki selektor musi zostać. strongSwan obsługuje osobne połączenie, którego child używa trybu pass, co mówi jądru, że pasujący ruch nie może być przetwarzany przez IPsec. Zdalny adres loopback chroni to połączenie przed wybraniem dla partnerów przychodzących, a selektory muszą opisywać rzeczywistą autoryzowaną parę, a nie wszystko.

connections {
    openvpn-exception {
        remote_addrs = 127.0.0.1
        children {
            openvpn-exception {
                local_ts = 10.44.7.0/24
                remote_ts = 172.20.8.0/24
                mode = pass
                start_action = trap
            }
        }
    }
}

Przykłady konfiguracji strongSwan dokumentują ten typ polityki i konwencję partnera loopback. Trzecią opcją jest projekt oparty na routingu z interfejsami XFRM, który wiąże politykę z ruchem routowanym przez nazwany interfejs, a nie z globalnym selektorem. To migracja, a nie dostrojenie, i ruch nadal musi spełniać wynegocjowane selektory.

OptionUse it whenCost
Narrow the selectorThe broad prefix was convenienceA rekey and a policy review
Passthrough childThe broad selector must stayOne exception per intended pair
XFRM interfacePolicy should follow routingA design migration

Udowodnij wyjątek, nie osłabiając reszty

Po załadowaniu zmiany przetestuj wyjątek i zwykły cel, który musi pozostać chroniony. Sprawdź oba kierunki, potem opuść tunel OpenVPN i potwierdź, co dzieje się z ruchem objętym wyjątkiem. Wyjątek, który po cichu wysyła ten prefiks otwarcie, gdy tunel jest wyłączony, jest decyzją o polityce, którą należy podjąć świadomie, a nie odkryć podczas incydentu.

Zapisz, który prefiks używa której ścieżki i dlaczego. Inaczej następny inżynier, który zobaczy szeroki selektor, ponownie otworzy to samo dochodzenie, a odpowiedź będzie siedzieć w komunikacie commit, którego nikt nie czyta.

Powiązane artykuły