O seu ficheiro .ovpn pode executar código, não apenas encaminhar tráfego

A maioria das pessoas lê um ficheiro .ovpn como lê a página de definições de um router: endereços, rotas, uma lista de cifras. A parte que executa código fica perto do fundo, junto a diretivas que parecem trabalhos de canalização, e corre com quaisquer privilégios que o cliente já tenha. É essa a falha que um perfil descuidado ou malicioso explora, e é também a falha que transforma um auxiliar DNS útil num problema de suporte três semanas depois. A diretiva de evento, o nível de segurança e a propriedade do ficheiro decidem o que pode acontecer; o conteúdo do script decide o que acontece de facto. Leia as quatro antes de se ligar.

Um perfil que executa um auxiliar é um programa, não um ficheiro de definições

Diretivas como route e dhcp-option descrevem o estado que o cliente deve estabelecer, e o cliente trata-as como dados. Um script up é diferente: o cliente lança-o como processo e entrega-lhe um ambiente cheio de detalhes de ligação, por isso tudo o que o autor escreveu corre com os direitos da sua conta. Num portátil onde o utilizador é administrador, isso é uma porta larga para um ficheiro que chegou como anexo ou colado de um tópico de fórum. A distinção não é estilística, é a diferença entre configuração e código.

O mito que vale a pena retirar é que um perfil só pode redirecionar o tráfego. Um auxiliar que executa ip route add e outro que executa curl contra um anfitrião remoto são o mesmo mecanismo, e o perfil parece idêntico visto de fora. Nada na aparência do ficheiro lhe diz qual tem, por isso a revisão tem de chegar ao próprio script.

O que decide realmente a execução e como são as linhas que a permitem

Três coisas controlam um auxiliar: a diretiva de evento que o nomeia, o nível script-security que o permite e a implementação da própria plataforma do cliente. Um perfil pode pedir um gancho e mesmo assim não ver nada acontecer, porque um cliente móvel ou uma compilação de ambiente de trabalho reduzida pode não implementar esse evento de todo. Da mesma forma, um perfil que pede mais permissão do que a sua função precisa diz-lhe algo sobre a sua origem. Um nível de permissão é uma capacidade, não uma aprovação. As linhas que o permitem são assim, com um caminho a ocupar o lugar do seu.

script-security 2
up /etc/openvpn/update-resolv-conf.sh
down /etc/openvpn/update-resolv-conf.sh

O nível 0 recusa programas externos e o nível 1, o predefinido, só permite os executáveis integrados do cliente, por isso um gancho precisa de 2 ou superior; o nível 3 existe sobretudo para passar palavras-passe antigas e é melhor evitá-lo. Um perfil fornecido com um gancho precisa tanto da diretiva como desse nível, por isso uma linha perto do fundo do ficheiro merece o mesmo escrutínio que o bloco do certificado. O manual do OpenVPN enumera os níveis de permissão, e a sua redação merece ser lida ao lado do que o perfil pede realmente.

Propriedade, caminho e aquilo com que se alimenta o auxiliar

Um perfil em que confia mas que aponta para um script que outra conta pode reescrever não é um arranjo fiável, porque a revisão de ontem já não descreve o que corre hoje. Verifique o proprietário e o modo do auxiliar, e verifique que o caminho configurado resolve para o ficheiro que inspecionou e não para um nome que outra coisa possa eclipsar. Os argumentos e o ambiente merecem o mesmo olhar: o cliente passa detalhes de ligação ao gancho, e um auxiliar que registe todo o seu ambiente pode estar a escrever credenciais num ticket de suporte. Prefira uma integração documentada do operador ou da plataforma a um script DNS copiado de uma publicação não relacionada, porque dois gestores de resolvedores que discutem pelo mesmo ficheiro produzem uma falha que parece uma VPN avariada.

Quando reporta um gancho que falha, redija o ambiente antes de o colar em qualquer sítio. O despejo que o ajuda a depurar também pode transportar o token que o autentica.

As falhas de limpeza aparecem depois de o túnel desaparecer

Um auxiliar up acrescenta rotas e definições de resolvedor, e o auxiliar down deveria retirá-las de novo. Quando o gancho down falta, falha em silêncio ou nunca corre porque o cliente foi morto, os restos sobrevivem à sessão. O tráfego toma então um caminho que ninguém planeou e os nomes resolvem-se por um resolvedor que devia ter sido removido, enquanto o túnel parece saudável. Esses sintomas chegam depois da desconexão, por isso se culpa a rede e não o perfil.

Teste a desmontagem como um passo próprio: levante o túnel, anote as rotas e o resolvedor, derrube-o e confirme depois que ambos desapareceram. Um perfil que liga de forma limpa pode deixar estado para trás, e um código de saída zero do auxiliar não prova que o resolvedor acabou onde pensa.

Rever o auxiliar e manter uma saída

Leia o script do princípio ao fim à procura de três coisas: comandos que exigem privilégios, caminhos codificados que podem não existir no seu sistema e qualquer chamada de rede que faça. Depois veja como falha, porque um auxiliar que engole erros transforma um erro de configuração num mistério. Se não conseguir dizer numa frase o que o script faz e quem o pode alterar, não está pronto para o ativar. Um perfil que pede mais privilégios do que essa frase exige é o sinal de parar.

Guarde o último perfil que funcionava e o auxiliar a que apontava em armazenamento protegido, com ambas as versões anotadas, para que uma reversão seja uma cópia e não uma reconstrução no pior momento possível. Se o auxiliar só existe para uma distribuição ou versão de cliente que já não precisa dele, reforme-o na configuração que possui a definição em vez de subir privilégios até os erros pararem. Essa é a saída: menos peças móveis, não mais permissão.