La vostra VPN només funciona després d’iniciar sessió pel clauer

L’ordre funciona quan heu iniciat sessió, així que la poseu en un script d’arrencada i aneu a casa. L’endemà al matí la màquina és en línia i el túnel no. El mite és que una invocació que funciona és un servei que funciona. A la pràctica, la diferència sol ser una de dues coses: el perfil pertany a la vostra sessió d’usuari i no al sistema, o el secret el desbloqueja una cosa que només existeix després que inicieu sessió. Tots dos funcionen perfectament en una prova manual i fallen exactament en el moment que ningú mira.

Per què l’inici de sessió ho fa funcionar

Un inici de sessió gràfic engega un bus de sessió i un agent del servei de secrets, i és aquí on molts clients orientats a l’escriptori guarden la contrasenya del perfil o la frase clau de la clau privada. Una activació que s’executa com el vostre usuari després d’iniciar sessió pot demanar el secret a aquest agent i tenir èxit. La mateixa activació executada per una unitat d’arrencada no té sessió, ni bus, ni agent, així que la consulta falla o es bloqueja en un avís que ningú veu.

Executeu el mateix perfil abans i després d’iniciar sessió i obtindreu dos resultats diferents d’una sola configuració. Aquesta és la signatura d’una dependència de credencials, no d’un túnel trencat, i explica per què una prova manual en un terminal demostra menys del que sembla. El túnel està bé; falta la cosa que desbloqueja el seu secret.

Decidiu quin propietari inicia el túnel

Hi ha dos patrons compatibles, i barrejar-los és l’altra manera com falla això. NetworkManager pot activar una connexió d’àmbit de sistema, cosa adequada quan la màquina ja centralitza aquí la seva xarxa. Alternativament, una unitat systemd dedicada executa la VPN directament i posseeix la interfície.

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

No executeu tots dos propietaris contra una mateixa configuració. Si NetworkManager gestiona la interfície i una unitat també la puja, es barallaran per les rutes i el DNS, i l’estat resultant depèn de qui va acabar l’últim.

Poseu el secret on el servei el pugui llegir

Un servei en segon pla no pot respondre a un avís. Les contrasenyes de certificat, les contrasenyes de compte i els fitxers d’autenticació referenciats necessiten una disposició d’emmagatzematge que la unitat pugui assolir sense cap humà, propietat del compte que executa el servei i il·legible per a tota la resta.

El drecera temptador és fer que el fitxer sigui llegible per tothom fins que l’error de permisos desaparegui. Això canvia un fracàs d’arrencada per una exposició de credencials de llarga durada, i és el tipus de canvi que ningú revisa. Feu servir el mecanisme en què ja confia el desplegament: un fitxer de credencials restringit, una clau no xifrada protegida pels permisos del fitxer, o una connexió d’àmbit de sistema amb el seu propi magatzem de secrets.

Proveu l’esdeveniment que passa realment

Iniciar el servei manualment després d’iniciar sessió no prova gairebé res. Reinicieu, o desactiveu l’inici de sessió gràfic durant un cicle, i observeu com la unitat s’aixeca tota sola. Aquesta és l’única prova que exerceix alhora la disponibilitat de credencials, la preparació de la xarxa i l’ordre de les unitats. També és la prova que reprodueix la fallada que l’usuari va informar, cosa que un inici manual mai no fa.

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

L’ordre importa tant com les credencials. Una unitat que arrenca abans que l’enllaç ascendent subjacent estigui configurat es rendirà, i algunes distribucions difereixen en si esperen la connectivitat. Si la unitat informa d’una fallada a l’arrencada però té èxit quan la inicieu a mà trenta segons després, heu trobat un problema d’ordre i no un problema de secret.

Verifiqueu rutes i DNS, no només la interfície

Una interfície que existeix no és un túnel que funciona. Després d’un inici sense supervisió, comproveu les rutes, l’estat del resolutor i una destinació per adreça abans de comprovar un nom. Després comproveu l’aplicació per a la qual existeix el túnel.

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'

Si l’adreça funciona i el nom no, el problema restant és la política de DNS i no el túnel. Anoteu quin propietari inicia el servei i on viu el secret, perquè la propera persona que reiniciï aquesta màquina necessitarà tots dos fets.