Je VPN werkt pas na inloggen vanwege de sleutelring

Het commando werkt als je bent ingelogd, dus je zet het in een opstartscript en gaat naar huis. De volgende ochtend is de machine online en de tunnel niet. De mythe is dat een werkende aanroep een werkende service is. In de praktijk is het verschil meestal een van twee dingen: het profiel hoort bij je gebruikerssessie in plaats van bij het systeem, of het geheim wordt ontgrendeld door iets dat pas bestaat nadat je inlogt. Beide werken perfect in een handmatige test en falen precies op het moment dat niemand kijkt.

Waarom inloggen het laat werken

Een grafische login start een sessiebus en een agent van de geheime dienst, en daar bewaren veel desktopgerichte clients het wachtwoord van het profiel of de wachtzin van de privésleutel. Een activering die na het inloggen als jouw gebruiker draait, kan die agent om het geheim vragen en slagen. Dezelfde activering, uitgevoerd door een opstartunit, heeft geen sessie, geen bus en geen agent, dus de opzoeking mislukt of blokkeert op een prompt die niemand ziet.

Voer hetzelfde profiel voor en na het inloggen uit en je krijgt twee verschillende uitkomsten uit één configuratie. Dat is de signatuur van een afhankelijkheid van inloggegevens, niet van een kapotte tunnel, en het verklaart waarom een handmatige test in een terminal minder bewijst dan het lijkt. De tunnel is in orde; het ding dat het geheim ontgrendelt ontbreekt.

Bepaal welke eigenaar de tunnel start

Er zijn twee ondersteunde patronen, en ze door elkaar halen is de andere manier waarop dit mislukt. NetworkManager kan een systeembrede verbinding activeren, wat passend is wanneer de machine haar netwerk daar al centraliseert. Als alternatief draait een speciale systemd-unit de VPN rechtstreeks en bezit de interface zelf.

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

Draai niet beide eigenaren tegen één configuratie. Als NetworkManager de interface beheert en een unit brengt hem ook omhoog, vechten ze om routes en DNS, en de resulterende toestand hangt ervan af wie het laatst klaar was.

Leg het geheim waar een dienst het kan lezen

Een achtergronddienst kan geen prompt beantwoorden. Certificaat-wachtzinnen, accountwachtwoorden en gerefereerde auth-bestanden hebben allemaal een opslagregeling nodig die de unit zonder mens kan bereiken, in het bezit van het account dat de dienst draait en onleesbaar voor alle anderen.

De verleidelijke snelweg is het bestand voor iedereen leesbaar maken tot de permissiefout verdwijnt. Dat ruilt een opstartfout voor een langdurige blootstelling van inloggegevens, en het is het soort wijziging waar niemand op terugkomt. Gebruik het mechanisme dat de uitrol al vertrouwt: een beperkt inloggegevensbestand, een onversleutelde sleutel die door bestandsrechten wordt beschermd, of een systeembrede verbinding met een eigen geheimenopslag.

Test de gebeurtenis die echt gebeurt

De dienst na het inloggen handmatig starten test bijna niets. Herstart, of schakel de grafische login één cyclus uit, en kijk hoe de unit vanzelf omhoogkomt. Dat is de enige test die beschikbaarheid van inloggegevens, netwerk gereedheid en unitvolgorde samen uitoefent. Het is ook de test die de storing reproduceert die de gebruiker meldde, wat een handmatige start nooit doet.

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

Volgorde is net zo belangrijk als inloggegevens. Een unit die start voordat de onderliggende uplink is geconfigureerd geeft het op, en sommige distributies verschillen in of ze op connectiviteit wachten. Als de unit bij het opstarten een fout meldt maar slaagt wanneer je hem dertig seconden later met de hand start, heb je een volgordeprobleem gevonden en geen geheimprobleem.

Controleer routes en DNS, niet alleen de interface

Een interface die bestaat is geen werkende tunnel. Controleer na een onbewaakte start de routes, de status van de resolver en één bestemming op adres voordat je een naam controleert. Controleer daarna de toepassing waarvoor de tunnel bestaat.

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'

Als het adres werkt en de naam niet, is het resterende probleem DNS-beleid en niet de tunnel. Noteer welke eigenaar de dienst start en waar het geheim woont, want de volgende persoon die deze machine herstart heeft beide feiten nodig.