Proč služba VPN spuštěná při startu nemůže přečíst vaši klíčenku

Připojení, které po přihlášení funguje a před ním selhává, obvykle znamená, že pokus při startu nedokázal získat tajemství, ne že by ho server odmítl. Přihlašovací údaj existuje; kontext, který ho žádá, ne. Tento jediný rozdíl ušetří zbytečný reset hesla.

Sledujte požadavek: něco spustí připojení dřív, než existuje relace pracovní plochy, a úložiště tajemství, které obvykle odpovídá, ještě není odemčené. Oba kontexty se neshodnou na tom, komu tajemství patří, a profil zaznamenává, který z nich ho má dodat.

Co startovní cesta skutečně žádá

Při startu se NetworkManager spouští jako systémová služba bez uživatelské relace, bez relace D-Bus a bez odemčené klíčenky. Profil připojení lze přesto zvednout, ale jen s tajemstvími, ke kterým se služba dostane sama. Cokoli vlastní agent tajemství, čeká, dokud se člověk nepřihlásí a agent se neobjeví. Služba dělá přesně to, co říká její konfigurace; měnit se musí profil.

Selhání je zapsané v připojení, ne skryté v klíčence.

Čtení příznaků tajemství u připojení

Zeptejte se připojení, co očekává, ne co si pamatuje pracovní plocha. Sloupec příznaků odpovídá na otázku přímo a přežije restartování v souboru profilu na disku.

Začněte seznamem profilů, pak ověřte, které připojení je nastaveno, aby se zvedlo samo. Potom vypište jedno připojení a přečtěte příznaky hesla:

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"

První příkaz potvrdí, které profily existují a zda je některý nastaven na automatické připojení, což je způsob, jakým se pokus bez dozoru vůbec spustí. Druhý odhalí hodnoty příznaků a třetí ukazuje, jak si služba stěžuje, že žádný agent neodpověděl za dané tajemství. Řádek protokolu, který tajemství označí jako vlastněné agentem, je celá diagnóza v jedné větě.

Proč přesun připojení do systémového rozsahu mění odpověď

Připojení vlastněné uživatelem se aktivuje pod agentem toho uživatele, a proto funguje bezchybně, jakmile je pracovní plocha nahoře. Přesun do systémového rozsahu odstraní agenta z cesty, takže stejný profil se chová jinak, aniž by se změnil jediný řádek konfigurace VPN.

Tento přesun je legitimní návrh a nese požadavek: tajemství musí být pro systémovou službu dostupné. Uložení v profilu, poskytnutí přes přihlašovací údaj systémového rozsahu nebo přijetí interaktivní výzvy ve správný okamžik jsou všechny platné odpovědi. Ponechat příznak 1 a doufat, že to vyjde, ne.

Soukromý klíč s vlastní passphrase přidává druhou vrstvu. Ani uložené heslo účtu neodemkne klíč, který chce passphrase, takže před jakoukoli změnou ověřte, které tajemství selhávající fáze skutečně žádá.

Co nedělat a co dělat místo toho

Udělat každý soubor s přihlašovacími údaji čitelným pro všechny, nebo vypnout ověřování, aby nebyla potřeba výzva, mění nepohodlí při startu za trvalé vystavení. Obojí také závislost skrývá, místo aby ji řešilo, a další aktualizace image vrátí stejné selhání.

V této fázi použijte mechanismus, který vaše distribuce dokumentuje pro aktivaci bez dozoru, a potom ověřte, že příznaky profilu odpovídají. Zkontrolujte výsledek z čistého startu, ne z shellu, který už agenta má. Zapište vlastníka připojení, zdroj tajemství a fázi, která musí fungovat, aby pozdější změna automatického spouštění nemohla tiše vrátit závislost na tom, že někdo nejprve odemkne pracovní plochu. Dokumentace je rozdíl mezi opravenou službou a službou, která se příští čtvrtletí znovu rozbije.

Testujte z řízeného čistého startu, ne z ručního opakování po přihlášení. Opakování uspěje z důvodu, proč pokus při startu selhal, a to je přesně ten důkaz, který rychlý test zničí.