Din VPN fungerar bara efter inloggning på grund av nyckelringen

Kommandot fungerar när du är inloggad, så du lägger det i ett startskript och går hem. Nästa morgon är maskinen online och tunneln är det inte. Myten är att ett fungerande anrop är en fungerande tjänst. I praktiken är skillnaden oftast en av två saker: profilen tillhör din användarsession i stället för systemet, eller så låses hemligheten upp av något som bara finns efter att du loggar in. Båda fungerar perfekt i ett manuellt test och misslyckas exakt i det ögonblick ingen tittar.

Varför inloggning får det att fungera

En grafisk inloggning startar en sessionsbuss och en agent för hemlighetstjänsten, och det är där många skrivbordsorienterade klienter förvarar profilens lösenord eller lösenfrasen för den privata nyckeln. En aktivering som körs som din användare efter inloggning kan be den agenten om hemligheten och lyckas. Samma aktivering som utförs av en uppstartsenhet har ingen session, ingen buss och ingen agent, så sökningen misslyckas eller blockerar på en fråga som ingen ser.

Kör samma profil före och efter inloggning och du får två olika utfall från en enda konfiguration. Det är signaturen för ett beroende av inloggningsuppgifter, inte för en trasig tunnel, och det förklarar varför ett manuellt test i en terminal bevisar mindre än det verkar. Tunneln är okej; det som låser upp dess hemlighet saknas.

Bestäm vilken ägare som startar tunneln

Det finns två stödda mönster, och att blanda dem är det andra sättet detta misslyckas. NetworkManager kan aktivera en systemomfattande anslutning, vilket passar när maskinen redan centraliserar sitt nätverk där. Alternativt kör en dedikerad systemd-enhet VPN direkt och äger gränssnittet själv.

systemctl list-unit-files 'openvpn*'
systemctl list-unit-files 'wg-quick*'
nmcli connection show --active
systemctl enable --now wg-quick@wg0

Kör inte båda ägarna mot en konfiguration. Om NetworkManager hanterar gränssnittet och en enhet också tar upp det, kommer de att slåss om rutter och DNS, och det resulterande tillståndet beror på vem som blev klar sist.

Lägg hemligheten där en tjänst kan läsa den

En bakgrundstjänst kan inte svara på en fråga. Lösenfraser för certifikat, kontolösenord och refererade autentiseringsfiler behöver alla ett lagringsarrangemang som enheten kan nå utan en människa, ägt av kontot som kör tjänsten och oläsbart för alla andra.

Den frestande genvägen är att göra filen läsbar för alla tills behörighetsfelet försvinner. Det byter ett uppstartsfel mot en långvarig exponering av inloggningsuppgifter, och det är den typen av ändring som ingen återvänder till. Använd mekanismen som distributionen redan litar på: en begränsad inloggningsfil, en okrypterad nyckel skyddad av filbehörigheter, eller en systemomfattande anslutning med sitt eget hemlighetslager.

Testa händelsen som faktiskt inträffar

Att starta tjänsten manuellt efter inloggning testar nästan ingenting. Starta om, eller inaktivera grafisk inloggning under en cykel, och se enheten komma upp av sig själv. Det är det enda testet som utövar tillgängligheten av inloggningsuppgifter, nätverkets beredskap och enhetsordningen tillsammans. Det är också testet som återskapar felet användaren rapporterade, vilket en manuell start aldrig gör.

systemctl is-enabled wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager
systemctl status systemd-networkd-wait-online --no-pager

Ordningen betyder lika mycket som inloggningsuppgifterna. En enhet som startar innan den underliggande upplänken är konfigurerad ger upp, och vissa distributioner skiljer sig åt i om de väntar på anslutning. Om enheten rapporterar fel vid uppstart men lyckas när den startas manuellt trettio sekunder senare, har du hittat ett ordningsproblem och inte ett hemlighetsproblem.

Kontrollera rutter och DNS, inte bara gränssnittet

Ett gränssnitt som finns är inte en fungerande tunnel. Efter en övervakad start, kontrollera rutterna, resolverns tillstånd och en destination efter adress innan du kontrollerar ett namn. Kontrollera sedan programmet som tunneln finns för.

ip -4 route show
resolvectl status
ping -c 3 10.61.0.1
curl -sS --max-time 5 https://internal.example/ -o /dev/null -w '%{http_code}\n'

Om adressen fungerar och namnet inte, är det återstående problemet DNS-policy och inte tunneln. Anteckna vilken ägare som startar tjänsten och var hemligheten bor, för nästa person som startar om maskinen behöver båda fakta.