Dlaczego klienci OpenVPN nie trafiają w selektory IPsec bramy

Wyślij ping z bramy do hosta za zdalnym tunelem IPsec, a odpowie czysto, więc tunel wygląda zdrowo, a zgłoszenie idzie dalej. Potem połączony klient próbuje tego samego hosta i nic nie dostaje. Ten ping nigdy nie był dowodem dla przepływu klienta, bo wyszedł z własnym adresem źródłowym bramy i pasował do innego selektora IPsec. Zrozumienie, dlaczego te dwa przypadki się rozchodzą, to większość naprawy.

Ping z bramy testuje przepływ, którego twój klient nigdy nie używa

Adres źródłowy decyduje, która polityka obowiązuje. Pakiet utworzony na bramie wychodzi z adresem z jej lokalnej sieci LAN lub z punktu końcowego tunelu, a polityka, która do niego pasuje, została napisana dokładnie dla tego przypadku. Pakiet klienta przychodzi na interfejs OpenVPN z adresem z puli klientów, co jest zupełnie innym selektorem.

Dlatego awaria wygląda jak problem routingu, choć w rzeczywistości jest problemem zakresu polityki. Osiągalność z bramy dowodzi, że peer działa i że propozycje zostały wynegocjowane, i nie dowodzi niczego o tym, czy pula jest chroniona.

Wypchnij prefiks zdalny, którego aplikacja naprawdę potrzebuje

Weź ilustracyjną parę 10.8.0.0/24 dla połączonych klientów i 172.30.239.0/25 dla chronionej sieci zdalnej. Klient potrzebuje trasy do tego drugiego prefiksu, nie do sieci LAN bramy i nie do innego adresu tunelu. Trasa wypchnięta do puli jest tym, co w ogóle skłania klienta do przekazania tego ruchu bramie. Bez niej pakiet nigdy nie dociera do decyzji polityki, którą debugujesz.

Na serwerze Community, który przyjmuje wypychane trasy, dyrektywa przyjmuje prawdziwą maskę: push "route 172.30.239.0 255.255.255.128". Access Server konfiguruje ten sam cel przez ustawienia sieci prywatnej lub reguł dostępu zainstalowanej wersji, świadomie wybierając tryb routowany albo tłumaczony. Edytowanie wygenerowanych łańcuchów zapory zamiast konfiguracji właściciela to droga, na której działająca instalacja staje się niemożliwa do odtworzenia.

Po połączeniu czytaj tablicę routingu klienta, a nie intencję serwera. Trasa obejmująca tylko pulę oznacza, że wypchnięcie nigdy nie dotarło, a trasa domyślna przez tunel jest szersza niż to wymaganie i zaskoczy cię później. Sprawdź maskę i prefiks, bo /25 wypchnięty jako /24 wysyła ruch sąsiednich adresów ścieżką, która nie może go unieść. Następnie potwierdź, że klient wybrał interfejs tunelu dla tego celu.

Spraw, by selektory obejmowały pulę klientów

Dla dostępu routowanego, który zachowuje adresy klientów, polityka IPsec musi chronić ruch między pulą a prefiksem zdalnym. Selektory napisane dla własnej sieci LAN bramy przepuszczają ping i odrzucają żądanie klienta, i to jest dokładnie ta asymetria, która rozpoczęła to dochodzenie.

Sprawdź wynegocjowaną politykę oraz skonfigurowane propozycje, na przykład za pomocą ipsec statusall na strongSwan lub równoważnego polecenia stanu dla twojej implementacji. W IPsec opartym na politykach zwykła trasa może wskazywać na interfejs fizyczny, podczas gdy pasujący ruch nadal jest szyfrowany, więc brak urządzenia tunelowego niczego nie dowodzi. Porównaj pary selektorów z pulą i prefiksem, które zapisałeś.

Ogólny NAT źródłowy na bramie również może zepsuć dopasowanie. Jeśli reguła masquerade przepisuje źródło klienta przed sprawdzeniem polityki, pakiet nie przypomina już selektora, który napisałeś. To jeden z powodów, dla których szeroka reguła masquerade jest złą naprawą drugiego VPN: zmienia, która polityka obowiązuje i który adres rejestruje strona zdalna. Wyłącz ruch, który zamierzasz routować, albo świadomie go przetłumacz i zaktualizuj selektory.

Wybierz routing albo tłumaczenie świadomie

Routing utrzymuje adres klienta widocznym dla strony zdalnej, więc zdalne logi i reguły według źródła pozostają sensowne, i wymaga, by zdalna brama znała drogę powrotną do puli. Tłumaczenie ukrywa pulę za jednym adresem, co usuwa problem trasy powrotnej i niszczy tożsamość każdego klienta.

Wybierz jeden projekt i zapisz go, bo oba potrzebują różnych selektorów i innej kolejności zapory. Na wpół zastosowany masquerade ląduje pomiędzy nimi i nie zadowala żadnego. Zapisany wybór to także to, co pozwala następnemu inżynierowi odróżnić błąd od świadomej decyzji.

Zamknij pętlę na przekazywaniu i odpowiedzi

Brama musi przekazywać protokół i cel, które masz na myśli, co oznacza włączone przekazywanie IP i łańcuch przekazywania, który dopuszcza parę. Następnie strona zdalna musi odsyłać odpowiedzi ścieżką IPsec, i to jest decyzja routingu na ich bramie, a nie na twojej. Obie połowy to zwykła konfiguracja i obie łatwo zostawić niedokończone. Testuj je osobno, żeby brakująca reguła przekazywania nie została wzięta za zepsuty tunel.

Zweryfikuj jednym prawdziwym żądaniem od klienta do aplikacji, obserwując, jak przechodzi przez interfejs OpenVPN, decyzję IPsec i zdalny host. Obejrzyj odpowiedź jako osobną obserwację, bo żądanie, które dociera, i odpowiedź, która nigdy nie wraca, wyglądają tak samo z miejsca klienta. Jedno prześledzone żądanie jest warte więcej niż dowolna liczba pingów z bramy.

Trzymaj autoryzację celu wąską podczas testów i potwierdź, że klient bez reguły nie może dotrzeć do usługi. Zainstalowana trasa plus ustanowiona asocjacja to nie to samo co przyznany dostęp.