Twój tunel wstaje i klient się łączy, ale stały adres i wypchnięte trasy, które zdefiniowałeś dla tego jednego użytkownika, zniknęły. W logu nie ma “file not found”, i właśnie to wysyła ludzi do ponownego generowania certyfikatów. W większości takich przypadków demon działa z innego katalogu niż powłoka, w której testowałeś, a client-config-dir nigdy nie zostało rozwiązane tak, jak zakładałeś. Poprawka to korekta ścieżki, a nie reset danych logowania.

Przeczytaj unit, zanim dotkniesz konfiguracji

Zacznij od procesu, który naprawdę działa, a nie od pliku, który edytowałeś. Zapytaj systemd o linię uruchomienia, katalog roboczy i konto, na które schodzi. Te trzy odpowiedzi wyjaśniają większość awarii w tej klasie:

systemctl show openvpn-server@server -p ExecStart -p WorkingDirectory -p User -p RootDirectory

Pusty WorkingDirectory oznacza, że unit startuje w /, więc względna client-config-dir ccd jest szukana w /ccd. Ten katalog prawie nigdy nie istnieje, a demon nie uznaje jego braku za krytyczny.

Porównaj to z interaktywnym uruchomieniem, którego używałeś podczas testów, gdzie bieżącym katalogiem twojej powłoki był prawdopodobnie katalog konfiguracji. Ten sam plik, te same słowa kluczowe, dwa różne wyniki.

Względem czego rozwiązywana jest ścieżka względna

Słowo kluczowe jest rozwiązywane względem katalogu roboczego procesu w chwili użycia opcji. Nie znaczy to “obok pliku konfiguracji, który podałem przez --config”. OpenVPN chętnie przeczyta konfigurację ze ścieżki bezwzględnej i mimo to rozwiąże wartości względne gdzie indziej, i dokładnie w tym tkwi pułapka. Podręcznik OpenVPN 2.6 podaje tę zasadę przy --client-config-dir i ponownie przy --cd.

Słowo kluczowe cd zmienia ten kontekst, zanim przeczytane zostaną inne pliki, więc unit, który ustawia cd /etc/openvpn/server i potem client-config-dir ccd, rozwiązuje się na /etc/openvpn/server/ccd. Jeśli dodasz cd, sprawdź kolejność dyrektyw i pamiętaj, że wpływa to na każde inne względne odwołanie w tym samym pliku.

Przejdź ścieżkę jako konto demona

Ścieżka może być poprawna i wciąż nieczytelna. Po zrzuceniu uprawnień demon nie jest już rootem, więc każdy katalog nadrzędny potrzebuje prawa wyszukiwania dla tego konta, a sam plik klienta prawa odczytu. Jeden brakujący bit wykonania na katalogu nadrzędnym wystarczy, by ukryć plik, a błąd objawia się tylko jako klient, który po cichu dostaje domyślną pulę.

namei wypisuje uprawnienia każdego elementu po kolei, co jest szybsze niż sprawdzanie katalogów jeden po drugim:

namei -l /etc/openvpn/server/ccd/client1

Potem sprawdź odczyt jako konto usługi, a nie jako ty:

runuser -u openvpn -- test -r /etc/openvpn/server/ccd/client1 && echo readable

Jeśli unit używa chroot, katalog musi istnieć wewnątrz więzienia, a ścieżka w konfiguracji jest interpretowana po zastosowaniu chroot. Plik, który jest na hoście poza więzieniem, jest niewidoczny od środka.

Potwierdź wyszukiwanie zamiast zgadywać

Podnieś poziom logu na jedno restartowanie i przeczytaj, co serwer mówi o opcjach specyficznych dla klienta. Przy verb 4 demon raportuje zaimportowaną konfigurację dla każdego klienta, więc brakujący wiersz jest bezpośrednim dowodem, że dla tego połączenia nie odczytano żadnego pliku.

openvpn --config /etc/openvpn/server.conf --verb 4 --client-config-dir /etc/openvpn/server/ccd

Uruchom to na pierwszym planie na wolnym porcie i podłącz jednego klienta. To całkowicie usuwa systemd z obrazu: jeśli nadpisania pojawiają się tutaj, a nie pod usługą, różnica tkwi w kontekście unitu, nie w pliku.

Zdecyduj, co ma się stać, gdy żaden plik nie pasuje. Bez ccd-exclusive klient jest przyjmowany tylko z globalnymi ustawieniami puli, i to jest cicha awaria opisana wyżej. Z nią brakujący plik staje się odrzuconym połączeniem, a takie odrzucenie łatwiej zauważyć, ale trudniej debugować pod obciążeniem.

Popraw, zrestartuj, zweryfikuj

Ustaw katalog jako bezwzględny w konfiguracji i zostaw go tak. Ścieżki względne są bezpieczne tylko wtedy, gdy unit przypina katalog roboczy, a przypinanie to dodatkowy ruchomy element, który ktoś później usunie.

client-config-dir /etc/openvpn/server/ccd
ccd-exclusive

Zrestartuj instancję, podłącz ponownie znanego klienta i odczytaj adres, który otrzymał, wraz z trasami wypchniętymi do niego. Jeśli adres zgadza się z wierszem ifconfig-push w pliku tego klienta, wyszukiwanie zadziałało. Jeśli klient nadal trafia do puli ogólnej, wróć do liczby wierszy logu: zero importów oznacza, że ścieżka lub tożsamość jest błędna, jeden import z błędną zawartością oznacza, że edytujesz inny plik niż ten, który czyta demon.

Wycofaj się, przywracając poprzedni unit i konfigurację razem, a następnie zrestartuj. Certyfikatów nie trzeba z tego powodu wystawiać ponownie, a traktowanie problemu z katalogiem jako problemu z danymi logowania to sposób, w jaki pięciominutowa poprawka staje się oknem serwisowym.

Powiązane artykuły