Jo VPN wurket pas nei it oanmelden fanwegen de kaaiering

It kommando wurket as jo oanmeld binne, dus jo sette it yn in opstartskript en geane nei hûs. De oare moarns is de masine online en de tunnel net. De myte is dat in wurkjende oanrop in wurkjende tsjinst is. Yn de praktyk is it ferskil meastentiids ien fan twa dingen: it profyl heart by jo brûkerssesje yn stee fan by it systeem, of it geheim wurdt ûntskoattele troch eat dat pas bestiet neidat jo oanmelde. Beide wurkje perfekt yn in hânmjittige test en fale krekt op it momint dat nimmen sjocht.

Wêrom't oanmelden it wurkje lit

In grafyske oanmelding start in sesjebus en in agent fan de geheimetsjinst, en dat is wêr't in protte desktoprjochte kliïnten it wachtwurd fan it profyl of de wachtfrase fan 'e partikuliere kaai bewarje. In aktivaasje dy't nei it oanmelden as jo brûker rint, kin dat agent om it geheim freegje en slagje. Deselde aktivaasje útfierd troch in opstartienheid hat gjin sesje, gjin bus en gjin agent, dus de syktocht falt of blokkearret op in oanfreget dat nimmen sjocht.

Rin itselde profyl foar en nei it oanmelden en jo krije twa ferskillende útkomsten út ien konfiguraasje. Dat is de hantekening fan in ôfhinklikens fan oanmeldgegevens, net fan in stikken tunnel, en it ferklearret wêrom't in hânmjittige test yn in terminal minder bewiist as't liket. De tunnel is goed; it ding dat syn geheim ûntskoattelet ûntbrekt.

Beslis hokker eigner de tunnel startet

Der binne twa stipe patroanen, en se trochinoar helje is de oare manier wêrop dit falt. NetworkManager kin in ferbining op systeemnivo aktivearje, wat geskikt is as de masine har netwurk dêr al sintralisearret. Alternatyf rint in tawijde systemd-ienheid de VPN direkt en besit sels de ynterface.

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

Rin net beide eigners tsjin ien konfiguraasje. As NetworkManager de ynterface beheart en in ienheid bringt him ek omheech, sille se fjochtsje oer rûtes en DNS, en de resultearjende tastân hinget derfan ôf wa't it lêst klear wie.

Set it geheim wêr't in tsjinst it lêze kin

In eftergrûntsjinst kin gjin oanfreget beäntwurdzje. Sertifikaatwachtwurden, akkountwachtwurden en ferwiisde auth-bestannen hawwe allegear in opslachregeling nedich dy't de ienheid sûnder minske berikke kin, eigendom fan it akkount dat de tsjinst rint en ûnlêsber foar alle oaren.

De ferliedlike fluchste wei is it bestân foar elkenien lêsber te meitsjen oant de tastimmingsflater ferdwynt. Dat ruilet in opstartflater foar in langduorjende bleatstelling fan oanmeldgegevens, en it is it soarte feroaring dêr't nimmen op weromkomt. Brûk it meganisme dat de útrôl al fertrout: in beheind oanmeldgegevensbestân, in net-fersifere kaai beskerme troch bestânstimmings, of in ferbining op systeemnivo mei syn eigen geheimenopslach.

Test it barren dat echt bart

De tsjinst nei it oanmelden mei de hân starte testet hast neat. Start opnij, of skeakel de grafyske oanmelding foar ien syklus út, en sjoch de ienheid fansels omheech kommen. Dat is de iennige test dy't tagelyk beskikberens fan oanmeldgegevens, netwurkgereedheid en ienheidsoarderefening docht. It is ek de test dy't de flater reprodusearret dy't de brûker meldde, wat in hânmjittige start nea docht.

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

Oarder is like wichtich as oanmeldgegevens. In ienheid dy't start foardat de ûnderlizzende uplink konfigurearre is, jout it op, en guon distribúsjes ferskille yn oft se op ferbining wachtsje. As de ienheid by it opstarten in flater meldt mar slagget as se tritich sekonden letter mei de hân starten wurdt, dan hawwe jo in oarderprobleem fûn en gjin geheimprobleem.

Kontrolearje rûtes en DNS, net allinnich de ynterface

In ynterface dy't bestiet is gjin wurkjende tunnel. Nei in ûnbewekke start, kontrolearje de rûtes, de tastân fan de oplosser en ien bestimming op adres foardat jo in namme kontrolearje. Kontrolearje dan de applikaasje dêr't de tunnel foar bestiet.

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 it adres wurket en de namme net, is it oerbleaune probleem DNS-belied en net de tunnel. Skriuw op hokker eigner de tsjinst startet en wêr't it geheim wennet, want de folgjende persoan dy't dizze masine opnij start hat beide feiten nedich.