Zagnieżdżony VPN: który tunel przenosi połączenie zewnętrzne?

Dwa klienty VPN działające jednocześnie nie tworzą zagnieżdżonego tunelu; tworzą dwa tunele i spór o routing. Zagnieżdżony tunel istnieje wtedy, gdy połączenie wewnętrznego klienta z jego własnym serwerem jest samo przenoszone przez tunel zewnętrzny, a to układ, który buduje się celowo. Jeśli wyjdzie dobrze, serwer wewnętrzny widzi adres serwera zewnętrznego; jeśli źle, jeden klient po cichu łączy się ponownie wokół drugiego. Trzy warunki decydują, czy zagnieżdżenie jest prawdziwe czy przypadkowe.

Trzy warunki decydują o zagnieżdżeniu

Pierwszy to który punkt końcowy potrzebuje której trasy. Nazwij adres serwera wewnętrznego, nazwij adres serwera zewnętrznego i wyraźnie stwierdź, że serwer wewnętrzny jest osiągalny tylko przez tunel zewnętrzny. Wszystko inne wynika z tego zdania, łącznie z tym, które trasy należą do której tabeli.

Drugi to czy widzisz trasę na każdej warstwie. Jeśli nie możesz zapytać jądra, której trasy użyłby konkretny cel, wnioskujesz łańcuch z końcowego IP wyjścia, a to jest właśnie dowód, który nie potrafi odróżnić zagnieżdżenia od przypadku.

Trzeci to co się dzieje, gdy tunel zewnętrzny padnie. Tunel wewnętrzny może zatrzymać się razem z nim, połączyć ponownie przez zwykłą sieć albo pozostać zablokowany, aż trasa zewnętrzna wróci, i wszystkie trzy są obronnymi politykami. To nie ta sama polityka, a domyślnym zachowaniem większości klientów jest druga. Klient, który ponownie łączy swój punkt końcowy przez sieć fizyczną, pokazując przy tym zdrowe połączenie, to najczęstszy sposób, w jaki zamierzony łańcuch po cichu staje się dwoma niepowiązanymi tunelami.

Warunek pierwszy: który punkt końcowy potrzebuje której trasy

ip route get 203.0.113.10 odpowiada na to pytanie wprost: wypisuje trasę, adres źródłowy i interfejs, którego jądro użyłoby dla tego celu w tej chwili.

Uruchom to dla serwera wewnętrznego przed startem wewnętrznego klienta i jeszcze raz potem, a następnie porównaj. Jeśli odpowiedź zmienia się z interfejsu fizycznego na interfejs tunelu zewnętrznego, zagnieżdżenie jest w tym momencie prawdziwe. Jeśli się nie zmienia, wewnętrzny klient łączy się bezpośrednio, cokolwiek mówi panel. Powtórz dla adresu serwera zewnętrznego, który nadal musi być rozwiązywany przez interfejs fizyczny, bo trasa przechwytująca oba punkty końcowe rekurencyjnie to awaria, która całkowicie odcina maszynę od sieci.

Warunek drugi: zbadaj trasę na każdej warstwie

Wybór trasy to więcej niż główna tabela na nowoczesnym kliencie. Reguły polityki mogą wysyłać oznaczone pakiety do innej tabeli, klient może przypiąć swój socket do interfejsu, a kontener lub przestrzeń nazw ma własne tabele. ip rule i ip route show table all to sposób, by dowiedzieć się, który z tych mechanizmów działa.

Klient, który ustawia SO_MARK na własnym sockecie albo jest skonfigurowany do przypisania się do konkretnego urządzenia, omija domyślną trasę, którą sądziłeś, że ustawiłeś. To funkcja, a nie błąd, i oznacza, że jedynym wiarygodnym sprawdzeniem jest to uruchamiane w tej samej przestrzeni nazw co klient. Jeśli klienci działają w kontenerach, uruchamiaj sprawdzenia w tych kontenerach, a nie na hoście.

Warunek trzeci: co się dzieje, gdy tunel zewnętrzny padnie

Zachowanie przy awarii wymaga decyzji, a nie wartości domyślnej. Zapisz, co ma się stać z tunelem wewnętrznym, gdy zniknie zewnętrzny, a potem spraw, by klienci tak robili.

Opcje są konkretne. Zatrzymanie wewnętrznego klienta, gdy znika trasa zewnętrzna, daje czysty łańcuch i oczywistą awarię. Pozwolenie mu na bezpośrednie ponowne połączenie daje dostępność i po cichu usuwa właściwość, dla której zbudowano łańcuch. Blokowanie do powrotu trasy zewnętrznej jest najsurowsze i najbardziej uciążliwe w eksploatacji, bo każde drgnięcie tunelu zewnętrznego staje się widocznym incydentem.

Przetestuj wszystkie trzy na nieszkodliwym ruchu i celowej awarii tunelu zewnętrznego, bo czytanie konfiguracji nie powie ci, którą masz. Zabij tunel zewnętrzny, obserwuj, co robi wewnętrzny klient, i sprawdź trasę ponownie, gdy jest wyłączony. Potem przywróć tunel zewnętrzny i potwierdź, że łańcuch się odtwarza, zamiast zostawiać wewnętrznego klienta na bezpośredniej trasie, którą wybrał w międzyczasie.

Czego łańcuch ci nie daje

Dodatkowe warstwy dodają punkty końcowe, klucze i tryby awarii; nie dodają żadnej gwarancji anonimowości i nie sprawiają, że zewnętrzny operator nie może zobaczyć, iż tunel istnieje. Każde twierdzenie o tym, przed czym chroni zagnieżdżenie, musi wskazać obserwatora, przed którym chroni.

Wynikiem jest krótki dokument, a nie działające połączenie: który punkt końcowy używa której trasy, co się dzieje przy awarii zewnętrznej i trzy polecenia pokazujące bieżący stan. Dokumentacja strongSwan o przekazywaniu to przydatne źródło o tym, jak ruch tunelu jest przekazywany między interfejsami na hoście Linux. Uruchamiaj sprawdzenia ponownie po każdej aktualizacji klienta, bo ustawienia domyślne, które wytworzyły twój łańcuch, nie są umową. Zagnieżdżony tunel, którego nie możesz zbadać, to pogłoska z lampką stanu.