Restartowanie usługi przy OpenVPN up: hooki biją tun0.device

Podłączenie zależnej usługi do tun0.device wygląda jak subskrypcja tunelu, ale nią nie jest. Jednostka urządzenia odzwierciedla istnienie interfejsu, co może pozostać prawdą przez nieudane połączenie i następujące po nim ponowne połączenie. Usługa działa wtedy w złym momencie albo wcale, zależnie od tego, czy interfejs zniknął w międzyczasie. Hookiem opisującym zdarzenie, na którym naprawdę ci zależy, jest ten, który wywołuje OpenVPN, a nie ten, który wnioskuje systemd.

Zdecyduj, jakiego warunku potrzebuje usługa, zanim wybierzesz wyzwalacz, bo trzej kandydaci nie są wymienne.

Co jednostka urządzenia faktycznie śledzi

systemd tworzy jednostkę urządzenia na podstawie widoku jądra na interfejs sieciowy, więc tun0.device staje się aktywna, gdy interfejs się pojawia, i nieaktywna, gdy zostaje usunięty. Z persist-tun miękki restart utrzymuje interfejs na miejscu, więc jednostka nigdy nie migocze i nic do niej przywiązanego nie zostaje wyzwolone. Nawet bez trwałości jednostka nic nie mówi o trasach, DNS ani o tym, czy odpowiada drugi koniec.

To czyni ją słabym zastępnikiem „VPN jest gotowy”. Odbiorca, który potrzebuje tylko adresu lokalnego, może zadowolić się istnieniem interfejsu, podczas gdy usługa wywołująca aplikację w zdalnej sieci potrzebuje tras i osiągalności, czego jednostka urządzenia nie potrafi wyrazić.

up, route-up i up-restart znaczą różne rzeczy

up uruchamia się po otwarciu urządzenia TUN/TAP i skonfigurowaniu interfejsu, co jest właściwym momentem dla odbiorcy wiążącego przydzielony adres. route-up uruchamia się po zainstalowaniu tras, z uwzględnieniem skonfigurowanego opóźnienia trasy, i pasuje do pracy wymagającej ukończonego etapu tras. Żaden z nich nie dowodzi, że zdalna aplikacja odpowiada. Wybór między nimi jest pytaniem o to, czego potrzebuje usługa, a nie o to, który hook brzmi bardziej ukończenie.

Z persist-tun restarty ponownie używają urządzenia, więc up nie uruchamia się ponownie, chyba że ustawiono up-restart. Ta opcja włącza skrypt up dla udokumentowanego cyklu życia restartu, a jego środowisko jest zredukowane w porównaniu z pierwszym startem. Skrypt zakładający pełne środowisko działa przy pierwszym połączeniu i zawodzi przy następnym.

Wyślij akcję, nie czekając na nią

Hook, który synchronicznie wywołuje systemctl restart, może wejść w zakleszczenie z jednostką, której kolejność czeka na tunel. systemctl --no-block try-restart vpn-dependent.service umieszcza zadanie w kolejce i wraca, co nie pozwala hookowi zablokować połączenia, na które reagował. try-restart działa tylko na działającą jednostkę, podczas gdy restart uruchamia także nieaktywną; wybieraj świadomie, a nie z przyzwyczajenia.

Umieszczenie w kolejce nie jest weryfikacją. Hook zwraca sukces, gdy tylko zadanie zostanie przyjęte, więc sprawdzenie musi nastąpić w dzienniku jednostki docelowej lub w jej rzeczywistym stanie odbiornika.

Polityka restartu żyje w jednostce, a nie w hooku

Jednostka oneshot z RemainAfterExit=yes pozostaje aktywna po zakończeniu swojego polecenia, a drugie żądanie startu nic nie robi, bo systemd uznaje ją za już uruchomioną. To właściwość, wokół której się projektuje, a nie defekt, który obchodzi się powtarzanymi wywołaniami startu. Jeśli akcja ma działać przy każdym połączeniu, jednostka potrzebuje kształtu, który na to pozwala.

After= porządkuje jednostki, a BindsTo= wiąże czasy życia, ale żadne z nich nie znaczy „restartuj to za każdym razem, gdy VPN się ponownie łączy”. Jednostka powiązana z tunelem zatrzymuje się, gdy tunel się zatrzyma; nie restartuje się sama, gdy tunel wróci, chyba że coś ją ponownie uruchomi.

Przetestuj trzy ponowne połączenia, a nie jedno

Zimny start, pełny restart klienta i miękkie ponowne połączenie ćwiczą każdy inną ścieżkę. Miękkie ponowne połączenie jest tym, które ujawnia brakujący up-restart, zredukowane środowisko lub jednostkę urządzenia, która nigdy nie stała się nieaktywna. Uruchom wszystkie trzy i potwierdź oba kierunki: usługa działa, gdy tunel się podnosi, i nie restartuje się przy niepowiązanych zmianach łącza, takich jak roaming Wi-Fi.

Zachowaj niezależną ścieżkę odzyskiwania, gdy zależna usługa niesie twój własny dostęp administracyjny. Hook, który restartuje to, przez co jesteś połączony, jest zmianą, która może cię zablokować.