VPN-en din verkar berre etter innlogging på grunn av nøkkelringen

Kommandoen verkar når du er logga inn, så du legg han i eit oppstartsskript og går heim. Neste morgon er maskina på nettet og tunnelen er det ikkje. Myten er at eit fungerande kall er ei fungerande teneste. I praksis er skilnaden som regel ein av to ting: profilen høyrer til brukarøkta di i staden for systemet, eller løyndomen blir låst opp av noko som berre finst etter at du loggar inn. Begge verkar perfekt i ein manuell test og feilar nøyaktig i det augneblinken ingen ser på.

Kvifor innlogging får det til å verke

Ei grafisk innlogging startar ein sesjonsbuss og ein agent for løyndomstenesta, og det er der mange skrivebordsorienterte klientar oppbevarer passordet til profilen eller passfrasen til den private nøkkelen. Ein aktivering som køyrer som brukaren din etter innlogging kan be den agenten om løyndomen og lukkast. Den same aktiveringa utført av ei oppstartseining har inga økt, ingen buss og ingen agent, så oppslaget feilar eller blokkerer på ein førespurnad ingen ser.

Køyr same profil før og etter innlogging, og du får to ulike resultat frå éin konfigurasjon. Det er signaturen til ein avhengnad av påloggingsinformasjon, ikkje til ein øydelagd tunnel, og det forklarer kvifor ein manuell test i ein terminal beviser mindre enn det ser ut som. Tunnelen er i orden; det som låser opp løyndomen manglar.

Bestem kva eigar som startar tunnelen

Det finst to støtta mønster, og å blande dei er den andre måten dette feilar på. NetworkManager kan aktivere ei systemomfattande tilkopling, noko som passar når maskina allereie sentraliserer nettverket sitt der. Alternativt køyrer ei dedikert systemd-eining VPN-en direkte og eig grensesnittet sjølv.

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

Ikkje køyr båe eigarane mot éin konfigurasjon. Viss NetworkManager styrer grensesnittet og ei eining òg tek det opp, vil dei kjempe om ruter og DNS, og den resulterande tilstanden avheng av kven som vart ferdig sist.

Legg løyndomen der ei teneste kan lese han

Ei bakgrunnsteneste kan ikkje svare på ein førespurnad. Passfrase for sertifikat, kontopassord og refererte godkjenningsfiler treng alle ei lagringordning som eininga kan nå utan eit menneske, eigd av kontoen som køyrer tenesta og uleseleg for alle andre.

Den freistande snarvegen er å gjere fila leseleg for alle til løyvetfeilen forsvinn. Det byter ein oppstartsfeil mot ei langvarig eksponering av påloggingsinformasjon, og det er den typen endring ingen går tilbake til. Bruk mekanismen distribusjonen allereie stolar på: ei avgrensa påloggingsfil, ein ukryptert nøkkel verna av filrettar, eller ei systemomfattande tilkopling med sitt eige løyndomslager.

Test hendinga som faktisk skjer

Å starte tenesta manuelt etter innlogging testar nesten ingenting. Start på nytt, eller deaktiver grafisk innlogging i éin syklus, og sjå eininga kome opp av seg sjølv. Det er den einaste testen som prøver tilgjenge på påloggingsinformasjon, nettverksberedskap og einingrekkjefølgje saman. Det er òg testen som attskapar feilen brukaren rapporterte, noko ein manuell start aldri gjer.

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

Rekkjefølgja tyder like mykje som påloggingsinformasjonen. Ei eining som startar før den underliggjande oppstrømskoplinga er konfigurert, gir opp, og nokre distribusjonar er ulike på om dei ventar på tilkopling. Viss eininga rapporterer feil ved oppstart men lukkast når ho blir starta manuelt tretti sekund seinare, har du funne eit rekkjefølgjeproblem og ikkje eit løyndomsproblem.

Kontroller ruter og DNS, ikkje berre grensesnittet

Eit grensesnitt som finst er ikkje ein fungerande tunnel. Etter ein uovervaka start, kontroller rutene, tilstanden til resolvaren og éin destinasjon etter adresse før du kontrollerer eit namn. Kontroller deretter programmet tunnelen finst 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'

Viss adressa verkar og namnet ikkje, er det gjenverande problemet DNS-policy og ikkje tunnelen. Noter kva eigar som startar tenesta og kvar løyndomen bur, for den neste personen som startar denne maskina på nytt treng begge fakta.