VPN-en din virker bare etter innlogging på grunn av nøkkelringen

Kommandoen virker når du er logget inn, så du legger den i et oppstartsskript og går hjem. Neste morgen er maskinen på nett og tunnelen er det ikke. Myten er at et fungerende kall er en fungerende tjeneste. I praksis er forskjellen som regel en av to ting: profilen tilhører brukersesjonen din i stedet for systemet, eller hemmeligheten låses opp av noe som bare finnes etter at du logger inn. Begge virker perfekt i en manuell test og feiler nøyaktig i det øyeblikket ingen ser på.

Hvorfor innlogging får det til å virke

En grafisk innlogging starter en sesjonsbuss og en agent for hemmelighetstjenesten, og det er der mange skrivebordsorienterte klienter oppbevarer passordet til profilen eller passfrasen til den private nøkkelen. En aktivering som kjører som brukeren din etter innlogging kan be den agenten om hemmeligheten og lykkes. Den samme aktiveringen utført av en oppstartsenhet har ingen sesjon, ingen buss og ingen agent, så oppslaget feiler eller blokkerer på en forespørsel ingen ser.

Kjør samme profil før og etter innlogging, og du får to ulike resultater fra én konfigurasjon. Det er signaturen til en avhengighet av påloggingsinformasjon, ikke til en ødelagt tunnel, og det forklarer hvorfor en manuell test i en terminal beviser mindre enn det ser ut som. Tunnelen er i orden; det som låser opp hemmeligheten mangler.

Bestem hvilken eier som starter tunnelen

Det finnes to støttede mønstre, og å blande dem er den andre måten dette feiler på. NetworkManager kan aktivere en systemomfattende tilkobling, noe som passer når maskinen allerede sentraliserer nettverket sitt der. Alternativt kjører en dedikert systemd-enhet VPN-en direkte og eier grensesnittet selv.

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

Ikke kjør begge eierne mot én konfigurasjon. Hvis NetworkManager styrer grensesnittet og en enhet også tar det opp, vil de kjempe om ruter og DNS, og den resulterende tilstanden avhenger av hvem som ble ferdig sist.

Legg hemmeligheten der en tjeneste kan lese den

En bakgrunnstjeneste kan ikke svare på en forespørsel. Passfrase for sertifikater, kontopassord og refererte godkjenningsfiler trenger alle en lagringsordning som enheten kan nå uten et menneske, eid av kontoen som kjører tjenesten og uleselig for alle andre.

Den fristende snarveien er å gjøre filen lesbar for alle til tillatelsesfeilen forsvinner. Det bytter en oppstartsfeil mot en langvarig eksponering av påloggingsinformasjon, og det er den typen endring ingen går tilbake til. Bruk mekanismen distribusjonen allerede stoler på: en begrenset påloggingsfil, en ukryptert nøkkel beskyttet av filrettigheter, eller en systemomfattende tilkobling med sitt eget hemmelighetslager.

Test hendelsen som faktisk skjer

Å starte tjenesten manuelt etter innlogging tester nesten ingenting. Start på nytt, eller deaktiver grafisk innlogging i én syklus, og se enheten komme opp av seg selv. Det er den eneste testen som prøver tilgjengeligheten av påloggingsinformasjon, nettverksberedskap og enhetsrekkefølge sammen. Det er også testen som gjenskaper feilen brukeren rapporterte, noe en manuell start aldri gjør.

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

Rekkefølgen betyr like mye som påloggingsinformasjonen. En enhet som starter før den underliggende oppstrømsforbindelsen er konfigurert, gir opp, og noen distribusjoner er forskjellige på om de venter på tilkobling. Hvis enheten rapporterer feil ved oppstart men lykkes når den startes manuelt tretti sekunder senere, har du funnet et rekkefølgeproblem og ikke et hemmelighetsproblem.

Kontroller ruter og DNS, ikke bare grensesnittet

Et grensesnitt som finnes er ikke en fungerende tunnel. Etter en uovervåket start, kontroller rutene, resolver-tilstanden og én destinasjon etter adresse før du kontrollerer et navn. Kontroller deretter programmet tunnelen finnes 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, er det gjenstående problemet DNS-policy og ikke tunnelen. Noter hvilken eier som starter tjenesten og hvor hemmeligheten bor, for den neste personen som starter denne maskinen på nytt trenger begge faktaene.