Serwer i klient OpenVPN na jednym hoście: dlaczego klienci wypadają

Dodaj profil klienta do maszyny, na której już działa serwer VPN, a pierwszą ofiarą będzie dotychczasowa usługa. Nowy tunel może nigdy nie powstać albo wstać, gdy istniejący klienci serwera po cichu przestają dostawać odpowiedzi. Dwie kolizje dają oba wyniki: pula tuneli już używana oraz trasa domyślna instalowana przez nową połowę klienta, obejmująca całą tablicę. Żadna z nich nie generuje komunikatu błędu OpenVPN, dlatego awarię czyta się jako problem serwera.

Jedna maszyna, dwie role i dwie niezgodne odpowiedzi na to, dokąd mają trafiać odpowiedzi.

Ta sama pula, dwa serwery: który wygrywa

Każda instancja serwera potrzebuje własnej podsieci tunelu. Skopiowanie wiersza takiego jak server 10.8.0.0 255.255.255.0 do drugiej konfiguracji daje obu instancjom ten sam prefiks, a wynikiem jest albo odmowa startu, albo cicha rywalizacja, w której klienci jednego serwera dostają adresy, które drugi też uważa za swoje. Różne porty UDP i różne nazwy urządzeń nie pomagają, bo żadne z nich nie dotyka przestrzeni adresowej. Zmień drugą pulę i zmień ją wszędzie, gdzie trasy ją wymieniają.

Wypisz, co działa, zanim zaczniesz edytować: ip -4 addr show pokazuje urządzenia tuneli, ss -lunp pokazuje nasłuchujące procesy, a systemctl list-units wymienia nazwy jednostek. Jedno spojrzenie na adresy tuneli rozstrzyga, czy pule się nakładają.

Co profil klienta dodaje do tablicy

Połowa klienta zapisuje trasy zaraz po połączeniu. redirect-gateway def1 dzieli trasę domyślną na 0.0.0.0/1 plus 128.0.0.0/1, obie kierowane przez nowe urządzenie, wraz z trasą do hosta odległego serwera, celowo przypiętą do interfejsu fizycznego. To przypięcie istnieje po to, by tunel zachował ścieżkę dla własnego transportu. Wszystko inne, łącznie z odpowiedziami, które lokalny serwer winien jest swoim klientom, idzie teraz nową trasą domyślną i wychodzi przez łącze zdalne.

Druga kolizja nie jest więc zepsutym tunelem. To działający tunel w złym miejscu tablicy.

Trzy sposoby rozdzielenia ról

Najmniej inwazyjna poprawka trzyma trasę domyślną poza profilem klienta: route-nopull plus jawne wiersze route dla prefiksów zdalnych, dzięki czemu lokalna tablica zmienia się tylko tam, gdzie o to poproszono. Następnym krokiem jest reguła polityki zwalniająca lokalną podsieć tunelu, pozwalająca odpowiedziom do lokalnych klientów wychodzić interfejsem, którym przyszły, nawet gdy istnieje trasa domyślna. Najgruntowniejsze jest osobne namespace sieciowe dla roli klienta, które całkowicie usuwa współdzieloną tablicę i kosztuje drugi kontekst routingu w utrzymaniu.

Niezależnie od wybranej drogi wyjątek musi wskazywać lokalną podsieć tunelu, a nie LAN. Odpowiedź wysyłana przez lokalny serwer ma jako cel adres tunelu, więc wyjątek w kształcie LAN nigdy do niej nie pasuje.

Która z dwóch instancji jest winna

Zatrzymaj instancję klienta i ponownie przetestuj pierwotnych klientów. Natychmiastowe ustąpienie oznacza routing, nie serwer. Przywróć klienta i prześledź pojedynczą odpowiedź za pomocą ip route get, któremu podano zarówno adres źródłowy, jak i docelowy, co pokazuje ścieżkę, którą wybrałby kernel, a następnie obserwuj interfejs, którego pakiety naprawdę używają, za pomocą tcpdump -ni any port 1194. Plik stanu serwera, zapisywany co kilka sekund przez dyrektywę status, zawiera listę podłączonych klientów i liczniki bajtów w obu kierunkach.

Czytaj te liczniki jeden przeciw drugiemu. Ruch, który wychodzi i nigdy nie wraca, jest odpowiedzią routingu, a nie problemem z uściskiem dłoni.