Pełny tunel w strongSwan wymaga 0.0.0.0/0 po obu stronach

Pełny tunel wymaga 0.0.0.0/0 jako remote_ts klienta i local_ts bramy, a także przekazywania, NAT i trasy powrotnej. Sprawdź wszystkie cztery.

Połączenie strongSwan działające dla jednej prywatnej podsieci nie będzie przenosić ruchu internetowego tylko dlatego, że ktoś edytował jedną linię. Pełny tunel to umowa między dwiema stronami co do tego, które adresy chroni child SA, a każda strona nazywa drugą względem siebie. Ustaw jedną stronę dobrze, a drugą źle, a child SA albo nie wstanie, albo wstanie węższa niż zamierzano. Pięć kontroli poniżej podąża za tą umową od klienta, przez bramę, aż do internetu.

Najpierw sprawdź selektor klienta

Klient opisuje to, co chce chronić po drugiej stronie, jako remote_ts, a wszystko, co wysyła, pochodzi z jego własnego przydzielonego adresu. Dla ruchu internetowego ta wartość musi obejmować miejsca docelowe, do których użytkownik faktycznie dotrze, co w praktyce oznacza całą przestrzeń IPv4. Klient, który nadal wymienia jedną podsieć, prosi o tunel dzielony, niezależnie od nazwy profilu w interfejsie. Strona źródłowa to zwykle dynamic, ponieważ adres jest przydzielany przy połączeniu. Stałe źródło zapisane tam psuje się, gdy tylko zmieni się pula adresów.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

Ten fragment nie jest kompletnym plikiem połączenia i zakłada, że uwierzytelnianie, tożsamości i pula adresów wirtualnych są już skonfigurowane. Selektor źródła klienta i adres przydzielany przez serwer nadal muszą się zgadzać, inaczej child SA wstanie z zakresem, którego żadna ze stron nie oczekiwała. Załaduj go poleceniem swanctl --load-all i przeczytaj wynik, zanim uznasz sukces. Plik, który się parsuje, nadal może zostać odrzucony z powodu selektora, który nie pokrywa się z propozycją drugiej strony.

Sprawdź selektor bramy po jej własnej stronie

Brama czyta to samo pojęcie z przeciwnego kierunku. Miejsca docelowe internetu są lokalne dla bramy, więc jej local_ts jest szeroki, a remote_ts opisuje pulę klientów. To odwrócenie jest najczęstszym błędem w konfiguracji pełnego tunelu i przechodzi przegląd, ponieważ obie linie z osobna wyglądają wiarygodnie.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

Skopiowanie fragmentu klienta do pliku bramy daje parę selektorów, która nie opisuje niczego użytecznego, ponieważ obie strony rościłyby sobie tę samą rolę. Przewodnik strongSwan po przekazywaniu wprost dokumentuje parowanie klienta i bramy, i warto go czytać obok pliku połączenia, a nie po awarii. Plik bramy potrzebuje też definicji puli, do której odwołuje się remote_ts. Selektor wskazujący nieistniejącą pulę ładuje się bez skargi i zawodzi przy połączeniu.

Starszy ipsec.conf używa ról lewej i prawej z różnymi kluczami, a linia rightsubnet nie jest bezpośrednim zamiennikiem wartości swanctl. Trzymaj obie składnie w osobnych plikach zamiast wklejać jedną do drugiej. Mieszanie ich w jednym katalogu to sposób, w jaki działające połączenie po restarcie cicho wraca do poprzedniego stanu.

Sprawdź wynegocjowany child SA, nie plik

Zapisana konfiguracja dowodzi zamiaru i niczego więcej. Druga strona może zawęzić to, o co proszono, a istniejący child SA nie jest zastępowany tylko dlatego, że plik pod nim się zmienił. Potwierdź, co jest naprawdę zainstalowane, zanim zmienisz cokolwiek innego.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

Pierwsze polecenie pokazuje, co załadował demon, drugie pokazuje ustanowione child SA, a trzecie polityki, które zastosuje jądro. Jeśli plik mówi 0.0.0.0/0, a lista pokazuje jedną podsieć, negocjacja zawęziła zakres i ponowne czytanie pliku tego nie wyjaśni. Zakończ child, uruchom ją ponownie i porównaj ponownie wszystkie trzy wyniki. Child, która wraca z tym samym wąskim zakresem, jest zawężana przez drugą stronę, a nie przez lokalny plik, i to jest rozmowa z drugim administratorem, a nie lokalna zmiana.

Czytaj oba kierunki na liście polityk, ponieważ tunel, który instaluje jeden kierunek, a nie drugi, to problem routingu w kostiumie konfiguracji. Polityki w przód i w tył powinny nazywać tę samą parę selektorów w odbiciu lustrzanym, a brakujące lustro to defekt demona lub propozycji, a nie tekstu selektora.

Sprawdź przekazywanie i trasę powrotną

Selektor wpuszcza ruch do bramy, ale nie sprawia, że brama routuje ten ruch dalej. Przekazywanie musi być włączone, zapora musi przepuścić strumień, a odpowiedź musi znaleźć drogę powrotną do puli klientów. To trzy osobne wymagania i każde zawodzi z innym objawem. Brakująca reguła przekazywania zachowuje się jak czarna dziura, a brakująca trasa powrotna jak tunel jednokierunkowy.

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

Prywatne adresy klientów zwykle wymagają świadomego tłumaczenia źródła, zanim opuszczą interfejs publiczny, a jawnie trasowane przydzielenie wymaga innego podejścia. Jeśli NAT jest w grze, zachowaj wyjątki obsługiwane przez implementację, aby ruch, który polityka bezpieczeństwa powinna sprawdzić, nie został przetłumaczony z pominięciem jej. Szeroka reguła masquerade skopiowana z innej bramy zmienia znacznie więcej przepływów, niż zamierzał jej autor. Napisz regułę tylko dla puli klientów i zostaw komentarz wyjaśniający, dlaczego istnieje.

Na kliencie potwierdź trasy zainstalowane przez backend, a nie trasy, które założyłeś. Menedżer z wyłączoną instalacją tras potrzebuje ręcznie utrzymywanego projektu routingu, a ten projekt trzeba aktualizować przy każdej zmianie tunelu. Sprawdź tablicę routingu po ponownym połączeniu, nie tylko po świeżym starcie.

Sprawdź, czego tunel nadal nie obejmuje

Para selektorów obejmuje IPv4 i nic więcej. IPv6, DNS i każda polityka na poziomie aplikacji to osobne decyzje, które szeroki selektor IPv4 po cichu ignoruje. Tunel przenoszący każdy pakiet IPv4 nadal może ujawniać każde wyszukiwanie nazwy.

Wskaż wyraźnie zamierzoną ścieżkę DNS, ponieważ pełny tunel, który nadal rozwiązuje nazwy przez lokalny resolver, ujawnia zapytania poza tunelem i psuje nazwy prywatne. Jeśli klientowi przydzielono adres IPv6, ta rodzina adresów wymaga takiego samego traktowania, inaczej host wybierze ścieżkę, której tunel nie chroni. Testuj nazwą, na którą może odpowiedzieć tylko strona prywatna, a publiczną odpowiedź traktuj jako wyciek.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Potwierdź łańcuch tymi dwoma poleceniami oraz wynegocjowanymi selektorami z listy powyżej. Jeśli traceroute pokazuje lokalny router jako pierwszy skok, ruch nie korzysta z tunelu, cokolwiek twierdzą selektory. Dostęp do internetu jest pełny tylko wtedy, gdy wybrany ruch jest dopuszczony, przekazany i zwrócony przez zaprojektowaną bramę. Znalezienie 0.0.0.0/0 w profilu to początek tego łańcucha, a nie jego dowód.

Powiązane artykuły