Prečo služba VPN spustená pri štarte nemôže prečítať tvoj zväzok kľúčov

Pripojenie, ktoré funguje po prihlásení a pred ním zlyháva, zvyčajne znamená, že pokus pri štarte nedokázal získať tajomstvo, a nie že ho server odmietol. Prihlasovací údaj existuje; kontext, ktorý ho žiada, nie. Tento jediný rozdiel ušetrí zbytočný reset hesla.

Sleduj požiadavku: niečo spustí pripojenie skôr, než existuje relácia pracovnej plochy, a úložisko tajomstiev, ktoré zvyčajne odpovedá, ešte nie je odomknuté. Oba kontexty sa nezhodujú v tom, komu tajomstvo patrí, a profil zaznamenáva, ktorý z nich ho má dodať.

Čo štartová cesta skutočne žiada

Pri štarte sa NetworkManager spúšťa ako systémová služba bez používateľskej relácie, bez relácie D-Bus a bez odomknutého zväzku kľúčov. Profil pripojenia sa dá napriek tomu zdvihnúť, ale iba s tajomstvami, ku ktorým sa služba dostane sama. Čokoľvek vlastní agent tajomstiev, čaká, kým sa človek prihlási a agent sa objaví. Služba robí presne to, čo hovorí jej konfigurácia; meniť treba profil.

Zlyhanie je zapísané v pripojení, nie skryté vo zväzku kľúčov.

Čítanie príznakov tajomstiev na pripojení

Opýtaj sa pripojenia, čo očakáva, nie čo si pamätá pracovná plocha. Stĺpec príznakov odpovedá na otázku priamo a prežije reštarty v profile na disku.

Začni zoznamom profilov, potom over, ktoré pripojenie je nastavené zdvihnúť sa samo. Potom vypíš jedno pripojenie a prečítaj prí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"

Prvý príkaz overí, ktoré profily existujú a či je niektorý nastavený na automatické pripojenie, čím sa pokus bez dozoru vôbec začína. Druhý odhalí hodnoty príznakov a tretí ukazuje službu sťažujúcu sa, že žiadny agent neodpovedal za dané tajomstvo. Riadok protokolu, ktorý nazve tajomstvo vlastníctvom agenta, je celá diagnóza v jednej vete.

Prečo presun pripojenia do systémového rozsahu mení odpoveď

Pripojenie vlastnené používateľom sa aktivuje pod agentom toho používateľa, preto funguje bezchybne hneď, ako je pracovná plocha hore. Presun do systémového rozsahu odstráni agenta z cesty, takže ten istý profil sa správa inak bez zmeny jediného riadku konfigurácie VPN.

Tento presun je legitímny návrh a nesie požiadavku: tajomstvo musí byť dostupné pre systémovú službu. Uloženie v profile, poskytnutie cez prihlasovací údaj v systémovom rozsahu alebo prijatie interaktívnej výzvy v správnom okamihu sú všetky platné odpovede. Nechať príznak 1 a dúfať, že to vyjde, nie.

Súkromný kľúč s vlastnou heslovou frázou pridáva druhú vrstvu. Ani uložené heslo účtu neodomkne kľúč, ktorý chce heslovú frázu, preto pred akoukoľvek zmenou over, ktoré tajomstvo zlyhávajúca fáza skutočne žiada.

Čo nerobiť a čo robiť namiesto toho

Urobiť každý súbor s prihlasovacími údajmi čitateľným pre všetkých alebo vypnúť overovanie, aby nebola potrebná výzva, vymieňa nepríjemnosť pri štarte za trvalé vystavenie. Oboje tiež závislosť skrýva namiesto toho, aby ju riešilo, a ďalšia aktualizácia obrazu vráti to isté zlyhanie.

V tejto fáze použi mechanizmus, ktorý tvoja distribúcia dokumentuje pre aktiváciu bez dozoru, a potom over, že príznaky profilu mu zodpovedajú. Skontroluj výsledok z čistého štartu, nie z shellu, ktorý už má agenta. Zapíš vlastníka pripojenia, zdroj tajomstva a fázu, ktorá musí fungovať, aby neskoršia zmena automatického spúšťania nemohla potichu vrátiť závislosť od toho, že niekto najprv odomkne pracovnú plochu. Dokumentácia je rozdiel medzi opravenou službou a tou, ktorá sa budúci štvrťrok znova pokazí.

Testuj z riadeného čistého štartu, nie z ručného opakovania po prihlásení. Opakovanie uspeje z dôvodu, prečo pokus pri štarte zlyhal, a to je presne ten dôkaz, ktorý rýchly test zničí.