De ce un serviciu VPN pornit la boot nu poate citi inelul tău de chei
Un VPN la boot nu are niciun agent de secrete deblocat de la care să împrumute. Citește fanioanele de secret ale conexiunii înainte de a reseta o parolă pe care serverul nu a respins-o niciodată.
O conexiune care funcționează după autentificare și eșuează înainte înseamnă de obicei că încercarea de la boot nu a putut obține un secret, nu că serverul a respins unul. Acreditarea există; contextul care o cere, nu. Această singură distincție economisește o resetare inutilă a parolei.
Urmărește cererea: ceva pornește conexiunea înainte să existe o sesiune de desktop, iar depozitul de secrete care răspunde de obicei nu este încă deblocat. Cele două contexte nu sunt de acord asupra cui aparține secretul, iar profilul înregistrează care dintre ele ar trebui să îl furnizeze.
Ce cere de fapt calea de boot
La boot, NetworkManager pornește ca serviciu de sistem fără sesiune de utilizator, fără D-Bus de sesiune și fără inel de chei deblocat. Un profil de conexiune poate fi totuși ridicat, dar numai cu secrete la care serviciul poate ajunge singur. Orice aparține unui agent de secrete așteaptă până când o persoană se autentifică și agentul apare. Serviciul face exact ce spune configurația lui; profilul este cel care trebuie schimbat.
Eșecul este scris în conexiune, nu ascuns într-un inel de chei.
Citirea fanioanelor de secret pe o conexiune
Întreabă conexiunea ce așteaptă, nu ce își amintește desktopul. Coloana de fanioane răspunde direct la întrebare și supraviețuiește repornirilor în fișierul de profil de pe disc.
Începe cu lista de profiluri, apoi confirmă ce conexiune este setată să se ridice singură. Apoi exportă o conexiune și citește fanioanele de parolă:
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"
Prima comandă confirmă ce profiluri există și dacă unul este setat pentru conectare automată, ceea ce este modul în care începe deloc o încercare nesupravegheată. A doua expune valorile fanioanelor, iar a treia arată serviciul plângându-se că niciun agent nu a răspuns pentru un anumit secret. O linie de jurnal care numește un secret ca aparținând agentului este întregul diagnostic într-o propoziție.
| Flag value | Where the secret lives | Behaviour before login |
|---|---|---|
| 0 | Stored in the connection profile | Available to the system service |
| 1 | Owned by a secret agent | Blocks until the agent is unlocked |
| 2 | Never stored | Prompts on every activation |
| 4 | Not required | Never requested at all |
De ce mutarea conexiunii în domeniul de sistem schimbă răspunsul
O conexiune deținută de un utilizator este activată sub agentul acelui utilizator, de aceea funcționează perfect odată ce desktopul este pornit. Mutarea ei în domeniul de sistem scoate agentul din cale, așa că același profil se comportă diferit fără ca o singură linie de configurare VPN să se schimbe.
Această mutare este un design legitim și aduce o cerință: secretul trebuie să fie accesibil serviciului de sistem. Stocarea lui în profil, furnizarea printr-o acreditare de domeniu de sistem sau acceptarea unei solicitări interactive la momentul potrivit sunt toate răspunsuri valide. A lăsa fanionul 1 și a spera, nu.
O cheie privată cu propria frază de acces adaugă un al doilea strat. Nici măcar o parolă de cont stocată nu va debloca o cheie care cere o frază de acces, așa că verifică ce secret cere de fapt etapa care eșuează înainte de a schimba ceva.
Ce să nu faci și ce să faci în schimb
A face fiecare fișier de acreditări lizibil pentru toată lumea, sau a dezactiva autentificarea ca să nu fie nevoie de nicio solicitare, schimbă un inconvenient la pornire pe o expunere permanentă. Ambele ascund și dependența în loc să o rezolve, iar următoarea actualizare a imaginii readuce același eșec.
În acea etapă folosește mecanismul pe care distribuția ta îl documentează pentru activare nesupravegheată, apoi confirmă că fanioanele profilului corespund. Verifică rezultatul dintr-un boot curat, nu dintr-un shell care are deja un agent. Notează proprietarul conexiunii, sursa secretului și etapa care trebuie să funcționeze, astfel încât o modificare ulterioară a pornirii automate să nu poată reintroduce în tăcere o dependență de cineva care deblochează mai întâi un desktop. Documentația este diferența dintre un serviciu reparat și unul care se strică din nou trimestrul viitor.
Testează dintr-un boot curat controlat, nu dintr-o reîncercare manuală după autentificare. Reîncercarea reușește din motivul pentru care încercarea de la boot a eșuat, și exact aceea este dovada pe care un test rapid o distruge.