VPN-ul tău funcționează doar după autentificare din cauza inelului de chei

Comanda funcționează când ești autentificat, așa că o pui într-un script de pornire și pleci acasă. A doua zi dimineață mașina este online, iar tunelul nu. Mitul este că o invocare funcțională înseamnă un serviciu funcțional. În practică diferența este de obicei unul din două lucruri: profilul aparține sesiunii tale de utilizator și nu sistemului, sau secretul este deblocat de ceva care există doar după ce te autentifici. Ambele funcționează perfect într-un test manual și eșuează exact în momentul în care nimeni nu se uită.

De ce autentificarea îl face să funcționeze

O autentificare grafică pornește un bus de sesiune și un agent al serviciului de secrete, și acolo mulți clienți orientați spre desktop păstrează parola profilului sau fraza de acces a cheii private. O activare care rulează ca utilizatorul tău după autentificare poate cere secretul acelui agent și poate reuși. Aceeași activare executată de o unitate de pornire nu are sesiune, bus și agent, așa că căutarea eșuează sau se blochează pe o solicitare pe care nimeni nu o vede.

Rulează același profil înainte și după autentificare și obții două rezultate diferite dintr-o singură configurație. Aceasta este semnătura unei dependențe de credențiale, nu a unui tunel defect, și explică de ce un test manual într-un terminal dovedește mai puțin decât pare. Tunelul este în regulă; lipsește ceea ce îi deblochează secretul.

Decide care proprietar pornește tunelul

Există două modele acceptate, iar amestecarea lor este cealaltă cale prin care acest lucru eșuează. NetworkManager poate activa o conexiune la nivel de sistem, ceea ce este potrivit când mașina își centralizează deja rețeaua acolo. Alternativ, o unitate systemd dedicată rulează VPN-ul direct și deține interfața.

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

Nu rula ambii proprietari pe o singură configurație. Dacă NetworkManager administrează interfața și o unitate o ridică și ea, se vor certa pe rute și DNS, iar starea rezultată depinde de cine a terminat ultimul.

Pune secretul acolo unde un serviciu îl poate citi

Un serviciu din fundal nu poate răspunde la o solicitare. Frazele de acces ale certificatelor, parolele conturilor și fișierele de autentificare referite au nevoie toate de o organizare de stocare pe care unitatea o poate atinge fără un om, deținută de contul care rulează serviciul și ilizibilă pentru toți ceilalți.

Scurtătura tentantă este să faci fișierul lizibil pentru toți până când eroarea de permisiuni dispare. Asta schimbă un eșec la pornire pe o expunere de credențiale pe termen lung și este genul de modificare la care nimeni nu mai reveni. Folosește mecanismul în care implementarea are deja încredere: un fișier de credențiale restricționat, o cheie necriptată protejată de permisiunile fișierului sau o conexiune la nivel de sistem cu propriul depozit de secrete.

Testează evenimentul care se întâmplă cu adevărat

Pornirea manuală a serviciului după autentificare nu testează aproape nimic. Repornește sau dezactivează autentificarea grafică pentru un ciclu și urmărește unitatea ridicându-se singură. Acesta este singurul test care exersează împreună disponibilitatea credențialelor, pregătirea rețelei și ordinea unităților. Este și testul care reproduce eșecul raportat de utilizator, ceea ce o pornire manuală nu face niciodată.

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

Ordinea contează la fel de mult ca credențialele. O unitate care pornește înainte ca legătura superioară de bază să fie configurată va renunța, iar unele distribuții diferă în privința dacă așteaptă conectivitatea. Dacă unitatea raportează un eșec la pornire dar reușește când o pornești manual treizeci de secunde mai târziu, ai găsit o problemă de ordine și nu o problemă de secret.

Verifică rutele și DNS, nu doar interfața

O interfață care există nu este un tunel funcțional. După o pornire nesupravegheată, verifică rutele, starea resolverului și o destinație după adresă înainte de a verifica un nume. Apoi verifică aplicația pentru care există tunelul.

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'

Dacă adresa funcționează și numele nu, problema rămasă este politica DNS și nu tunelul. Notează care proprietar pornește serviciul și unde trăiește secretul, pentru că următoarea persoană care repornește această mașină va avea nevoie de ambele fapte.