Która instancja OpenVPN naprawdę używa twojego profilu PiVPN?

PiVPN zapisuje konfigurację serwera i profil klienta, a następnie kończy pracę; nigdy nie staje się procesem, który przenosi twój ruch. Dlatego nieudanego uścisku dłoni, klienta łączącego się z niewłaściwym punktem końcowym ani usługi, która po restarcie wraca nieprawidłowo, nie da się wyjaśnić z menu instalatora. Te objawy należą do tego demona OpenVPN, który działa teraz, do konfiguracji, którą ten demon faktycznie wczytał, i do logu, na który go wskazano. Cztery polecenia tylko do odczytu zwykle to rozstrzygają i żadne z nich nie zmienia twoich certyfikatów ani kluczy.

Pomocnik i demon to różne obiekty

Zamieszanie łatwo wyjaśnić: jeden katalog zawiera plik utworzony przez pomocnika, plik czytany przez demona, a czasem nieaktualną kopię obu. Pomocnik to skrypt przygotowawczy. Instaluje pakiety, zapisuje pliki jednostek i wypisuje profil klienta, a potem jego praca się kończy. Zostaje wpis w menedżerze usług i wiersz poleceń.

Na hoście systemd zacznij od aktywnej jednostki, a nie od listy katalogu. Nazwa zależy od pakowania: obrazy Debian i Raspberry Pi OS zwykle udostępniają instancję szablonu, taką jak openvpn-server@server, podczas gdy starsze instalacje używają openvpn@server. Zapytaj menedżera, która działa, zamiast zgadywać z nazwy pliku.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

Przeczytaj ExecStart= w tym wyjściu. Wymienia plik wykonywalny i opcje, które menedżer faktycznie uruchamia, w tym każdą --config ścieżkę; plik konfiguracji leżący obok, do którego nie odwołuje się żadne polecenie, nie jest częścią działającego tunelu.

Śledź łańcuch konfiguracji rozwiązany przez demona

OpenVPN nie skanuje katalogu w poszukiwaniu ustawień. Czyta plik przekazany z --config, podąża za każdą config dyrektywą w nim, a potem stosuje opcje wiersza poleceń. Podręcznik 2.6 opisuje tę kolejność i ma to znaczenie, gdy dwa pliki nie zgadzają się co do portu, urządzenia lub szyfru.

Najpierw zrzuć efektywne wywołanie, a potem spójrz na dyrektywy decydujące o tożsamości i osiągalności. Oba polecenia są tylko do odczytu i bezpieczne na działającym serwerze, choć drugie wypisuje ścieżki, których możesz nie chcieć w publicznym zgłoszeniu.

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

Plik .ovpn w katalogu domowym jest artefaktem klienta. Demon serwera nigdy go nie czyta, więc edytowanie tego pliku, by naprawić błąd uścisku dłoni po stronie serwera, niczego nie daje.

Dołączenia to druga pułapka. Linia config wciąga drugi plik, którego opcje są przetwarzane w tym miejscu, więc późniejsza dyrektywa o jednej wartości może przesłonić to, co główny plik zdaje się mówić. Jeśli widoczny plik wygląda poprawnie, a demon nadal zachowuje się inaczej, przeczytaj dołączony plik, zanim cokolwiek zmienisz.

Dopasuj log do procesu, a nie do błędu, który pamiętasz

Dwa miejsca docelowe logu są częste, a tylko jedno z nich to journal. Przy log-append demon pisze do tego pliku, a journal zachowuje niewiele poza liniami startowymi. Bez tego journalctl jest źródłem zdarzeń.

journalctl -u openvpn-server@server -n 80 --no-pager

Powiąż jedną próbę połączenia z jednym oknem czasowym. Zanotuj punkt końcowy klienta, a potem czytaj zdarzenia serwera z tych samych sekund. Uścisk dłoni TLS, który nigdy nie dociera do wymiany certyfikatów, wskazuje na osiągalność lub niezgodność protokołu, podczas gdy odrzucenie uwierzytelnienia przychodzi po uzgodnieniu parametrów tunelu.

Stary wpis w logu niczego nie dowodzi w sprawie profilu pobranego pięć minut temu. Wygeneruj plik klienta ponownie, połącz się raz i czytaj tylko linie, które pojawiły się podczas tej próby.

Zanotuj pierwszy konkretny błąd, a nie ostatni ogólny. Błąd bindowania, nieodpowiedziana wymiana zewnętrzna, odrzucenie certyfikatu i odrzucenie konta prowadzą cię każdy do innej warstwy, a limit czasu na końcu często ukrywa przydatne zdarzenie powyżej.

Odbudowa tunelu nie jest krokiem diagnostycznym

Kuszącym skrótem jest postawienie drugiego, prostszego tunelu: klucz statyczny, bez certyfikatów, bez dodatkowego uwierzytelniania. Często się połączy i dowodzi tylko, że dwa hosty mogą przepuścić między sobą UDP lub TCP. Nie mówi nic o tym, dlaczego wdrożenie z uwierzytelnianiem certyfikatami zawodzi, i po cichu zastępuje model bezpieczeństwa, który miałeś zachować.

To samo dotyczy wyłączania tls-auth lub tls-crypt, łagodzenia verify-x509-name, albo porzucania drugiego czynnika dla zielonego statusu. Tunel, który łączy się, bo usunięto weryfikację, to inny system, a nie naprawiony.

Wprowadź jedną ograniczoną zmianę w warstwie wskazanej przez log, zrestartuj tę samą jednostkę i powtórz jedną próbę połączenia. To utrzymuje uczciwe porównanie i pozostawia zmianę, którą możesz cofnąć.

Co przekazać następnej osobie

Zapisz cztery fakty, dopóki je masz: wersję OpenVPN z openvpn --version, aktywną jednostkę, łańcuch konfiguracji z dołączeniami i okno logu obejmujące jedną próbę. Te cztery zamieniają mgliste zgłoszenie w odtwarzalny przypadek.

Zredaguj przed udostępnieniem. Klucze prywatne, auth-user-pass pliki, materiał klucza statycznego i pełne pakiety klienta nie należą do zgłoszenia; nazwy opcji i kształt łańcucha zwykle wystarczą drugiej parze oczu.

Jeśli łańcuch jest nienaruszony, a log nadal wskazuje na sieć, następnym krokiem jest droga między klientem a serwerem, a nie kolejna instalacja. To ta jedna część historii, której pomocnik nigdy nie posiadał.