Din VPN virker kun efter login på grund af nøgleringen

Kommandoen virker, når du er logget ind, så du lægger den i et opstartsscript og går hjem. Næste morgen er maskinen online, og tunnelen er det ikke. Myten er, at et fungerende kald er en fungerende tjeneste. I praksis er forskellen som regel en af to ting: profilen tilhører din brugersession i stedet for systemet, eller hemmeligheden låses op af noget, der først findes, efter du logger ind. Begge virker perfekt i en manuel test og fejler præcis i det øjeblik, ingen kigger.

Hvorfor login får det til at virke

Et grafisk login starter en sessionsbus og en agent for hemmelighedstjenesten, og det er her, mange skrivebordsorienterede klienter opbevarer profilens adgangskode eller adgangssætningen til den private nøgle. En aktivering, der kører som din bruger efter login, kan bede den agent om hemmeligheden og få succes. Den samme aktivering, udført af en opstartsenhed, har ingen session, ingen bus og ingen agent, så opslaget fejler eller blokerer på en prompt, ingen ser.

Kør den samme profil før og efter login, og du får to forskellige resultater fra én konfiguration. Det er signaturen på en afhængighed af legitimationsoplysninger, ikke på en ødelagt tunnel, og det forklarer, hvorfor en manuel test i en terminal beviser mindre, end det ser ud til. Tunnelen er fin; det, der låser dens hemmelighed op, mangler.

Beslut, hvilken ejer der starter tunnelen

Der findes to understøttede mønstre, og at blande dem er den anden måde, dette fejler på. NetworkManager kan aktivere en systemomfattende forbindelse, hvilket er passende, når maskinen allerede centraliserer sit netværk der. Alternativt kører en dedikeret systemd-enhed VPN'en direkte og ejer selv grænsefladen.

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

Kør ikke begge ejere mod én konfiguration. Hvis NetworkManager styrer grænsefladen, og en enhed også rejser den, vil de slås om ruter og DNS, og den resulterende tilstand afhænger af, hvem der blev færdig sidst.

Læg hemmeligheden, hvor en tjeneste kan læse den

En baggrundstjeneste kan ikke svare på en prompt. Adgangssætninger til certifikater, kontoadgangskoder og refererede auth-filer har alle brug for en opbevaringsordning, som enheden kan nå uden et menneske, ejet af den konto, der kører tjenesten, og ulæselig for alle andre.

Den fristende genvej er at gøre filen læsbar for alle, indtil tilladelsesfejlen forsvinder. Det bytter en opstartsfejl for en langvarig eksponering af legitimationsoplysninger, og det er den slags ændring, ingen vender tilbage til. Brug den mekanisme, som udrulningen allerede stoler på: en begrænset legitimationsfil, en ukrypteret nøgle, der beskyttes af filtilladelser, eller en systemomfattende forbindelse med sit eget hemmelige lager.

Test den hændelse, der faktisk sker

At starte tjenesten manuelt efter login tester næsten intet. Genstart, eller deaktiver det grafiske login i én cyklus, og se enheden rejse sig af sig selv. Det er den eneste test, der på samme tid prøver tilgængeligheden af legitimationsoplysninger, netværkets parathed og enhedsbestilling. Det er også den test, der genskaber den fejl, brugeren rapporterede, hvilket en manuel 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

Rækkefølge betyder lige så meget som legitimationsoplysninger. En enhed, der starter, før det underliggende uplink er konfigureret, giver op, og nogle distributioner er forskellige med hensyn til, om de venter på forbindelse. Hvis enheden rapporterer fejl ved opstart, men lykkes, når den startes i hånden tredive sekunder senere, har du fundet et rækkefølgeproblem og ikke et hemmelighedsproblem.

Kontrollér ruter og DNS, ikke kun grænsefladen

En grænseflade, der findes, er ikke en fungerende tunnel. Efter en uovervåget start skal du kontrollere ruterne, resolver-tilstanden og én destination efter adresse, før du kontrollerer et navn. Kontrollér derefter det program, tunnelen findes for.

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'

Hvis adressen virker, og navnet ikke gør, er det resterende problem DNS-politik og ikke tunnelen. Notér, hvilken ejer der starter tjenesten, og hvor hemmeligheden bor, for den næste person, der genstarter denne maskine, får brug for begge fakta.