Waarom een VPN-dienst die bij het opstarten start je sleutelring niet kan lezen
Een VPN bij het opstarten heeft geen ontgrendelde geheimenagent om van te lenen. Lees de geheimevlaggen van de verbinding voordat je een wachtwoord reset dat de server nooit heeft geweigerd.
Een verbinding die na het inloggen werkt en daarvoor faalt, betekent meestal dat de opstartpoging geen geheim kon verkrijgen, niet dat de server er een heeft geweigerd. De inloggegevens bestaan; de context die erom vraagt niet. Dat ene onderscheid bespaart een onnodige wachtwoordreset.
Volg het verzoek: iets start de verbinding voordat er een desktopsessie bestaat, en de geheimenopslag die normaal antwoordt, is nog niet ontgrendeld. De twee contexten zijn het er niet over eens wie het geheim bezit, en het profiel legt vast welke van hen het hoort te leveren.
Wat het opstartpad feitelijk vraagt
Bij het opstarten start NetworkManager als systeemdienst zonder gebruikerssessie, zonder sessie-D-Bus en zonder ontgrendelde sleutelring. Een verbindingsprofiel kan nog steeds worden opgezet, maar alleen met geheimen die de dienst zelf kan bereiken. Alles wat eigendom is van een geheimenagent blijft wachten tot een mens inlogt en de agent verschijnt. De dienst doet precies wat zijn configuratie zegt; het profiel is wat moet veranderen.
De fout staat in de verbinding geschreven in plaats van verborgen in een sleutelring.
De geheimevlaggen op een verbinding lezen
Vraag de verbinding wat hij verwacht, niet wat de desktop onthoudt. De vlaggenkolom beantwoordt de vraag direct, en hij overleeft herstarts in het profielbestand op schijf.
Begin met de profiellijst en bevestig dan welke verbinding is ingesteld om vanzelf op te komen. Dump daarna één verbinding en lees de wachtwoordvlaggen:
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"
Het eerste commando bevestigt welke profielen bestaan en of er een op automatisch verbinden staat, wat de manier is waarop een onbeheerde poging überhaupt begint. Het tweede legt de vlagwaarden bloot, en het derde toont de dienst klagen dat geen agent voor een bepaald geheim antwoordde. Een logregel die een geheim agent-eigendom noemt, is de hele diagnose in één zin.
| 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 |
Waarom de verbinding naar systeembereik verplaatsen het antwoord verandert
Een verbinding die eigendom is van een gebruiker wordt onder de agent van die gebruiker geactiveerd, daarom werkt hij perfect zodra de desktop actief is. Verplaatsen naar systeembereik haalt de agent uit het pad, dus hetzelfde profiel gedraagt zich anders zonder dat één regel VPN-configuratie verandert.
Die verplaatsing is een legitiem ontwerp, en zij brengt een vereiste mee: het geheim moet bereikbaar zijn voor de systeemdienst. Het in het profiel opslaan, het leveren via een inloggegeven in systeembereik of het accepteren van een interactieve prompt op het juiste moment zijn alle geldige antwoorden. Vlag 1 laten staan en hopen is dat niet.
Een privésleutel met een eigen wachtwoordzin voegt een tweede laag toe. Zelfs een opgeslagen accountwachtwoord ontgrendelt geen sleutel die een wachtwoordzin wil, dus controleer welk geheim de falende fase werkelijk vraagt voordat je iets verandert.
Wat je niet moet doen, en wat je in plaats daarvan moet doen
Elk inloggegevensbestand voor iedereen leesbaar maken, of authenticatie uitschakelen zodat geen prompt nodig is, ruilt een opstartongemak in voor een permanente blootstelling. Beide verbergen ook de afhankelijkheid in plaats van haar op te lossen, en de volgende image-update brengt dezelfde fout terug.
Gebruik in die fase het mechanisme dat je distributie documenteert voor onbeheerde activering, en bevestig dan dat de vlaggen van het profiel daarmee overeenkomen. Controleer het resultaat vanaf een schone opstart, niet vanuit een shell die al een agent heeft. Schrijf de verbindingseigenaar, de bron van het geheim en de fase die moet werken op, zodat een latere wijziging van de autostart niet stilzwijgend een afhankelijkheid kan herintroduceren van iemand die eerst een desktop ontgrendelt. Documentatie is het verschil tussen een gerepareerde dienst en een die volgend kwartaal weer breekt.
Test vanaf een gecontroleerde schone opstart in plaats van een handmatige nieuwe poging na het inloggen. De nieuwe poging slaagt om de reden waarom de opstartpoging faalde, en dat is precies het bewijs dat een snelle test vernietigt.