OpenVPN nie startuje: czytaj pierwszą linię, nie konfigurację

VPN, który umiera w pierwszej sekundzie, to inne zwierzę niż ten, który się łączy i potem zawodzi, a zwykłym błędem jest traktowanie ich tak samo. Nie ma tu handshake, wymiany certyfikatów ani trasy do zbadania. Jedna linia w journalu decyduje, która z kilku niepowiązanych napraw obowiązuje, a jej pominięcie kosztuje pół dnia edycji konfiguracji, której nigdy nie wczytano. Przeczytaj tę linię najpierw.

Trzy polecenia tylko do odczytu zaprowadzą cię tam: najpierw journalctl -u openvpn@server -b --no-pager, potem systemctl status openvpn@server, i ss -lunp dla nasłuchujących gniazd UDP oraz ich właścicieli.

Pierwsza linia wybiera gałąź

Konflikt portów i brakująca binarka oba zabijają start w ciągu sekundy, i zostawiają różne pierwsze linie. Komunikat, że adres jest już w użyciu, nazywa port; brakujący plik wykonywalny nazywa ścieżkę, która już nie istnieje; nieudany warunek lub brakujący plik konfiguracji nazywa plik. Te trzy prowadzą do różnych napraw, a żadnej nie poprawia reinstalacja klienta. Skopiuj pierwszy błąd do notatek, zanim uruchomisz cokolwiek innego.

Uważaj na pętlę ponowień, która ukrywa pierwotną linię. Jednostka z polityką restartu może pogrzebać pierwszy błąd pod tuzinem identycznych, więc journalctl -b filtrowany po jednostce i czytany od góry bije ogon.

Kto jeszcze trzyma port 1194

Winowajcą zwykle nie jest drugi serwer, który ktoś świadomie skonfigurował. Spodziewaj się klienta uruchomionego ręcznie, wciąż żywego w innym terminalu, drugiego profilu, który przypadkiem wybrał ten sam port, albo pakietu dostawcy, którego własny tunel trzyma 1194. Właściciel gniazda pojawia się w ss -lunp; przekaż ten PID do systemctl status, aby dowiedzieć się, czy odpowiada za to jednostka. Zatrzymaj go własną ścieżką sterowania, a nie sygnałem.

Sygnał do procesu zarządzanego przez jednostkę zwykle wywołuje restart, a ten sam błąd pojawia się chwilę później jako nowy problem. Użyj systemctl stop dla jednostki, własnego polecenia usługi pakietu dla instalacji dostawcy, a sygnału tylko dla czegoś, co sam uruchomiłeś w tej powłoce.

Jednostki pozostawione po odinstalowaniu

Odinstalowanie usuwa binarki; pliki jednostek pisane ręcznie, zwykle w /etc/systemd/system, to przeżywają. Systemd próbuje wtedy ponownie jednostki wskazującej ścieżkę, która już nie istnieje, a komunikat dotyczy tego brakującego pliku, nie wczorajszego usunięcia. systemctl status pokazuje ścieżkę fragmentu jednostki u góry, więc sprawdź ją za pomocą dpkg -S, zanim cokolwiek usuniesz. Gdy sierota zniknie, systemctl daemon-reload i systemctl reset-failed czyszczą stan; inaczej każde późniejsze sprawdzenie statusu go dziedziczy.

Gdy which openvpn odpowiada czymś w /usr/local, użyta binarka pochodzi od instalatora dostawcy, a nie z apt. Taki instalator zwykle przynosi własny nasłuch, własny wpis rozruchowy i własny katalog konfiguracji, więc usunięcie widocznego polecenia pozostawia gniazdo zajęte.

Odinstaluj go tak, jak dokumentuje dostawca, potwierdź, że port jest wolny, za pomocą ss -lunp, i dodaj klienta dystrybucji tylko wtedy, gdy go potrzebujesz.

Uporządkuj stan przed kolejną próbą

Wyczyść stan niepowodzenia, zanim wyciągniesz z niego wnioski: systemctl reset-failed usuwa liczniki, a systemctl status raportuje potem bieżący stan jednostki, a nie jej historię. Uruchom ją raz i czytaj journal tego konkretnego przebiegu, a nie zbiorczy stan maszyny. Jednostka zgłaszająca aktywność, gdy tunel nic nie przenosi, to osobny problem i znacznie częstszy. Oba zlewają się w zgłoszeniach błędów, bo oba kończą się słowami użytkownika, że VPN nie działa.

Zanotuj gałąź, którą wybrałeś: konflikt portów, brak binarki, brak konfiguracji. Następnym razem rozpoznanie będzie szybsze.