Jou VPN werk net ná aanmelding weens die sleutelring

Die opdrag werk wanneer jy aangemeld is, so jy sit dit in ’n selflaaiskrip en gaan huis toe. Die volgende oggend is die masjien aanlyn en die tonnel is nie. Die mite is dat ’n werkende oproep ’n werkende diens is. In die praktyk is die verskil gewoonlik een van twee dinge: die profiel behoort aan jou gebruikersessie eerder as aan die stelsel, of die geheim word ontsluit deur iets wat eers bestaan nadat jy aanmeld. Albei werk perfek in ’n handtoets en misluk presies op die oomblik wanneer niemand kyk nie.

Hoekom aanmelding dit laat werk

’n Grafiese aanmelding begin ’n sessiebus en ’n geheime-diensusagent, en dit is waar baie lessenaarkliënte die profiel se wagwoord of privaatsleutelwagfrase hou. ’n Aktivering wat ná aanmelding as jou gebruiker loop, kan daardie agent om die geheim vra en slaag. Dieselfde aktivering wat deur ’n selflaai-eenheid uitgevoer word, het geen sessie, geen bus en geen agent nie, so die soektog misluk of blokkeer op ’n opdrag wat niemand sien nie.

Voer dieselfde profiel voor en ná aanmelding uit en jy kry twee verskillende uitkomste uit een konfigurasie. Dit is die kenmerk van ’n geloofsbriewe-afhanklikheid, nie van ’n stukkende tonnel nie, en dit verduidelik waarom ’n handtoets in ’n terminaal minder bewys as wat dit lyk. Die tonnel is reg; die ding wat sy geheim ontsluit, ontbreek.

Besluit watter eienaar die tonnel begin

Daar is twee ondersteunde patrone, en om hulle te meng is die ander manier waarop dit misluk. NetworkManager kan ’n stelselgerigte verbinding aktiveer, wat gepas is wanneer die masjien reeds sy netwerk daar sentraliseer. Alternatiewelik hardloop ’n toegewyde systemd-eenheid die VPN direk en besit die koppelvlak self.

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

Moenie albei eienaars teen een konfigurasie laat loop nie. As NetworkManager die koppelvlak bestuur en ’n eenheid bring dit ook op, sal hulle oor roetes en DNS baklei, en die resulterende toestand hang daarvan af wie laas klaargemaak het.

Sit die geheim waar ’n diens dit kan lees

’n Agtergronddiens kan nie ’n opdrag antwoord nie. Sertifikaatwagfrases, rekeningwagwoorde en verwysde magtigingslêers het almal ’n stoorreëling nodig wat die eenheid sonder ’n mens kan bereik, wat deur die rekening besit word wat die diens loop en wat vir almal anders onleesbaar is.

Die versoeking is om die lêer wêreldleesbaar te maak totdat die toestemmingsfout verdwyn. Dit ruil ’n selflaai-mislukking vir ’n langdurige blootstelling van geloofsbriewe, en dit is die soort verandering wat niemand weer besoek nie. Gebruik die meganisme wat die ontplooiing reeds vertrou: ’n beperkte geloofsbriewe-lêer, ’n onversleutelde sleutel wat deur lêertoestemmings beskerm word, of ’n stelselgerigte verbinding met sy eie geheime stoor.

Toets die gebeurtenis wat werklik plaasvind

Om die diens ná aanmelding met die hand te begin, toets byna niks. Herbegin, of skakel die grafiese aanmelding vir een siklus af, en kyk of die eenheid vanself opkom. Dit is die enigste toets wat geloofsbriewe-beskikbaarheid, netwerk-gereedheid en eenheid-volgorde saam uitoefen. Dit is ook die toets wat die mislukking reproduseer wat die gebruiker gerapporteer het, wat ’n handmatige begin nooit doen nie.

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

Volgorde maak net so veel saak as geloofsbriewe. ’n Eenheid wat begin voordat die onderliggende opverbinding opgestel is, sal opgee, en sommige verspreidings verskil daarin of hulle vir verbinding wag. As die eenheid by selflaai mislukking rapporteer maar slaag wanneer dit dertig sekondes later met die hand begin word, het jy ’n volgorde-probleem eerder as ’n geheim-probleem gevind.

Verifieer roetes en DNS, nie net die koppelvlak nie

’n Koppelvlak wat bestaan, is nie ’n werkende tonnel nie. Ná ’n onbewaakte begin, kyk na die roetes, die resolver-toestand en een bestemming per adres voordat jy ’n naam toets. Toets dan die toepassing waarvoor die tonnel bestaan.

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'

As die adres werk en die naam nie, is die oorblywende probleem DNS-beleid en nie die tonnel nie. Teken aan watter eienaar die diens begin en waar die geheim woon, want die volgende persoon wat hierdie masjien herbegin, sal albei feite nodig hê.