OpenVPN 3 Linux: odczytaj błąd D-Bus, zanim cofniesz wersję
Pięć usług, jeden frontend. Przypisz błąd D-Bus do komponentu, który odmówił, sprawdź, czy istnieje sesja, i popraw na tej granicy.
Awarie OpenVPN 3 Linux przychodzą jako błąd metody D-Bus z nieznaną nazwą w środku, a pokusa jest taka, by obniżyć wersję pakietu i mieć nadzieję. Klient nie jest jednym programem: frontend wiersza poleceń rozmawia przez magistralę z usługami, które posiadają profile, sesje, silnik VPN i uprzywilejowane zmiany sieciowe. Rozstrzygnięcie, która z tych pięciu posiada zawodzące wywołanie, to większość diagnostyki, i kosztuje jedno polecenie zamiast wycofania wersji. To, co następuje, jest właśnie tą decyzją, w kolejności, w jakiej awarie zwykle się pojawiają.
Pięciu właścicieli za jednym poleceniem
Znaczenie ma pięć procesów, a każdy ma własną nazwę magistrali: frontend przyjmujący twoje polecenie, menedżer konfiguracji przechowujący profile i ich politykę dostępu, menedżer sesji posiadający czas życia sesji, backend prowadzący połączenie przez OpenVPN 3 Core Engine oraz usługa konfiguracji sieci instalująca interfejs, trasy i ustawienia DNS. Błąd nazywający obiekt konfiguracji nie jest więc błędem backendu, a backend, który nie startuje, nie jest błędem uwierzytelniania. Zaklasyfikowanie komunikatu do jednego z tych wierszy musi nastąpić, zanim cokolwiek zostanie zmienione, ponieważ każdy późniejszy krok zależy od tego, który wiersz jest prawdziwy. Zgadywanie wiersza to droga, na której krótka poprawka zamienia się w popołudnie przy pakietach.
Zapytaj magistralę systemową, jakie usługi są obecne, zanim zapytasz o cokolwiek innego, a następnie potwierdź, że zainstalowane części zgadzają się co do wersji. OpenVPN 3 Linux rejestruje te usługi jako jednostki systemowe, więc magistralą do odpytania jest magistrala systemowa, zapytanie o wersję wymaga uprawnień administracyjnych, a lista wykonana z --user czyta twoją sesję logowania, w której jednostki nigdy się nie pojawiają. Usługi aktywują się na żądanie, a niektóre kończą pracę, gdy są bezczynne, więc usługa brakująca przed twoim pierwszym żądaniem po prostu nie została jeszcze o nic zapytana. Trzy poniższe polecenia odpowiadają na pytanie o obecność, wersję i stan jednostki bez otwierania sesji VPN.
sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'Co naprawdę dowodzi każda z list
Widoki samego klienta są najtańszym dostępnym dowodem, a każdy z nich dowodzi mniej, niż się wydaje. Profil na liście konfiguracji pokazuje, że profil został zaimportowany, i nic o tym, czy ktoś może się z nim połączyć. Sesja na liście sesji pokazuje, że istnieje obiekt sesji, i nic o tym, czy uwierzytelnianie zdalne się zakończyło.
openvpn3 configs-list
openvpn3 sessions-listŚcieżki obiektów w tych wynikach wskazują obiekty zarządzane na magistrali, a nie pliki, więc nie można ich edytować, a ścieżka zapisana wcześniej staje się nieaktualna w chwili, gdy ta sesja się rozłączy. Użycie ponownie jednej z twoich notatek daje błędy "no such object", które nie mają nic wspólnego z VPN. Tabela etapów poniżej oddziela to, co ustanawia każdy krok połączenia, od tego, co pozostawia otwarte, i właśnie na tym rozróżnieniu opiera się decyzja o wycofaniu wersji. Przeczytaj wiersz pasujący do twojego dowodu, a potem przeczytaj tekst błędu jeszcze raz.
| Stage | What exists | What proves it | What it does not prove |
|---|---|---|---|
| Profile imported | A configuration object held by the configuration manager | The profile is listed by the client | That the profile owner permits a connection |
| Session requested | A session object held by the session manager | The session appears in the session list | That the remote side accepted the credentials |
| Connect dispatched | An asynchronous attempt on the VPN backend | Status changes arrive for that session | That an interface was configured |
| Tunnel configured | An interface, routes and DNS settings | The network service reports success and routes appear | That traffic reaches the peer |
Wywołanie połączenia wraca, zanim tunel istnieje
Wywołanie połączenia daje ci sesję do obserwacji i wraca, dlatego pozornie udane wywołanie, po którym następuje cisza, jest normalnym stanem pośrednim, a nie sprzecznością. Frontend nadal musi śledzić zmiany stanu i odpowiadać na każde żądanie interakcji. Profil, który potrzebuje poświadczenia i nie otrzymuje żadnej odpowiedzi, czeka w stanie wyglądającym dokładnie jak zawieszony backend. Ten stan oczekiwania zasługuje na rozpoznanie, bo wysyła ludzi do niewłaściwego komponentu.
Gdy próba trwa, obserwuj listę sesji oraz własny dziennik frontendu dla tego profilu. Sesja, która nigdy nie opuszcza stanu początkowego, nazywa komponent, który się zatrzymał, a dziennik zwykle nazywa go już w pierwszych linijkach. Miej pod ręką nazwę profilu, ponieważ polecenie dziennika przyjmuje profil, a nie ścieżkę sesji, co jest kolejnym powodem, by przeczytać listę ponownie zamiast używać ścieżki powtórnie.
openvpn3 sessions-list
openvpn3 log --config <profile> --level 6Czytanie dziennika jednego komponentu bez otwierania sesji
Gdy frontend nie zgłasza niczego użytecznego, idź do komponentu, który zapisał awarię, zamiast rozpoczynać kolejne połączenie. Przy skonfigurowanym rejestratorze systemd-journald ograniczony widok dziennika administratora czyta zdarzenia jednego komponentu bez dotykania polityki magistrali i bez otwierania sesji, co ma znaczenie, bo diagnostyka, która zmienia mierzony system, dowodzi bardzo niewiele. Filtruj po jednostce, a nie po znaczniku syslog: poszczególne jednostki usług nie gwarantują wspólnego identyfikatora, więc zapytanie po znaczniku może zwrócić pustą stronę, podczas gdy sama jednostka zapisała awarię.
Zapisz cztery pola, zanim poprosisz kogokolwiek o pomoc: pełną nazwę błędu, usługę i obiekt, których dotyczy, znacznik czasu oraz wersje zainstalowanych pakietów. To jest to, czego potrzebuje opiekun, i nic z tego nie wymaga wklejania profilu ani poświadczenia do zgłoszenia. Rozszerzanie polityki dostępu do magistrali, by uciszyć błąd, nie jest diagnostyką, usuwa granicę, która nazywała komponent za ciebie. Prywatna zawartość profili pozostaje poza współdzielonymi raportami z tego samego powodu co poświadczenia.
journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>Poprawianie granicy, która odmówiła
Każdy wiersz mapy ma własną poprawkę i wiersze nie zastępują się nawzajem. Odmówiona operacja na profilu to pytanie o politykę i własność, podczas gdy backend, który się nie aktywuje, to pytanie o usługi i pakowanie. Serwer odrzucający uwierzytelnianie nie jest żadnym z nich, więc powtarzane zmiany hasła nie naprawią lokalnego problemu z aktywacją. Wybór niewłaściwej poprawki to droga, na której problem z polityką staje się ponowną instalacją.
Po zmianie pakietów sprawdź spójną, obsługiwaną instalację, zamiast kopiować stary plik binarny na jego miejsce. Kontrolowane wycofanie wersji jest uzasadnioną odpowiedzią na potwierdzoną regresję, pod warunkiem że pakiety pozostają zgodne i istnieje droga powrotu do obsługiwanego utrzymania. Ustal tę drogę, zanim usługa przestanie się uruchamiać, a nie potem.
Inna platforma może dzielić tę samą bibliotekę rdzenia VPN bez dzielenia usług magistrali Linuksa, więc podobnie wyglądająca awaria w Windowsie nic o tej nie mówi. Przegląd D-Bus dokumentuje ścieżki obiektów udostępniane dla konfiguracji i sesji, i to jest ta część architektury, na której opiera się ta diagnostyka. Przeczytaj go raz, a następny błąd przyjdzie z komponentem już do niego przypisanym.