Pode un script de gancho de OpenVPN usar o túnel que acaba de construír?

Que un script de gancho chegue ao outro lado do túnel depende de tres condicións: a que evento está ligado, se OpenVPN segue dentro da súa secuencia de arranque cando se executa o script e se o traballo foi separado desa secuencia. A maioría dos scripts fallan na terceira. Engadir unha espera trata un problema de ciclo de vida como un problema de tempos, e funciona xusto o bastante a miúdo para enganar.

Decida primeiro o evento, despois o mecanismo para aprazar o traballo e despois o lugar onde se executa o traballo aprazado. Esas tres decisións son independentes, e mesturalas é como un gancho de dúas liñas se converte nunha tarde enteira.

Por que o gancho espera un túnel que o espera a el

OpenVPN chama os seus ganchos de forma síncrona, dentro do mesmo proceso que move os paquetes. up dispara cando existe o dispositivo tun ou tap, pero antes de que se engada calquera ruta, e route-up dispara despois das rutas; ningún deses momentos promete que un par responda. Mentres un script de calquera dos ganchos segue executándose, o demonio non reenvía, así que un comando que espera que o tráfico cruce o túnel espera un túnel que espera o comando. Esa espera circular é a razón pola que unha execución manual pasa e o gancho esgota o tempo.

O parche obvio, durmir uns segundos, ás veces funciona porque o extremo remoto subiu só, non porque a espera arranxase nada. Un axudante que consulta a dispoñibilidade é outra resposta: o gancho volve, o reenvío comeza e o axudante obtén o que necesita cando de verdade está aí.

Escolla o gancho por evento, non por comodidade

Ate up ao traballo que só necesita o dispositivo, route-up ao traballo que necesita rutas, e reserve client-connect e client-disconnect para tarefas por cliente no lado do servidor. A limpeza ao desconectar debe tolerar executarse dúas veces, xa que as reconexións sobre unha interface persistente non seguen a mesma secuencia que un reinicio completo. No servidor, client-connect dispara cando un cliente se autentica, non cando arranca o demonio, algo que convén confirmar antes de mover alí a lóxica. Se o traballo pertence ao ciclo de vida do servizo e non a unha soa conexión, unha unidade de systemd é un fogar mellor que calquera gancho.

Os comandos de gancho execútaos directamente o demonio, sen ningún shell no medio, así que ifconfig_remote nunha liña up chega como texto literal. Envolva o comando nun shell explícito ou manteña a lóxica nun script que lea o contorno. ipchange é unha directiva que engade argumentos propios: entrega o enderezo e o porto ao comando, así que un script escrito para ningún ve dous inesperados.

Tres formas de separar o traballo

A primeira opción é enviar o axudante ao fondo desde dentro do gancho: inícieo con setsid ou systemd-run --scope, peche os descritores herdados e saia con cero de inmediato. A segunda é que o gancho escriba un pequeno ficheiro de estado e que un temporizador de systemd ou unha unidade de ruta actúen sobre el, o que mantén o gancho trivial e pon a política de reintentos onde hai rexistros. A terceira é descartar o gancho por completo e mover o traballo a unha unidade ordenada despois do servizo VPN, que é a resposta correcta cando o traballo non é por conexión en absoluto. As tres comparten unha regra: o gancho debe volver antes de necesitar o túnel.

Escolla o que escolla, faga o axudante idempotente e observable. Dúas invocacións solapadas non deberían executar a mesma acción irreversible dúas veces, e un axudante que falla ten que deixar algo que unha persoa poida ler.

Separe os fallos de sandbox dos fallos de ciclo de vida

Cando un script se executa desde un indicador de root e falla como servizo, a causa adoita ser unha sandbox e non a rede. Unha ProtectHome restritiva, unha ProtectSystem de só lectura ou un directorio de traballo que non existe poden deixar o script ou os seus datos inalcanzables, e nun host SELinux o ficheiro tamén necesita un contexto que permita a execución. Lea a unidade con systemctl cat openvpn-server@server e o rexistro con journalctl -u openvpn-server@server -n 80, e logo busque un erro de permisos ou de contexto en lugar dun tempo de espera de conexión. Desactivar a sandbox debería ser o último movemento, non o primeiro.

Un fallo de ciclo de vida vese distinto: o gancho arranca, o axudante corre e o socket simplemente aínda non está. Escriba unha liña con marca de tempo desde o propio gancho, desconecte e reconecte, e lea os eventos en orde. Cando o axudante necesite de verdade o túnel, déixeo consultar a dispoñibilidade en lugar de durmir un período fixo.

Tres campos fan útil o seguinte informe: que gancho se executou, que conta usou e onde se detivo. Sen eles, cada investigación posterior comeza de cero.