Dlaczego usługa VPN uruchamiana przy starcie nie może odczytać twojego pęku kluczy

Połączenie, które działa po zalogowaniu, a przed nim zawodzi, zwykle oznacza, że próba przy starcie nie zdołała uzyskać sekretu, a nie że serwer go odrzucił. Poświadczenie istnieje; kontekst, który o nie prosi, nie. Ta jedna różnica oszczędza niepotrzebny reset hasła.

Prześledź żądanie: coś uruchamia połączenie, zanim istnieje sesja pulpitu, a magazyn sekretów, który zwykle odpowiada, nie jest jeszcze odblokowany. Oba konteksty nie zgadzają się co do tego, kto posiada sekret, a profil zapisuje, który z nich ma go dostarczyć.

Czego naprawdę żąda ścieżka startowa

Przy starcie NetworkManager uruchamia się jako usługa systemowa bez sesji użytkownika, bez sesyjnego D-Bus i bez odblokowanego pęku kluczy. Profil połączenia nadal można podnieść, ale tylko z sekretami, do których usługa dotrze sama. Wszystko, co należy do agenta sekretów, czeka, aż człowiek się zaloguje i agent się pojawi. Usługa robi dokładnie to, co mówi jej konfiguracja; zmienić trzeba profil.

Awaria jest zapisana w połączeniu, a nie ukryta w pęku kluczy.

Odczyt flag sekretów na połączeniu

Zapytaj połączenie, czego oczekuje, a nie co pamięta pulpit. Kolumna flag odpowiada na pytanie wprost i przetrwa restarty w pliku profilu na dysku.

Zacznij od listy profili, potem potwierdź, które połączenie jest ustawione na samodzielne podnoszenie się. Następnie wyeksportuj jedno połączenie i odczytaj flagi hasła:

nmcli -f NAME,UUID,TYPE,AUTOCONNECT connection show
nmcli connection show "Work VPN" | grep -i -E "password|secret|key"
journalctl -b -u NetworkManager --grep "secret"

Pierwsze polecenie potwierdza, które profile istnieją i czy któryś jest ustawiony na automatyczne łączenie, właśnie tak zaczyna się próba bez nadzoru. Drugie ujawnia wartości flag, a trzecie pokazuje usługę skarżącą się, że żaden agent nie odpowiedział za dany sekret. Linia dziennika nazywająca sekret własnością agenta to cała diagnoza w jednym zdaniu.

Dlaczego przeniesienie połączenia do zakresu systemowego zmienia odpowiedź

Połączenie należące do użytkownika jest aktywowane pod agentem tego użytkownika, dlatego działa bezbłędnie, gdy tylko pulpit jest gotowy. Przeniesienie go do zakresu systemowego usuwa agenta ze ścieżki, więc ten sam profil zachowuje się inaczej bez zmiany choćby jednej linii konfiguracji VPN.

To przeniesienie jest uzasadnionym projektem i niesie wymóg: sekret musi być osiągalny dla usługi systemowej. Przechowywanie go w profilu, dostarczanie przez poświadczenie w zakresie systemowym albo zaakceptowanie interaktywnego monitu w odpowiednim momencie to wszystkie prawidłowe odpowiedzi. Zostawienie flagi 1 i nadzieja — nie.

Klucz prywatny z własną frazą hasła dodaje drugą warstwę. Nawet zapisane hasło konta nie odblokuje klucza, który wymaga frazy hasła, więc zanim cokolwiek zmienisz, sprawdź, którego sekretu faktycznie żąda zawodzący etap.

Czego nie robić i co robić zamiast tego

Uczynienie każdego pliku poświadczeń czytelnym dla wszystkich albo wyłączenie uwierzytelniania, żeby monit nie był potrzebny, zamienia niedogodność startu na trwałe wystawienie. Oba rozwiązania także ukrywają zależność zamiast ją rozwiązywać, a następna aktualizacja obrazu przywraca ten sam błąd.

Na tym etapie użyj mechanizmu, który twoja dystrybucja dokumentuje dla aktywacji bez nadzoru, a potem potwierdź, że flagi profilu są z nim zgodne. Sprawdź wynik z czystego startu, a nie z powłoki, która ma już agenta. Zapisz właściciela połączenia, źródło sekretu i etap, który musi działać, aby późniejsza zmiana autostartu nie mogła po cichu przywrócić zależności od tego, że ktoś najpierw odblokuje pulpit. Dokumentacja to różnica między naprawioną usługą a tą, która znów się psuje w następnym kwartale.

Testuj z kontrolowanego czystego startu, a nie z ręcznej ponownej próby po zalogowaniu. Ponowna próba się udaje z powodu, dla którego próba przy starcie zawiodła, i to jest dokładnie ten dowód, który szybki test niszczy.