Co persist-tun i persist-key naprawdę przeżywają w OpenVPN

Zatrzymanie usługi usuwa interfejs nawet przy ustawionym persist-tun. To opcja działająca zgodnie z dokumentacją, a nie awaria. Opcja opisuje jedną ścieżkę restartu wewnątrz działającego procesu, a systemctl stop nie jest tą ścieżką.

Przeczytaj obie nazwy razem, a projekt staje się jasny. Jedna trzyma deskryptor, druga trzyma materiał klucza, i obie istnieją z powodu tego, co dzieje się po zrzuceniu uprawnień.

Dwa zasoby i restart, do którego należą

OpenVPN sygnalizuje własny restart w dwóch zwykłych sytuacjach. Jawne SIGUSR1 to robi, a ping-restart wywołane przez martwego partnera robi to samo. Oba pozostawiają proces żywym i ponownie wykonują konfigurację połączenia, i właśnie tam opcje zyskują swoje miejsce.

Tylko wiersz miękkiego restartu jest tym, co zmieniają te dwie opcje, a praca, którą pomijają, jest drogą częścią na zajętym łączu. Ponowne otwarcie urządzenia zrywa przypisane do niego adresy i trasy, a ich odbudowa może zgubić pakiety, które były w drodze, gdy restart się zaczął. Zatrzymanie niszczy te same obiekty bez żadnej opcji ich zachowania.

Dlaczego te opcje w ogóle istnieją

Utwardzony serwer OpenVPN zwykle startuje jako root, otwiera swoje klucze i swoje urządzenie, a następnie przechodzi na użytkownika bez uprawnień. Po tym przejściu niektóre operacje po prostu znikają. Odczyt pliku klucza w trybie 0600, utworzenie interfejsu sieciowego lub zmiana tras mogą zostać odrzucone.

Bez opcji persist partner, który milczy wystarczająco długo, by wywołać ping-restart, wymusiłby dokładnie te operacje. Ponowne połączenie nie powiodłoby się, mimo że nic w konfiguracji się nie zmieniło. Proces wyglądałby tak, jakby umierał bez powodu, a dziennik pokazałby błąd uprawnień zamiast błędu sieci.

Z nimi miękki restart ponownie wykorzystuje to, co faza uprzywilejowana już uzyskała. Nie ma tu żadnej magii i proces niczego nie przeżywa. Pozyskiwanie zasobów jest po prostu odroczone.

Czytaj pierwszy błąd, nie ostatni

Gdy restart się nie powiedzie, czytaj pierwszy błąd zamiast ostatniego. Chroniony klucz, plik auth, ioctl interfejsu i zewnętrzny hook to cztery różne zasoby. Zachowanie jednego nic nie mówi o dostępie do pozostałych. Hook, który wywołuje narzędzie firewalla, nadal potrzebuje uprawnień wymaganych przez to narzędzie.

Hooki mają własny przełącznik. Podręcznik OpenVPN łączy opcje persist z up-restart, który decyduje, czy skrypty up i down uruchomią się ponownie po restarcie. Interfejs, który pozostał podniesiony, nie mówi ci więc nic o tym, czy twoja integracja resolvera została odświeżona.

# which restart path just happened?
journalctl -u openvpn-client@office --since '10 min ago' | grep -E 'SIGUSR1|ping-restart|Restart pause|NOTE:'

# did the interface survive, and do its routes still exist?
ip -brief link show tun0
ip route show dev tun0

Ta para poleceń rozdziela dwa tryby awarii w sekundach. Interfejs, który istnieje, ale brakuje mu tras, to problem hooka lub trasy. Interfejs, który zniknął, oznacza, że proces naprawdę się zakończył.

Zachowany interfejs nie jest kill switchem

Jeśli wymaganiem jest, by ruch nigdy nie opuszczał tunelu, zachowane urządzenie tego nie zapewnia. Trasy dla drugiej rodziny adresów, druga trasa domyślna i przypadek, w którym proces kończy się całkowicie, pozostają poza zakresem opcji.

Traktuj oba wymagania osobno. Zachowywanie obiektu tunelu między ponownymi połączeniami to wygoda dla demona. Blokowanie wyjścia, gdy tunel jest wyłączony, to polityka firewalla z własnymi regułami i własnym testem. Mieszanie ich daje konfigurację, która wygląda obronnie, a zachowuje się jak ponowne połączenie najlepszym wysiłkiem.

Nazwij zdarzenie, zanim je zdiagnozujesz. Miękki restart, nieudana próba połączenia i zatrzymanie usługi to trzy zdarzenia o trzech zachowaniach, i tylko pierwsze jest tym, co opisują te opcje.