OpenVPN pokazuje active (exited)? Znajdź instancję, którą uruchomiłeś

Sprawdzasz tunel, uruchamiasz systemctl status openvpn i dostajesz active (exited) bez Main PID i z pustą listą procesów. Naturalny odczyt jest taki, że usługa wystartowała i zmarła, więc otwierasz unit, znajdujesz /bin/true i wnioskujesz, że pakiet jest zepsuty. W pakiecie Debiana ten stan to wrapper działający zgodnie z projektem, a tunel żyje w jednej z jednostek instancji, które uruchamia. Zbiorcza jednostka nigdy nie powie ci, która instancja ją zbudowała.

Co active (exited) naprawdę oznacza na tym unicie

Spakowana jednostka to zadanie jednorazowe: jej ExecStart to /bin/true, a RemainAfterExit=yes jest tym, co utrzymuje zakończoną jednostkę zgłaszaną jako active (exited). Usuń tę dyrektywę, a to samo udane zadanie /bin/true kończy się w inactive (dead), czyli dokładnie w stanie, którego ludzie oczekują i który błędnie czytają w drugą stronę. Polecenie jest tylko zastępnikiem, a jednostka raportuje o pracy wykonywanej przez inne jednostki. Nic w tym układzie nie jest zepsute, a zastąpienie /bin/true zmienia umowę pakowania, nie tunel.

Wrapper deleguje. Uruchamia jednostki instancji dostarczane przez konfigurację pakietu lub jego generator systemd, dlatego pusta lista procesów niczego nie dowodzi w kwestii tunelu. Gdy nie wybrano żadnej instancji, wrapper nadal kończy się sukcesem i nadal niczego nie uruchamia. Stan odpowiada na pytanie, czy wrapper działał, a nie czy istnieje tunel.

Czytaj trzy wiersze wyjścia status, a nie słowo w nawiasie. Loaded nazywa plik jednostki, który przeczytał systemd, Active niesie znacznik czasu ostatniego udanego uruchomienia, a brak Main PID pasuje do zakończonego zadania jednorazowego. Te trzy wiersze to także sposób odróżnienia tego wrappera od usługi, która padła sekundę po starcie.

Wylistuj jednostki, zanim ponownie odczytasz status

Zapytaj systemd, co istnieje, zanim zapytasz, co działa. Szablon może być zainstalowany, gdy nie utworzono żadnej instancji, a tunel niesie tylko utworzona jednostka. Zacznij od załadowanego zbioru:

systemctl list-units 'openvpn*'

Ta lista to to, co systemd załadował w tej chwili, i jest najbliżej inwentarza tuneli. Zainstalowane pliki jednostek odpowiadają na inne pytanie, a ta lista nadal pokazuje szablon, gdy nic nie utworzono:

systemctl list-unit-files 'openvpn*'

Czytaj obie listy razem, ponieważ szablon w drugiej i instancja w pierwszej to dwie różne odpowiedzi. Istniejący szablon i działająca instancja nie są tym samym faktem, a tylko to drugie oznacza tunel. Układy pakietów różnią się też między dystrybucjami i wersjami OpenVPN. Starszy szablon openvpn@, rozdzielona para client i server oraz wrapper dystrybucji mogą być wszystkie legalne w swoim pakowaniu.

Dostosuj się do swojej maszyny, a nie do poradnika, który znalazłeś. Nazwa instancji w cudzym wyjściu może brzmieć office, podczas gdy twoja to home lub work. Przenoszona jest metoda, nie łańcuch.

Podążaj od nazwy instancji do pliku, który ona czyta

W szablonie client upstream katalogiem roboczym jednostki jest /etc/openvpn/client, a jej polecenie bierze stamtąd %i.conf, więc openvpn-client@office czyta /etc/openvpn/client/office.conf. Potwierdź to mapowanie na zainstalowanej jednostce, zamiast ufać przykładowi, ponieważ twój szablon może być starszy lub przepisany przez dystrybucję:

systemctl cat [email protected]

Czytaj pliki drop-in pojawiające się na dole tego wyjścia, ponieważ plik pod .d/ może zmienić ExecStart, katalog roboczy lub ścieżkę konfiguracji. Profil pobrany jako office.ovpn nie jest plikiem, który otwiera instancja. Ta luka to zwykły powód, dla którego błąd wskazuje ścieżkę, której nigdy nie edytowałeś.

Ścieżki względne w profilu to następna pułapka. Przeniesienie pliku głównego przy pozostawieniu względnych odwołań ca, cert i key zamienia błąd brakującego pliku na inny błąd brakującego pliku. Drugi wskazuje plik, którego istnienia byłeś pewien, dlatego katalog profilu jest ważniejszy niż nazwa pliku.

Uruchom ją, a potem przeczytaj dziennik tej instancji

Uruchom instancję, którą właśnie sprawdziłeś, ponieważ dziennik zbiorczej jednostki nie będzie zawierał błędów tunelu. Następnie przeczytaj dziennik tego rozruchu i szukaj w tej kolejności błędu konfiguracji, błędu dostępu do pliku i błędu połączenia, ponieważ każdy z nich zawodzi na innym etapie startu.

sudo systemctl start [email protected]
journalctl -u [email protected] -b

Uruchamianie i włączanie to osobne decyzje: start wykonuje jednostkę teraz, enable przygotowuje następny rozruch, a enable --now robi oba w jednym kroku. daemon-reload ponownie czyta definicje jednostek i nie restartuje działającego procesu ani nie stosuje edytowanego profilu. Po zmianie profilu zrestartuj instancję, ponieważ to ponownie czyta plik.

Nie stawiaj drugiego menedżera na tym samym tunelu

NetworkManager i menedżery sesji OpenVPN 3 mają własny stan połączenia, a instancja systemd obok jednego z nich stawia dwóch właścicieli na tym samym tunelu. Objawem jest tunel, który wstaje i po kilku sekundach jest zastępowany, albo taki, który odmawia pozostania zatrzymanym. Wybierz menedżera, którego twoja dystrybucja dokumentuje dla pulpitu, a na serwerze świadomie używaj systemd.

Sprawdź, czy istnieje już właściciel, zanim uruchomisz instancję. Gdy aplet pulpitu pokazuje połączenie, uruchomiona instancja konkuruje z nim zamiast je dopełniać. Wyłącz menedżera, którego nie używasz, zamiast uruchamiać oba i liczyć, że kolejność się utrzyma. Ten konflikt wyjaśnia też dzienniki, w których tunel jest ustanawiany, a potem rozbierany przez proces, którego nigdy nie uruchomiłeś.

Odpowiedz na pierwotne pytanie nazwą instancji, przeczytanym przez nią plikiem i nieudanym wierszem dziennika. Notatki OpenVPN o integracji z systemd opisują układ szablonu i mapowanie plików, przez które rozwiązywana jest nazwa instancji.