O teu VPN só funciona despois de iniciar sesión polo chaveiro

O comando funciona cando iniciaches sesión, así que o pones nun script de arranque e vas para casa. Á mañá seguinte a máquina está en liña e o túnel non. O mito é que unha invocación que funciona é un servizo que funciona. Na práctica a diferenza adoita ser unha de dúas cousas: o perfil pertence á túa sesión de usuario en lugar do sistema, ou o segredo desbloquéao algo que só existe despois de que inicies sesión. Ambos funcionan perfectamente nunha proba manual e fallan xusto no momento en que ninguén mira.

Por que iniciar sesión o fai funcionar

Un inicio de sesión gráfico arranca un bus de sesión e un axente do servizo de segredos, e aí é onde moitos clientes orientados ao escritorio gardan o contrasinal do perfil ou a frase de paso da chave privada. Unha activación que se executa como o teu usuario tras iniciar sesión pode pedirlle o segredo a ese axente e ter éxito. A mesma activación executada por unha unidade de arranque non ten sesión, nin bus, nin axente, así que a busca falla ou bloquéase nunha solicitude que ninguén ve.

Executa o mesmo perfil antes e despois de iniciar sesión e obterás dous resultados distintos dunha soa configuración. Esa é a sinatura dunha dependencia de credenciais, non dun túnel roto, e explica por que unha proba manual nun terminal demostra menos do que parece. O túnel está ben; falta o que desbloquea o seu segredo.

Decide que propietario inicia o túnel

Hai dous patróns admitidos, e mesturalos é a outra forma en que isto falla. NetworkManager pode activar unha conexión de ámbito de sistema, o cal é axeitado cando a máquina xa centraliza aí a súa rede. Como alternativa, unha unidade systemd dedicada executa a VPN directamente e posúe a interface.

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

Non executes ambos propietarios contra unha mesma configuración. Se NetworkManager xestiona a interface e unha unidade tamén a levanta, pelexarán polas rutas e o DNS, e o estado resultante depende de quen rematou último.

Pon o segredo onde o servizo poida lelo

Un servizo en segundo plano non pode responder a unha solicitude. As frases de contrasinal de certificados, os contrasinais de conta e os ficheiros de autenticación referenciados necesitan unha disposición de almacenamento que a unidade poida acadar sen un humano, propiedade da conta que executa o servizo e ilexible para todos os demais.

O atallo tentador é facer que o ficheiro sexa lexible por todos ata que o erro de permisos desapareza. Iso cambia un fallo de arranque por unha exposición de credenciais de longa duración, e é o tipo de cambio que ninguén revisa. Usa o mecanismo no que xa confía o despregamento: un ficheiro de credenciais restrinxido, unha chave non cifrada protexida polos permisos do ficheiro, ou unha conexión de ámbito de sistema co seu propio almacén de segredos.

Proba o evento que ocorre de verdade

Iniciar o servizo a man despois do inicio de sesión non proba case nada. Reinicia, ou desactiva o inicio de sesión gráfico durante un ciclo, e observa como a unidade se levanta soa. Esa é a única proba que exercita á vez a dispoñibilidade de credenciais, a preparación da rede e a orde das unidades. Tamén é a proba que reproduce o fallo que notificou o usuario, algo que un inicio manual nunca fai.

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

A orde importa tanto como as credenciais. Unha unidade que arranca antes de que estea configurado o enlace ascendente subxacente renderase, e algunhas distribucións difiren en se agardan a conectividade. Se a unidade informa dun fallo ao arrancar pero ten éxito cando a inicias a man trinta segundos despois, atopaches un problema de orde e non un problema de segredo.

Verifica rutas e DNS, non só a interface

Unha interface que existe non é un túnel que funciona. Tras un arranque sen supervisión, comproba as rutas, o estado do resolutor e un destino por enderezo antes de comprobar un nome. Despois comproba a aplicación para a que existe o 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'

Se o enderezo funciona e o nome non, o problema restante é a política de DNS e non o túnel. Anota que propietario inicia o servizo e onde vive o segredo, porque a próxima persoa que reinicie esta máquina necesitará ambos os feitos.