Gancho de cliente ou gancho de servidor? Onde corre um script do OpenVPN

A tarefa é clara: quando um portátil se liga, algo no portátil deve mudar. A configuração que está a ser editada pertence ao servidor, e é aí que a suposição se quebra. Um caminho num ficheiro do servidor nomeia um ficheiro nesse servidor, e nenhuma quantidade de push muda qual processo o executa. Escolher entre os dois ganchos é sobretudo decidir que máquina é dona do trabalho e aceitar os limites que daí decorrem.

Duas máquinas, duas perguntas a responder primeiro

Pergunte onde tem de ocorrer a mudança de estado e depois pergunte que evento lhe corresponde. Se a mudança for uma autorização por utilizador ou uma decisão de configuração por cliente, pertence onde o diretório de utilizadores é conhecido: o servidor. Se a mudança for uma rota, uma definição do resolver ou um auxiliar local num extremo, pertence ao extremo, e só o extremo o pode fazer.

Responder a essas duas perguntas pela ordem inversa é como as pessoas acabam a tentar empurrar um ficheiro batch para um portátil Windows. O servidor sabe quem se ligou; o portátil sabe como é a sua própria pilha de rede. Nenhum tem a informação do outro, e a tentativa costuma falhar em silêncio em vez de com um erro claro.

Antes de ambas vale a pena uma terceira pergunta: a plataforma sequer expõe o gancho que quer? Um equipamento que gera a sua própria configuração pode não oferecer os mesmos nomes de eventos, e um cliente de secretária que importa um ficheiro .ovpn não é necessariamente o mesmo cliente para o qual o ficheiro foi escrito. Confirmar a plataforma primeiro poupa-o de desenhar à volta de um gancho que ali não existe. Também lhe diz que documentação se aplica realmente à máquina à sua frente.

A opção do lado do servidor: um evento por ligação

Um script client-connect corre no contexto do processo do servidor quando um cliente autenticado se liga, e recebe detalhes de ligação documentados como o common name e o endereço atribuído. É o local certo para escrever um fragmento de configuração por cliente, aplicar uma decisão de política ou registar estado que o servidor possui.

A distinção que as pessoas perdem é a diferença entre esse gancho e um gancho up do servidor. O gancho up dispara quando o servidor abre o seu dispositivo de túnel, o que num servidor com vários clientes acontece uma vez no arranque do daemon. Não é um evento por início de sessão, e o código ali colocado corre quando o serviço arranca e não quando os utilizadores se ligam.

Num equipamento com interface web, use o mecanismo de extensão suportado em vez de editar ficheiros do daemon gerados. Os ficheiros gerados são reescritos no próximo guardar, e a reescrita remove silenciosamente a sua alteração no pior momento possível. Guarde uma cópia do texto da extensão fora do equipamento para que uma atualização de firmware não perca também a intenção.

A opção do lado do cliente: trabalho que tem de correr localmente

Um cliente da comunidade pode executar um script local quando o dispositivo de túnel aparece e de novo quando as rotas são instaladas. São dois momentos diferentes, e escolher o errado produz a clássica corrida em que um auxiliar arranca antes de existir a rota de que depende.

O auxiliar tem de existir nesse cliente, ser legível e executável pela conta que executa o cliente, e ser permitido por uma definição script-security explícita. Um script que funciona quando inicia o cliente como administrador não lhe diz nada sobre um serviço antes do início de sessão nem sobre a sessão de outro utilizador.

Os nomes também importam. O gancho up corresponde à criação do dispositivo e o route-up à instalação de rotas, mas uma tarefa que precisa de uma rede privada alcançável deve verificar a alcançabilidade em vez de assumir que a criação do dispositivo implica que cada rota, entrada de resolver e aplicação estão prontas.

Porque empurrar código executável não está no menu

As opções empurradas com push estão restringidas de propósito, e as opções que executam scripts estão entre as categorias que o servidor não pode entregar. Essa restrição existe porque a alternativa permitiria que um servidor comprometido ou mal configurado executasse comandos arbitrários em cada cliente que alguma vez se ligue.

Ativar a execução de scripts localmente não muda isso. A sua definição script-security permite scripts locais que escolheu; não autoriza o servidor a fornecer novos.

Se o objetivo é apenas instalar rotas VPN, use a configuração de rotas suportada em vez de inventar um esquema de execução remota. Se o objetivo exigir mesmo código local, distribua-o pelas ferramentas de gestão de extremos da organização e reveja-o como qualquer outro software que corre com os privilégios do utilizador.

O que verificar antes de confiar em qualquer dos ganchos

Anote quatro coisas por cada gancho: a máquina, o nome do evento, a conta com que corre e a mudança de estado que deve produzir. Depois teste a ligação, uma religação e o caminho de limpeza, porque um gancho que perde estado na religação é pior do que um que nunca correu.

Teste com a conta que realmente o executará, no momento em que realmente será executado. O manual openvpn(8) documenta ambas as famílias de ganchos e as restrições do push; a plataforma onde implementa documenta se as expõe ou não. Um script que tem sucesso num terminal de administrador interativo é uma hipótese, não uma verificação.