Serwer czy klient: która jednostka OpenVPN na Pi o podwójnej roli

Na Pi działają dwa procesy OpenVPN, które jednocześnie przyjmują użytkowników mobilnych i docierają do dostawcy nadrzędnego, a poza sprzętem nie dzielą prawie niczego. Jeden nasłuchuje tuneli przychodzących, drugi łączy się na zewnątrz. Każdy czyta swój własny katalog i każdy ma swój własny tryb awarii. Ponowne uruchomienie niewłaściwego jest najczęstszym sposobem, w jaki poprawka klienta zamiast tego wytrąca słuchacza.

Dopasuj nazwę jednostki do katalogu, który wczytuje

Upstream 2.6 dostarcza dwie jednostki szablonowe, [email protected] i [email protected]. Szablon serwera startuje w /etc/openvpn/server i stamtąd wczytuje %i.conf. Szablon klienta startuje w /etc/openvpn/client. Instancja o nazwie roaming może istnieć w obu miejscach jednocześnie, jako serwer i jako klient, z dwiema niepowiązanymi konfiguracjami i bez żadnego związku między nimi poza łańcuchem.

Pytaj systemd, a nie systemu plików, ponieważ pakujący dodają dodatkowe pliki, które mogą zmienić katalog roboczy lub argumenty otrzymywane przez binarkę.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

Pierwsze polecenie wymienia każdą utworzoną jednostkę, w tym te, które zawiodły i pozostały wczytane. Drugie wypisuje plik jednostki wraz z każdym nadpisaniem. Trzecie jest najszybszym sposobem, by zobaczyć dwa fakty rozstrzygające pytanie: katalog, w którym startuje proces, oraz ścieżkę konfiguracji, którą mu podano.

Decyduj po kierunku pakietów, nie po nazwie interfejsu

Instancja serwera posiada gniazdo nasłuchujące i przyjmuje połączenia. Jej szyfrowany transport to lokalne wejście i lokalne wyjście na Pi, natomiast ruch, który przekazuje dla użytkowników, podąża ścieżką przekazywania i odpowiada innemu zestawowi reguł. Instancja klienta nie ma w tym sensie słuchacza: łączy się z peerem, więc jej szyfrowany transport to lokalne wyjście w stronę warstwy niższej.

Ta różnica mówi, gdzie należy reguła. Reguła pasująca do interfejsu wewnątrz łańcucha przekazywania pozwala tylko na ruch, który routing już wybrał; nigdy nie wybiera trasy. Kiedy pakiety użytkownika mobilnego wychodzą złą drogą, łańcuchem do sprawdzenia jest forward, a nie output.

Spójrz na gniazda, zanim zaczniesz teoretyzować. Serwer związany z udp/1194 pokazuje gniazdo nasłuchujące. Klient pokazuje powiązanie z adresem dostawcy i nic, co by nasłuchiwało.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

Trasa domyślna jednej instancji może przechwycić odpowiedzi drugiej

redirect-gateway wypychany przez klienta nadrzędnego instaluje trasę domyślną, która konkuruje ze wszystkim innym na maszynie, w tym z odpowiedziami, które serwer wysyła użytkownikom mobilnym. OpenVPN robi wyjątek dla własnego adresu peera, aby tunel pozostał osiągalny, ale ten wyjątek nic nie mówi o telefonie w sieci hotelowej.

Objaw jest zwykle asymetryczny. Uścisk dłoni się kończy, klient zgłasza połączenie, a ruch ginie po pierwszym pakiecie odpowiedzi. Routing polityki oparty na źródle albo znacznik pakietu ustawiony na instancji serwera za pomocą --mark trzyma oba strumienie osobno; żadne z nich samo w sobie nie jest pełnym zestawem reguł, a oba potrzebują prawidłowych tras w tabeli, którą wybierają.

Testuj decyzję lokalną, a nie stan tunelu, ponieważ jądro wybiera źródło i interfejs, zanim OpenVPN zobaczy pakiet.

ip route get 203.0.113.44
ip rule show

Uruchom ponownie jedną rolę i udowodnij, że druga przetrwała

Kolejność ma znaczenie, gdy obie role zależą od tej samej warstwy niższej. Uruchom najpierw klienta, jeśli trasa nadrzędna musi istnieć, zanim będzie można przekazywać ruch użytkowników, a uruchom najpierw serwer, gdy zmieniasz tylko jego słuchacza lub jego pulę. W każdym razie potwierdź potem obie jednostki, ponieważ nieudane uruchomienie może zostawić drugą rolę działającą na nieaktualnym stanie.

Zapisz warunek zatrzymania przed zmianą: czy utrata tunelu nadrzędnego blokuje użytkowników mobilnych, czy spada z powrotem na własny uplink Pi? DNS i IPv6 też potrzebują jasnej odpowiedzi, ponieważ wypchnięty resolver często żyje dłużej niż trasa, która uczyniła go użytecznym.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

Zaakceptuj zmianę tylko wtedy, gdy trzy rzeczy zachodzą jednocześnie: nowe połączenie przychodzące się kończy, przekazana aplikacja dociera do celu przez zamierzone wyjście, a oba procesy nadal zgłaszają oczekiwanego peera. Jeśli jedna z trzech zawiedzie, zmieniłeś niewłaściwą instancję albo niewłaściwą trasę, a następnym krokiem jest ponowne przeczytanie jednostki, a nie restartowanie czegokolwiek innego.