OpenVPN przy starcie w Ubuntu: NetworkManager czy systemd?

Większość poradników przedstawia ten wybór jako kosmetyczny: albo pozwól NetworkManagerowi podnieść tunel, albo włącz instancję systemd i po sprawie. Obie ścieżki różnią się jedną rzeczą, która decyduje o wyniku na maszynie bez ekranu, i nie ma ona nic wspólnego z tym, które narzędzie jest nowsze. NetworkManager odblokowuje sekrety przez sesję; instancja systemd nie ma sesji do odblokowania. Wybierz tę, której obchodzenie się z sekretami pasuje do maszyny przed tobą.

Wszystko inne, od instalacji tras po zachowanie przy ponownym łączeniu, wynika z tej pierwszej decyzji.

Pęk kluczy to różnica, o której nikt nie mówi

Gdy NetworkManager posiada profil VPN, hasło może mieszkać w pęku kluczy logowania, który odblokowuje się, gdy użytkownik się zaloguje. Na laptopie działa to dobrze: osoba jest obecna, pęk kluczy się otwiera, tunel się podnosi. Na serwerze, który startuje bez nadzoru, nie ma nikogo, kto by cokolwiek odblokował, więc profil czeka na sekret, który nigdy nie nadchodzi. Połączenie wygląda na skonfigurowane i nigdy się nie aktywuje.

Instancja systemd unika tego problemu, czytając plik poświadczeń z dysku, co czyni plik tym, co chronisz. chmod 400 plus własność roota to minimum, a plik powinien pozostawać poza kopiami zapasowymi i szablonami obrazów, których nie kontrolujesz.

Podłączenie VPN do połączenia nie jest gwarancją startu

W nm-connection-editor wybierz połączenie przewodowe lub bezprzewodowe zamiast VPN, otwórz kartę General, zaznacz opcję automatycznego łączenia z VPN i nazwij profil. NetworkManager aktywuje wtedy VPN jako połączenie dodatkowe, gdy połączenie podstawowe osiągnie stan połączony. To zależność, a nie reguła zapory. Pakiety nadal mogą wychodzić w sekundach przed podniesieniem tunelu, a zapisany sekret, którego nie da się odblokować, zostawia maszynę online bez niego.

Jeśli wymaganiem jest, aby nic nie wychodziło bez tunelu, powiedz to i zbuduj wyłącznik awaryjny, bo to ustawienie go nie zapewni. Przetestuj także wstrzymanie i wznowienie, ponieważ połączenie dodatkowe jest ponownie oceniane w drodze powrotnej.

Instancja systemd potrzebuje pasującej nazwy pliku

Umieść profil w katalogu klienta oczekiwanym przez pakiet, na przykład /etc/openvpn/client/office.conf, i wskaż w nim plik poświadczeń za pomocą auth-user-pass office.cred. Nazwa instancji to nazwa pliku bez rozszerzenia, więc openvpn-client@office czyta office.conf. Włącz ją poleceniem sudo systemctl enable --now openvpn-client@office i potwierdź mapowanie poleceniem systemctl cat openvpn-client@office, zamiast ufać przykładowi z bloga.

Ścieżki wewnątrz profilu są rozwiązywane względem katalogu roboczego jednostki, a nie samego profilu, więc względna linia ca lub auth-user-pass może zawieść przy starcie, choć działa przy ręcznym teście. Używaj ścieżek bezwzględnych dla wszystkiego, co jednostka musi znaleźć. Następnie po prawdziwym starcie odczytaj journalctl -u openvpn-client@office -b; jednostka, która zgłasza aktywność bez tunelu, zwykle wymienia w tym logu brakujący plik.

Starsze pakiety dostarczają inną nazwę szablonu, więc systemctl list-unit-files 'openvpn*' rozstrzyga, która istnieje na tym hoście.

Zachowanie przy ponownym łączeniu to osobna decyzja

Profil z ping-restart odbudowuje tunel po zerwaniu, a jednostka z dyrektywą restartu robi coś podobnego na poziomie usługi. To zasady, które wybierasz, a nie wartości domyślne, które dziedziczysz. Jeśli połączenie ma się podnosić tylko na żądanie, celowo usuń zachowanie restartu i zapisz dlaczego. Jeśli jednostka startuje, zanim sieć będzie użyteczna, potrzebuje zasady ponawiania, ponieważ jedna nieudana próba przy starcie nie powtarza się sama.

Zatrzymywanie jest równie dosłowne: sudo systemctl disable --now openvpn-client@office zatrzymuje działającą instancję i usuwa dowiązanie startowe. Samo wyłączenie pozostawia tunel działający do następnego restartu, co zaskakuje każdego, kto testuje przez wyłączenie i patrzy, jak interfejs pozostaje podniesiony.

Zrestartuj, a następnie sprawdź cztery rzeczy po kolei

Restart usługi testuje usługę; restart maszyny testuje ścieżkę startu. Po restarcie potwierdź, że jednostka wstała, potem że istnieje trasa do zdalnej podsieci, potem jaki adres maszyna prezentuje internetowi, a na końcu że nazwy są rozwiązywane przez tunel. Te cztery kontrole zawodzą w tej kolejności, gdy coś jest nie tak, co czyni pierwszy błąd tym użytecznym.

Jednostka aktywna bez trasy zwykle oznacza, że profil się połączył, ale serwer nie wypchnął żadnej trasy, albo że trasa została zainstalowana na interfejsie, który później zniknął. Trasa bez działającego wyszukiwania nazw wskazuje na konfigurację DNS, a nie na sam tunel.

Zdecyduj z góry, co ma się stać, gdy tunel nie może się podnieść. Powrót do zwykłej łączności to zasada i powinna zostać zapisana, a nie pozostawiona temu menedżerowi, który wystartował pierwszy.