Gancho de cliente ou gancho de servidor? Onde se executa un script de OpenVPN
Unha ruta de script nunha configuración de servidor é unha ruta do servidor. Escolla o gancho segundo a máquina que debe facer o traballo e deixe de agardar que un push execute código nun portátil.
A tarefa está clara: cando un portátil se conecta, algo no portátil debería cambiar. A configuración que se edita pertence ao servidor, e aí é onde se rompe a suposición. Unha ruta nun ficheiro do servidor nomea un ficheiro nese servidor, e ningunha cantidade de push cambia que proceso o executa. Escoller entre os dous ganchos é sobre todo decidir que máquina é dona do traballo e aceptar os límites que se derivan.
Dúas máquinas, dúas preguntas que responder primeiro
Pregunte onde debe ocorrer o cambio de estado e despois que evento lle corresponde. Se o cambio é unha autorización por usuario ou unha decisión de configuración por cliente, pertence a onde se coñece o directorio de usuarios: o servidor. Se o cambio é unha ruta, un axuste do resolutor ou un axudante local nun extremo, pertence ao extremo, e só o extremo pode facelo.
Responder esas dúas preguntas na orde inversa é como a xente acaba intentando empurrar un ficheiro por lotes a un portátil con Windows. O servidor sabe quen se conectou; o portátil sabe como é a súa propia pila de rede. Ningún ten a información do outro, e o intento adoita fallar en silencio en lugar de cun erro claro.
Antes de ambas paga a pena unha terceira pregunta: a plataforma ofrece sequera o gancho que quere? Un aparello que xera a súa propia configuración pode non ofrecer os mesmos nomes de eventos, e un cliente de escritorio que importa un ficheiro .ovpn non é necesariamente o mesmo cliente para o que se escribiu o ficheiro. Confirmar a plataforma primeiro aforra deseñar arredor dun gancho que non existe alí. Tamén lle di que documentación se aplica realmente á máquina que ten diante.
A opción do lado do servidor: un evento por conexión
Un script client-connect execútase no contexto do proceso do servidor cando se conecta un cliente autenticado, e recibe detalles de conexión documentados como o common name e o enderezo asignado. É o lugar correcto para escribir un fragmento de configuración por cliente, aplicar unha decisión de política ou rexistrar estado que o servidor posúe.
A distinción que a xente pasa por alto é a diferenza entre ese gancho e un gancho up do servidor. O gancho up dispárase cando o servidor abre o seu dispositivo de túnel, o que nun servidor con varios clientes ocorre unha vez ao arrincar o demonio. Non é un evento por inicio de sesión, e o código colocado alí execútase cando arrinca o servizo, non cando se conectan os usuarios.
Nun aparello con interface web, use o mecanismo de extensión admitido en lugar de editar ficheiros do demonio xerados. Os ficheiros xerados reescríbense no seguinte gardado, e a reescritura elimina a súa modificación en silencio no peor momento posible. Garde unha copia do texto da extensión fóra do aparello para que unha actualización de firmware non perda tamén a intención.
A opción do lado do cliente: traballo que debe executarse localmente
Un cliente da comunidade pode executar un script local cando aparece o dispositivo de túnel e de novo cando se instalan as rutas. Son dous momentos distintos, e escoller o equivocado produce a clásica carreira na que un axudante arrinca antes de que exista a ruta da que depende.
O axudante debe existir nese cliente, ser lexible e executable pola conta que executa o cliente, e estar permitido por un axuste explícito de script-security. Un script que funciona cando se lanza o cliente como administrador non di nada sobre un servizo previo ao inicio de sesión nin sobre a sesión doutro usuario.
Os nomes tamén importan. O gancho up corresponde á creación do dispositivo e route-up á instalación de rutas, pero unha tarefa que necesita que unha rede privada sexa alcanzable debe verificar a alcanzabilidade en lugar de supoñer que a creación do dispositivo implica que cada ruta, entrada de resolutor e aplicación están listas.
Por que empurrar código executable non está no menú
As opcións empurradas con push están restrinxidas a propósito, e as opcións que executan scripts están entre as categorías que o servidor non pode entregar. Esa restrición existe porque a alternativa permitiría que un servidor comprometido ou mal configurado executase ordes arbitrarias en cada cliente que se conecte algunha vez.
Habilitar a execución de scripts localmente non cambia iso. O seu axuste de script-security permite scripts locais que vostede elixiu; non autoriza o servidor a suministrar novos.
Se o obxectivo é simplemente instalar rutas VPN, use a configuración de rutas admitida en lugar de inventar un esquema de execución remota. Se o obxectivo realmente require código local, distribúao mediante as ferramentas de xestión de extremos da organización e revíseo como calquera outro software que se executa cos privilexios do usuario.
Que verificar antes de confiar en calquera dos dous ganchos
Anote catro cousas por cada gancho: a máquina, o nome do evento, a conta coa que se executa e o cambio de estado que debe producir. Despois probe a conexión, unha reconexión e a ruta de limpeza, porque un gancho que filtra estado ao reconectar é peor que un que nunca se executou.
Probe coa conta que realmente o executará, no momento en que realmente se execute. O manual openvpn(8) documenta ambas familias de ganchos e as restricións do push; a plataforma na que despregue documenta se as expón ou non. Un script que ten éxito nunha terminal de administrador interactiva é unha hipótese, non unha verificación.