OpenVPN nie startuje bez błędu? Zajrzyj do journala

Polecenie wraca, usługa pokazuje się jako nieudana, a do terminala nie dociera nic, co przypomina wyjaśnienie. Ta cisza jest objawem, który ludzie opisują jako „OpenVPN nie startuje”, i prawie nigdy nie oznacza, że program zginął, nic nie mówiąc. Oznacza, że komunikat trafił do kanału, którego nie czytałeś, albo że to, co uruchomiłeś, nie było tym, co skonfigurowałeś. Oba przypadki można zdiagnozować w mniej niż minutę, gdy przestaniesz traktować profil jako podejrzanego.

Cztery miejsca pochłaniają wyjście: journal jednostki, wtyczka, która posiada połączenie, drugi koniec tunelu i inny plik binarny niż ten, który, jak sądzisz, działa. Każde ma własną kontrolę.

Cisza oznacza, że nie patrzyłeś na właściwy kanał

Wywołanie na pierwszym planie drukuje do twojego terminala. Jednostka drukuje do journala, a nieudana jednostka może zakończyć się, zanim cokolwiek zapisze, jeśli błąd tkwi w tym, jak została uruchomiona, a nie w tym, co jej powiedziano. Ta różnica jest ważna: brak wpisu w journalu oznacza, że proces nigdy naprawdę nie działał, natomiast jeden wpis i po nim zakończenie oznacza, że działał i czemuś odmówił.

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

Dodaj systemctl show -p Result -p ExecMainStatus openvpn-client@office, aby oddzielić czyste zakończenie od sygnału. Status 1 z Result=exit-code jest decyzją programu; Result=signal lub limit czasu wskazują raczej na środowisko, i żadna edycja profilu tego nie zmieni. Zapisz obie wartości, zanim cokolwiek uruchomisz ponownie, bo restart usuwa stan przejściowy, który je wytworzył.

Nazwa instancji jest częścią ścieżki

Spakowana jednostka szablonu nie przyjmuje ścieżki pliku. Przyjmuje nazwę instancji, a ta nazwa jest dodawana do katalogu, aby znaleźć profil: office w pakietach Debian i Ubuntu rozwiązuje się na /etc/openvpn/client/office.conf. Plik o nazwie office-v2.conf, uruchomiony jako @office nigdy nie jest czytany, a jednostka kończy się cicho, bo z jej punktu widzenia nie było nic do zrobienia. Katalog wyszukiwania różni się między trybem klienta i serwera, więc ten sam błąd wskazuje zupełnie inne miejsce, gdy zmienisz szablon.

Ta rozbieżność jest najczęstszą przyczyną cichej awarii i jest niewidoczna w profilu, ponieważ profil jest w porządku. Wypisz, co naprawdę istnieje, i porównaj obie nazwy znak po znaku, łącznie z każdym rozszerzeniem, którego oczekuje pakiet.

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

Jeśli jednostka jest włączona, ale nie ma żadnej instancji, samo włączenie może wskazywać na nazwę, która została później zmieniona. Ponowne włączenie właściwej instancji zwykle wystarcza, a stary pozostawiony plik jednostki warto usunąć, aby nie mylił następnej osoby. Pozostawiony plik jednostki to drobiazg, który komuś później kosztuje godzinę.

Gdy tunel należy do wtyczki, terminal nic nie widzi

Połączenie uruchomione z apletu pulpitu należy do NetworkManagera, a jego wyjście OpenVPN trafia do journala tej usługi, a nie do powłoki, którą masz otwartą. Uruchamianie klienta ręcznie i brak jakiegokolwiek wyjścia jest w tym układzie oczekiwane, bo proces uruchomiony ręcznie nie jest tym, który niesie połączenie.

Poszukaj w journalu usługi, która jest jego właścicielem, a następnie odtwórz parsowanie z poziomem szczegółowości, który możesz przeczytać. Dwa poniższe polecenia patrzą na różnych właścicieli tej samej awarii.

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

Osobne uruchomienie służy do czytania komunikatów, a nie do zastępowania zarządzanego połączenia, i oba różnią się potem: integracja DNS, trasy i czas życia należą do wtyczki. Naprawienie błędu parsowania w osobnym uruchomieniu nie naprawia automatycznie rozwiązywania nazw, gdy aplet przejmie kontrolę, więc trzymaj obie obserwacje osobno.

Dwa pliki binarne, jeden PATH

Ręcznie zbudowana instalacja pod /usr/local wygrywa przy wywołaniu z powłoki, bo /usr/local/sbin poprzedza /usr/sbin w domyślnym PATH Ubuntu. Jednostka nie używa twojego PATH; wykonuje ścieżkę bezwzględną zapisaną w ExecStart. Wersja działająca w twoim terminalu i wersja, która zawodzi jako usługa, mogą więc być naprawdę różnymi programami.

Porównaj oba, zanim cokolwiek przebudujesz. Trzecie polecenie jest tym, które rozstrzyga spór.

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

Jeszcze jedna różnica środowiskowa kryje się w tym samym miejscu. Spakowana jednostka polega na katalogu czasu wykonania pod /run , który tworzy dla niej systemd; ręcznie napisana jednostka zastępcza, która pomija to ustawienie, może zawieść, zanim otworzy choć jeden plik, a awaria wygląda jak ogólna odmowa bez żadnego komunikatu OpenVPN.

Awarie, których klient nie może zgłosić

Niektóre wyniki rozstrzygają się na drugim końcu. Brama, która odpowiada statusem HTTP i zamyka połączenie, powiedziała ci o swoim stanie, a użytecznym następnym krokiem jest jej log albo konto za poświadczeniami, a nie twoje lokalne pliki. W tym scenariuszu nic lokalnego nie jest zepsute, a edycja profilu dla kompensacji utrudnia następną diagnozę. Przeczytaj ten log, zanim dotkniesz konfiguracji klienta.

Innym cichym przypadkiem jest klient, który działa poprawnie. Tunel w trybie klienta nigdy nie nasłuchuje na porcie, więc kontrola oczekująca otwartego nasłuchu nic nie zgłosi i będzie wyglądać jak awaria. Potwierdź, który tryb uruchomiłeś, zanim wyciągniesz wniosek z pustej listy portów.

Przechodź warstwy po kolei: czy jednostka istnieje i czy nazwa instancji jest poprawna, czy coś dotarło do journala lub pliku --log , który plik binarny i profil naprawdę działały, i czy awaria jest lokalna czy zdalna. Każda odpowiedź usuwa jedną warstwę. Zaczynanie od profilu oznacza przepisanie pliku, który może nigdy nie został otwarty.