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.

Artigos relacionados