openvpn3 session-start ignoruje plik danych logowania

Połącz się klientem 2.x, a profil działa; podaj ten sam plik klientowi 3.x, a zatrzyma się na monicie o hasło. Podaj --auth-user-pass creds.txt do openvpn3 session-start, a wynik jest taki sam, ponieważ nowszy klient nie ma etapu, który czyta ten plik. Odmowa jest zamierzona: dane logowania należą do sesji, a sesję tworzy usługa, a nie proces w twoim terminalu. Wybierz między interaktywnym monitem a pomocnikiem autoload i wiedz, co każdy z nich przechowuje.

Dlaczego zapisany plik nie ma gdzie trafić

W nowszym projekcie zarządzanie konfiguracją i zarządzanie sesjami to osobne usługi rozmawiające przez magistralę systemową. To rozdzielenie pozwala zwykłemu użytkownikowi rozpocząć sesję bez uprzywilejowanego demona czytającego w jego imieniu chroniony plik haseł. Dane logowania oparte na plikach nie mają miejsca w tym modelu, ponieważ nie ma uruchamiania po stronie demona, które by je czytało. Odmowa jest konsekwencją architektury, a nie brakującą funkcją.

Stary wzorzec warto nazwać, żeby łatwiej się go oduczyć: profil wskazuje plik danych logowania, a demon czyta go przy starcie tunelu. W nowym modelu dane logowania należą do sesji i są dostarczane, gdy ta sesja się zaczyna. openvpn3 session-start --config work.ovpn pyta o nie, a --auth-user-pass creds.txt jest odrzucany, ponieważ nic na tej ścieżce nie otworzyłoby pliku. Każdy przepis 2.x, który znajdziesz, zakłada etap, którego już nie ma.

Konfiguracja i ustawienia lokalne witryny są również rozdzielone, co wyjaśnia drugą niespodziankę. Profil może wyglądać na kompletny, choć połączeniu, które tworzy, brakuje konfiguracji routingu i resolvera. Te elementy są stosowane jako ustawienia lokalne witryny, osobno od zaimportowanego pliku.

Ścieżka monitu i sesja, którą zostawia

Podanie hasła przy starcie sesji to zamierzony przepływ pracy. Klient pyta raz, przekazuje dane logowania backendowi sesji i kontynuuje:

openvpn3 session-start --config work.ovpn
openvpn3 sessions-list

Tą ścieżką nic nie jest zapisywane na dysku. Sesja działa dalej po zamknięciu terminala, co zaskakuje ludzi oczekujących, że proces umrze wraz z powłoką. Właśnie o to chodzi w przenoszeniu obsługi sesji do usługi. Sesja żyje dłużej niż terminal, który o nią poprosił, i trzeba ją jawnie zatrzymać.

W przypadku stacji roboczej z człowiekiem przed nią jest to także najbezpieczniejsza opcja, ponieważ nie ma zapisanego sekretu, którego trzeba by chronić lub zapomnieć. Nie nadaje się tylko tam, gdzie nie ma nikogo do wpisania.

Automatyzacja bez osoby przy klawiaturze

Tam, gdzie maszyna musi połączyć się bez osoby, projekt dostarcza openvpn3-autoload. Odczytuje katalog profili i pasujący opis dla każdego profilu, a opis dostarcza dane logowania w czystym tekście. Pomocnik to osobny plik binarny, zwykle w /usr/sbin/openvpn3-autoload, a nie flaga session-start. Skonfigurowanie go oznacza utworzenie katalogu, skopiowanie profilu pod nazwą oczekiwaną przez opis i zapisanie opisu.

Konfiguracja dla pojedynczego użytkownika wygląda tak i jest uruchamiana jako konto, które będzie właścicielem sesji. Tryb katalogu trzyma innych lokalnych użytkowników na zewnątrz:

mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload

Opis nazywa dane logowania i prosi o automatyczny start. Trzymaj wartość hasła poza kontrolą wersji:

{
  "autostart": true,
  "user-auth": {
    "autologin": true,
    "username": "svc-vpn",
    "password": "change-this-value"
  }
}

Następnie wywołaj pomocnika raz i potwierdź, że sesja się pojawia. Drugie polecenie to sprawdzenie, a nie kolejny krok konfiguracji:

/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list

Przy starcie spakowana jednostka o nazwie openvpn3-autoload.service używa katalogu systemowego /etc/openvpn3/autoload, a nie tego dla użytkownika. Ta lokalizacja wymaga własności roota i bardziej rygorystycznego trybu, a opis nadal przechowuje hasło w czystym tekście. Kompromis jest wyraźny: hasło leży teraz na dysku, więc traktuj ten katalog jak sekret, wyklucz go z kopii zapasowych poza hostem i wybieraj ścieżkę interaktywną zawsze, gdy jest obecna osoba.

Awaria magistrali, która wygląda jak awaria hasła

Niektóre awarie przypisywane danym logowania wcale takie nie są. Błąd uprawnień nazywający ścieżkę aktywacji usługi oznacza jedną z dwóch rzeczy: backend nie działa albo wywołujący nie ma uprawnień, by go aktywować. Żadna edycja profilu tego nie zmieni. Sprawdź stan usługi i dostarczoną politykę magistrali, zanim dotkniesz konfiguracji.

Polecenia poniżej rozdzielają te dwie rzeczy. Pierwsze informuje, czy backend działa; drugie pokazuje ostatnie błędy magistrali:

systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20

Innym częstym błędem odczytu jest sesja, która pojawia się i natychmiast znika. Ten wzorzec zwykle oznacza, że ustawienia lokalne witryny nigdy nie zostały zastosowane, więc tunel wstał bez tras i zmian resolvera, które czynią go użytecznym. Czytaj sekwencję, a nie ostatnią linię: to, czy sesja została utworzona, czy osiągnęła stan połączenia i czy przetrwała, to trzy osobne fakty.

Gdy starszy klient jest nadal w użyciu

Klient 2.x nadal akceptuje plik danych logowania, a keyring może odpowiedzieć na jego monit, zanim sekret trafi na dysk. Opakowanie rozwiązuje wpis, więc plik nazywa odnośnik wyszukiwania, a nie hasło. Ten układ zależy od odblokowanego keyringa, którego nie zapewni kontener bez sesji logowania ani jednostka uruchamiana przed zalogowaniem się kogokolwiek. Narzędzie wyszukiwania zgłasza wtedy kolekcję, do której nie może pisać, więc błąd wygląda jak usterka danych logowania, choć jest usterką keyringa.

Zanim cokolwiek z tego zbudujesz, sprawdź, czy ustawienie keepalive w profilu nie usuwa całkowicie potrzeby restartu. Sesja, która pozostaje włączona, nigdy nie osiąga monitu, który próbujesz zautomatyzować.