Hvorfor en VPN-tjeneste som starter ved boot ikke kan lese nøkkelringen din

En tilkobling som fungerer etter pålogging og feiler før, betyr som regel at oppstartsforsøket ikke klarte å skaffe en hemmelighet, ikke at tjeneren avviste en. Legitimasjonen finnes; konteksten som ber om den, gjør det ikke. Den ene forskjellen sparer en unødvendig tilbakestilling av passordet.

Følg forespørselen: noe starter tilkoblingen før en skrivebordsøkt eksisterer, og hemmelighetslageret som vanligvis svarer, er ikke låst opp ennå. De to kontekstene er uenige om hvem som eier hemmeligheten, og profilen registrerer hvem av dem som forventes å levere den.

Hva oppstartsstien egentlig ber om

Ved oppstart starter NetworkManager som en systemtjeneste uten brukerøkt, uten økt-D-Bus og uten opplåst nøkkelring. En tilkoblingsprofil kan fortsatt reises, men bare med hemmeligheter tjenesten selv kan nå. Alt som eies av en hemmelighetsagent, venter til et menneske logger på og agenten dukker opp. Tjenesten gjør nøyaktig det konfigurasjonen sier; profilen er det som må endres.

Feilen er skrevet inn i tilkoblingen i stedet for skjult i en nøkkelring.

Lese hemmelighetsflaggene på en tilkobling

Spør tilkoblingen hva den forventer, ikke hva skrivebordet husker. Flaggkolonnen svarer direkte på spørsmålet, og den overlever omstarter i profilfilen på disken.

Begynn med profillisten, og bekreft deretter hvilken tilkobling som er satt til å reise seg selv. Deretter dumper du én tilkobling og leser passordflaggene:

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"

Den første kommandoen bekrefter hvilke profiler som finnes og om én er satt til automatisk tilkobling, som er måten et uovervåket forsøk i det hele tatt starter. Den andre avdekker flaggverdiene, og den tredje viser tjenesten klage over at ingen agent svarte for en gitt hemmelighet. En logglinje som kaller en hemmelighet agent-eid, er hele diagnosen i én setning.

Hvorfor flytting av tilkoblingen til systemomfang endrer svaret

En tilkobling som eies av en bruker, aktiveres under den brukerens agent, og derfor virker den perfekt når skrivebordet er oppe. Å flytte den til systemomfang fjerner agenten fra stien, slik at samme profil oppfører seg annerledes uten at én linje VPN-konfigurasjon endres.

Den flyttingen er et legitimt design, og den bærer et krav: hemmeligheten må være tilgjengelig for systemtjenesten. Å lagre den i profilen, levere den via en legitimasjon i systemomfang eller godta en interaktiv forespørsel i rett øyeblikk er alle gyldige svar. Å la flagg 1 stå og håpe er det ikke.

En privat nøkkel med egen passfrase legger til et andre lag. Selv et lagret kontopassord låser ikke opp en nøkkel som vil ha en passfrase, så verifiser hvilken hemmelighet det feilende trinnet faktisk ber om før du endrer noe.

Hva du ikke bør gjøre, og hva du bør gjøre i stedet

Å gjøre hver legitimasjonsfil lesbar for alle, eller å slå av autentisering så ingen forespørsel trengs, bytter en ulempe ved oppstart mot en permanent eksponering. Begge skjuler også avhengigheten i stedet for å løse den, og neste bildeoppdatering gjeninnfører samme feil.

Bruk på det trinnet mekanismen distribusjonen din dokumenterer for uovervåket aktivering, og bekreft deretter at profilens flagg stemmer med den. Kontroller resultatet fra en ren oppstart, ikke fra et skall som allerede har en agent. Skriv ned tilkoblingens eier, hemmelighetens kilde og trinnet som må virke, slik at en senere endring av autostart ikke stille kan gjeninnføre en avhengighet av at noen først låser opp et skrivebord. Dokumentasjon er forskjellen mellom en reparert tjeneste og en som ryker igjen neste kvartal.

Test fra en kontrollert ren oppstart i stedet for et manuelt nytt forsøk etter pålogging. Det nye forsøket lykkes av grunnen til at oppstartsforsøket feilet, og det er nettopp beviset en rask test ødelegger.