Hvorfor en VPN-tjeneste, der starter ved opstart, ikke kan læse din nøglering

En forbindelse, der virker efter login og fejler før det, betyder normalt, at opstartsforsøget ikke kunne skaffe en hemmelighed, ikke at serveren afviste en. Legitimationsoplysningen findes; den kontekst, der beder om den, gør ikke. Den ene forskel sparer en unødvendig nulstilling af adgangskoden.

Følg anmodningen: noget starter forbindelsen, før der findes en skrivebordssession, og det hemmelighedslager, der normalt svarer, er endnu ikke låst op. De to kontekster er uenige om, hvem der ejer hemmeligheden, og profilen registrerer, hvilken af dem der forventes at levere den.

Hvad opstartsstien egentlig beder om

Ved opstart starter NetworkManager som en systemtjeneste uden brugersession, uden session-D-Bus og uden en oplåst nøglering. En forbindelsesprofil kan stadig rejses, men kun med hemmeligheder, som tjenesten selv kan nå. Alt, der ejes af en hemmelighedsagent, venter, indtil et menneske logger ind, og agenten dukker op. Tjenesten gør præcis, hvad dens konfiguration siger; profilen er det, der skal ændres.

Fejlen er skrevet ind i forbindelsen i stedet for skjult i en nøglering.

Læs hemmelighedsflagene på en forbindelse

Spørg forbindelsen, hvad den forventer, ikke hvad skrivebordet husker. Flagkolonnen svarer direkte på spørgsmålet, og den overlever genstart i profilfilen på disken.

Start med profillisten, og bekræft derefter, hvilken forbindelse der er sat til at rejse sig selv. Dump så én forbindelse, og læs adgangskodeflagene:

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 kommando bekræfter, hvilke profiler der findes, og om en er sat til automatisk forbindelse, hvilket er måden, hvorpå et uovervåget forsøg overhovedet starter. Den anden afslører flagværdierne, og den tredje viser tjenesten klage over, at ingen agent svarede for en given hemmelighed. En loglinje, der kalder en hemmelighed agent-ejet, er hele diagnosen i én sætning.

Hvorfor flytning af forbindelsen til systemomfang ændrer svaret

En forbindelse, der ejes af en bruger, aktiveres under den brugers agent, og derfor virker den perfekt, når skrivebordet er oppe. At flytte den til systemomfang fjerner agenten fra stien, så den samme profil opfører sig anderledes uden at en eneste linje VPN-konfiguration ændres.

Den flytning er et legitimt design, og den bærer et krav: hemmeligheden skal være tilgængelig for systemtjenesten. At gemme den i profilen, levere den via en legitimationsoplysning i systemomfang eller acceptere en interaktiv prompt på det rigtige tidspunkt er alle gyldige svar. At lade flag 1 stå og håbe er det ikke.

En privat nøgle med sin egen adgangsfrase tilføjer et andet lag. Selv en gemt kontoadgangskode låser ikke en nøgle op, der kræver en adgangsfrase, så verificér, hvilken hemmelighed det fejlende trin faktisk beder om, før du ændrer noget.

Hvad du ikke skal gøre, og hvad du skal gøre i stedet

At gøre hver legitimationsfil læsbar for alle eller slå godkendelse fra, så ingen prompt er nødvendig, bytter en ulejlighed ved opstart for en permanent eksponering. Begge skjuler også afhængigheden i stedet for at løse den, og den næste imageopdatering genindfører den samme fejl.

Brug den mekanisme, din distribution dokumenterer til uovervåget aktivering på det trin, og bekræft derefter, at profilens flag passer til den. Kontrollér resultatet fra en ren opstart i stedet for fra en shell, der allerede har en agent. Skriv forbindelsesejeren, hemmelighedens kilde og det trin, der skal virke, ned, så en senere ændring af autostart ikke stille kan genindføre en afhængighed af, at nogen først låser et skrivebord op. Dokumentation er forskellen mellem en rettet tjeneste og en, der går i stykker igen næste kvartal.

Test fra en kontrolleret ren opstart i stedet for et manuelt nyt forsøg efter login. Det nye forsøg lykkes af den grund, at opstartsforsøget fejlede, og det er præcis det bevis, en hurtig test ødelægger.