Varför en VPN-tjänst som startas vid boot inte kan läsa din nyckelring

En anslutning som fungerar efter inloggning och misslyckas före den betyder oftast att försöket vid uppstart inte kunde hämta en hemlighet, inte att servern avvisade en. Uppgifterna finns; sammanhanget som begär dem gör det inte. Den enda skillnaden sparar en onödig återställning av lösenordet.

Följ begäran: något startar anslutningen innan en skrivbordssession finns, och hemlighetslagret som normalt svarar är ännu inte upplåst. De två sammanhangen är oeniga om vem som äger hemligheten, och profilen registrerar vilken av dem som förväntas leverera den.

Vad uppstartsvägen faktiskt begär

Vid uppstart startar NetworkManager som en systemtjänst utan användarsession, utan sessions-D-Bus och utan upplåst nyckelring. En anslutningsprofil kan ändå resas, men bara med hemligheter som tjänsten själv kan nå. Allt som ägs av en hemlighetsagent väntar tills en människa loggar in och agenten dyker upp. Tjänsten gör exakt vad konfigurationen säger; profilen är det som måste ändras.

Felet är inskrivet i anslutningen i stället för dolt i en nyckelring.

Läsa hemlighetsflaggorna på en anslutning

Fråga anslutningen vad den förväntar sig, inte vad skrivbordet kommer ihåg. Flaggkolumnen svarar direkt på frågan, och den överlever omstarter i profilfilen på disken.

Börja med profillistan och bekräfta sedan vilken anslutning som är inställd att resa sig själv. Därefter dumpar du en anslutning och läser lösenordsflaggorna:

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"

Det första kommandot bekräftar vilka profiler som finns och om en är inställd på automatisk anslutning, vilket är hur ett oövervakat försök överhuvudtaget börjar. Det andra avslöjar flaggvärdena, och det tredje visar tjänsten klaga över att ingen agent svarade för en viss hemlighet. En logglinje som kallar en hemlighet agentägd är hela diagnosen i en mening.

Varför flytten av anslutningen till systemomfång ändrar svaret

En anslutning som ägs av en användare aktiveras under den användarens agent, därför fungerar den perfekt så snart skrivbordet är uppe. Att flytta den till systemomfång tar bort agenten från vägen, så samma profil beter sig annorlunda utan att en enda rad VPN-konfiguration ändras.

Den flytten är en legitim design, och den bär ett krav: hemligheten måste vara nåbar för systemtjänsten. Att lagra den i profilen, leverera den via en uppgift i systemomfång eller acceptera en interaktiv fråga i rätt ögonblick är alla giltiga svar. Att låta flagga 1 stå och hoppas är det inte.

En privat nyckel med egen lösenfras lägger till ett andra lager. Inte ens ett lagrat kontolösenord låser upp en nyckel som vill ha en lösenfras, så verifiera vilken hemlighet det misslyckade steget faktiskt begär innan du ändrar något.

Vad du inte bör göra, och vad du bör göra i stället

Att göra varje uppgiftsfil läsbar för alla, eller att stänga av autentisering så att ingen fråga behövs, byter en olägenhet vid uppstart mot en permanent exponering. Båda döljer också beroendet i stället för att lösa det, och nästa avbildsuppdatering återinför samma fel.

Använd i det steget mekanismen som din distribution dokumenterar för oövervakad aktivering, och bekräfta sedan att profilens flaggor stämmer med den. Kontrollera resultatet från en ren uppstart, inte från ett skal som redan har en agent. Skriv ned anslutningens ägare, hemlighetens källa och steget som måste fungera, så att en senare ändring av autostart inte tyst kan återinföra ett beroende av att någon först låser upp ett skrivbord. Dokumentation är skillnaden mellan en reparerad tjänst och en som går sönder igen nästa kvartal.

Testa från en kontrollerad ren uppstart i stället för ett manuellt nytt försök efter inloggning. Det nya försöket lyckas av skälet att uppstartsförsöket misslyckades, och det är just det beviset ett snabbt test förstör.