Kvifor ei VPN-teneste som startar ved oppstart ikkje kan lesa nøkkelringen din

Ei tilkopling som verkar etter innlogging og sviktar før, tyder vanlegvis at oppstartforsøket ikkje fekk tak i ein hemmelegheit, ikkje at tenaren avviste ei. Legitimasjonen finst; konteksten som ber om han, gjer det ikkje. Den eine skilnaden sparer ei unødvendig nullstilling av passordet.

Fylg førespurnaden: noko startar tilkoplinga før ei skrivebordsøkt finst, og hemmelegheitslageret som vanlegvis svarar, er enno ikkje låst opp. Dei to kontekstane er usamde om kven som eig hemmelegheita, og profilen registrerer kven av dei som er venta å levera henne.

Kva oppstartstien faktisk ber om

Ved oppstart startar NetworkManager som ei systemteneste utan brukarøkt, utan økt-D-Bus og utan opplåst nøkkelring. Ein tilkoplingsprofil kan likevel reisast, men berre med hemmelegheiter tenesta sjølv kan nå. Alt som er eigd av ein hemmelegheitsagent, ventar til eit menneske loggar inn og agenten dukkar opp. Tenesta gjer nøyaktig det konfigurasjonen seier; profilen er det som må endrast.

Feilen er skriven inn i tilkoplinga i staden for gøymd i ein nøkkelring.

Lesa hemmelegheitsflaggene på ei tilkopling

Spør tilkoplinga kva ho ventar, ikkje kva skrivebordet hugsar. Flaggkolonnen svarar direkte på spørsmålet, og han overlever omstartar i profilfila på disken.

Byrja med profillista, og stadfest deretter kva tilkopling som er sett til å reisa seg sjølv. Deretter dump éi tilkopling og les 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 stadfestar kva profilar som finst og om ein er sett til automatisk tilkopling, som er måten eit uovervaka forsøk i det heile startar. Den andre avdekkjer flaggverdiane, og den tredje viser tenesta klaga over at ingen agent svara for ei gitt hemmelegheit. Ei logglinje som kallar ei hemmelegheit agent-eigd, er heile diagnosen i éin setning.

Kvifor flytting av tilkoplinga til systemomfang endrar svaret

Ei tilkopling som er eigd av ein brukar, vert aktivert under agenten til den brukaren, og difor verkar ho perfekt når skrivebordet er oppe. Å flytta henne til systemomfang fjernar agenten frå stien, slik at same profil oppfører seg annleis utan at éi linje VPN-konfigurasjon vert endra.

Den flyttinga er eit legitimt design, og ho ber eit krav: hemmelegheita må vera tilgjengeleg for systemtenesta. Å lagra henne i profilen, levera henne via ein legitimasjon i systemomfang eller godta ein interaktiv førespurnad i rett augneblink er alle gyldige svar. Å la flagg 1 stå og håpa er det ikkje.

Ein privat nøkkel med eigen passfrase legg til eit andre lag. Sjølv eit lagra kontopassord låser ikkje opp ein nøkkel som vil ha ein passfrase, så verifiser kva hemmelegheit det sviktande trinnet faktisk ber om før du endrar noko.

Kva du ikkje bør gjera, og kva du bør gjera i staden

Å gjera kvar legitimasjonsfil lesbar for alle, eller å slå av autentisering så ingen førespurnad trengst, byter ein ulempe ved oppstart mot ei permanent eksponering. Begge gøymer òg avhengnaden i staden for å løysa han, og neste bildeoppdatering gjeninnfører same feilen.

Bruk på det trinnet mekanismen distribusjonen din dokumenterer for uovervaka aktivering, og stadfest deretter at flagga til profilen stemmer med han. Kontroller resultatet frå ein rein oppstart, ikkje frå eit skal som allereie har ein agent. Skriv ned eigaren av tilkoplinga, kjelda til hemmelegheita og trinnet som må verka, slik at ei seinare endring av autostart ikkje stille kan gjeninnføra ein avhengnad av at nokon først låser opp eit skrivebord. Dokumentasjon er skilnaden mellom ei reparert teneste og ei som ryker igjen neste kvartal.

Test frå ein kontrollert rein oppstart i staden for eit manuelt nytt forsøk etter innlogging. Det nye forsøket lukkast av grunnen til at oppstartforsøket svikta, og det er nettopp beviset ein rask test øydelegg.