Polecenie działa, gdy jesteś zalogowany, więc wrzucasz je do skryptu startowego i idziesz do domu. Następnego ranka maszyna jest online, a tunel nie. Mit mówi, że działające wywołanie to działająca usługa. W praktyce różnica jest zwykle jedną z dwóch rzeczy: profil należy do twojej sesji użytkownika, a nie do systemu, albo sekret jest odblokowywany przez coś, co istnieje dopiero po zalogowaniu. Oba działają idealnie w teście ręcznym i zawodzą dokładnie w momencie, gdy nikt nie patrzy.

Dlaczego logowanie sprawia, że to działa

Logowanie graficzne uruchamia magistralę sesji i agenta usługi sekretów, i właśnie tam wiele klientów nastawionych na pulpit przechowuje hasło profilu lub frazę hasła klucza prywatnego. Aktywacja działająca po zalogowaniu jako twój użytkownik może poprosić tego agenta o sekret i odnieść sukces. Ta sama aktywacja wykonana przez jednostkę startową nie ma sesji, magistrali ani agenta, więc wyszukiwanie zawodzi lub blokuje się na monicie, którego nikt nie widzi.

Uruchom ten sam profil przed i po zalogowaniu, a dostaniesz dwa różne wyniki z jednej konfiguracji. To sygnatura zależności od poświadczeń, a nie zepsutego tunelu, i wyjaśnia, dlaczego test ręczny w terminalu dowodzi mniej, niż się wydaje. Tunel jest w porządku; brakuje tego, co odblokowuje jego sekret.

Zdecyduj, który właściciel uruchamia tunel

Istnieją dwa obsługiwane wzorce, a ich mieszanie to drugi sposób, w jaki to zawodzi. NetworkManager może aktywować połączenie w skali systemu, co jest właściwe, gdy maszyna już tam centralizuje swoją sieć. Alternatywnie dedykowana jednostka systemd uruchamia VPN bezpośrednio i sama posiada interfejs.

systemctl list-unit-files 'openvpn*'
systemctl list-unit-files 'wg-quick*'
nmcli connection show --active
systemctl enable --now wg-quick@wg0

Nie uruchamiaj obu właścicieli na jednej konfiguracji. Jeśli NetworkManager zarządza interfejsem, a jednostka też go podnosi, będą walczyć o trasy i DNS, a wynikowy stan zależy od tego, kto skończył ostatni.

Połóż sekret tam, gdzie usługa może go przeczytać

Usługa w tle nie może odpowiedzieć na monit. Hasła certyfikatów, hasła kont i wskazane pliki uwierzytelniania potrzebują takiego układu przechowywania, do którego jednostka dotrze bez człowieka, który należy do konta uruchamiającego usługę i jest nieczytelny dla wszystkich innych.

Kuszącym skrótem jest uczynienie pliku czytelnym dla wszystkich, aż zniknie błąd uprawnień. To wymienia niepowodzenie startu na długotrwałe ujawnienie poświadczeń i jest to rodzaj zmiany, do której nikt nie wraca. Użyj mechanizmu, któremu wdrożenie już ufa: ograniczonego pliku poświadczeń, niezaszyfrowanego klucza chronionego uprawnieniami pliku lub połączenia w skali systemu z własnym magazynem sekretów.

Przetestuj zdarzenie, które naprawdę zachodzi

Ręczne uruchomienie usługi po zalogowaniu nie testuje prawie niczego. Zrestartuj lub wyłącz logowanie graficzne na jeden cykl i patrz, jak jednostka podnosi się sama. To jedyny test, który jednocześnie ćwiczy dostępność poświadczeń, gotowość sieci i kolejność jednostek. To także test, który odtwarza awarię zgłoszoną przez użytkownika, czego ręczny start nigdy nie robi.

systemctl is-enabled wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager
systemctl status systemd-networkd-wait-online --no-pager

Kolejność jest równie ważna jak poświadczenia. Jednostka, która startuje, zanim skonfigurowane jest podstawowe łącze wyjściowe, podda się, a niektóre dystrybucje różnią się tym, czy czekają na łączność. Jeśli jednostka zgłasza błąd przy starcie, ale udaje się, gdy uruchomisz ją ręcznie trzydzieści sekund później, znalazłeś problem kolejności, a nie problem sekretu.

Sprawdzaj trasy i DNS, nie tylko interfejs

Istniejący interfejs to nie działający tunel. Po niemonitorowanym starcie sprawdź trasy, stan resolvera i jeden cel po adresie, zanim sprawdzisz nazwę. Potem sprawdź aplikację, dla której tunel istnieje.

ip -4 route show
resolvectl status
ping -c 3 10.61.0.1
curl -sS --max-time 5 https://internal.example/ -o /dev/null -w '%{http_code}\n'

Jeśli adres działa, a nazwa nie, pozostałym problemem jest polityka DNS, a nie tunel. Zapisz, który właściciel uruchamia usługę i gdzie mieszka sekret, bo następna osoba, która zrestartuje tę maszynę, będzie potrzebować obu faktów.

Powiązane artykuły