OpenVPN : executar um arquivo .ovpn no Linux e entender uma falha

Você recebeu um arquivo .ovpn, você inicia o OpenVPN em uma VM Debian ou Ubuntu, e então o terminal exibe um erro ou fica travado antes da conexão. O arquivo pode ser válido, mesmo apontando para um certificado ausente, uma porta filtrada ou uma rota que interrompe sua sessão SSH. Verifique o perfil, anote o primeiro erro, e então verifique a rota e o serviço interno após a conexão.

Leia o arquivo .ovpn antes de iniciar o OpenVPN

Mantenha um console local, um console do fornecedor, iDRAC/IPMI ou uma rede de gerenciamento distinta já validada. Inicie o teste a partir desse acesso independente. O redirect-gateway pode ser escrito no arquivo ou enviado pelo servidor após a conexão. A rota padrão pode então passar pelo túnel. Uma segunda sessão SSH que usa a mesma rota não é um acesso de emergência.

Se você estiver conectado via SSH antes do teste, exiba e anote o endereço cliente. A partir do console de controle usado após a conexão, redefina esse endereço antes de verificar sua rota. Um console de recuperação permite retornar ao servidor, mas não garante que sua sessão SSH permaneça aberta.

# Na sessão SSH antes do lançamento:
printf '%sn' "$SSH_CLIENT"
# No console de controle após a conexão:
SSH_CLIENT_IP='198.51.100.42' # substitua pelo endereço cliente anotado
ip route get "$SSH_CLIENT_IP"

Coloque o arquivo em um diretório reservado para sua conta e limite seus direitos se alguma chave estiver integrada. Não coloque nem identificador, nem senha no arquivo de demonstração ou em um repositório Git.

mkdir -p ~/vpn-test
install -m 600 /caminho/recebido/client.ovpn ~/vpn-test/client.ovpn
cd ~/vpn-test
grep -nE '^[[:space:]]*(remote|proto|port|ca|cert|key|pkcs12|tls-auth|tls-crypt|tls-verify|auth-user-pass|auth-user-pass-verify|redirect-gateway|redirect-private|route|route-ipv6|route-gateway|route-table|route-noexec|route-nopull|pull-filter|config|plugin|script-security|up|down|route-up|route-pre-down|ipchange|dns-updown|management|daemon|log|log-append|syslog|status|writepid|askpass|cd|chroot|user|group|learn-address|client-connect|client-disconnect)' client.ovpn

Essa leitura mostra o host remoto, o protocolo, os arquivos de certificados e o modo de autenticação sem exibir seu conteúdo. Se config carregar outro arquivo, releia-o a partir do diretório do perfil, refaça esse filtro e siga cada config até o último arquivo. Toda a cadeia deve ser compreendida antes do lançamento. up, down, route-up, route-pre-down, ipchange e tls-verify lançam comandos externos. plugin carrega uma biblioteca no processo OpenVPN. management abre uma interface de controle que não deve ser exposta. Um perfil cliente que contém learn-address, client-connect, client-disconnect ou auth-user-pass-verify é rejeitado para este diagnóstico. Pare também se qualquer um dos outros caminhos for desconhecido. Os scripts externos exigem um valor script-security de 2 ou 3, valor que o perfil pode definir por conta própria. Verifique também auth-user-pass: sem argumento, o OpenVPN pedirá os identificadores no prompt; com um caminho, ele lerá esse arquivo e enviará seu conteúdo ao servidor do perfil. O lançamento com sudo é normal para criar a interface e as rotas, mas nenhum arquivo referenciado deve ser desconhecido.

# Para cada caminho encontrado após « config », a partir de ~/vpn-test:
sed -n '1,220p' caminho-incluído.conf

Um arquivo cuja origem ou diretivas permanecem desconhecidas nunca deve ser executado em um servidor de produção ou em uma máquina cuja acessibilidade SSH seja significativa. A primeira tentativa deve ser feita em uma VM descartável com console independente. Essa leitura reduz o risco, mas não transforma um perfil arbitrário em um perfil seguro. Recuse também daemon, log, log-append e syslog para este diagnóstico: eles movem as mensagens fora do terminal e podem deixar o processo em segundo plano.

Se o perfil referenciar caminhos relativos, não mova apenas client.ovpn. Mantenha o diretório recebido em um local controlado ou copie cada dependência lida com a mesma estrutura de diretórios e direitos restritivos. Por exemplo, um perfil que cita ca ca.crt deve encontrar ca.crt em ~/vpn-test.

install -m 600 /caminho/recebido/ca.crt ~/vpn-test/ca.crt

Uma dependência ausente ou ilegível é uma falha no perfil, distinta de um erro TLS após a tentativa de rede. Um arquivo .ovpn também pode incorporar os certificados entre tags, e esse controle não exibirá nenhum caminho externo.

find ~/vpn-test -maxdepth 1 -type f -printf '%f %mn'
# Para proto udp4/tcp4:
getent ahostsv4 vpn.exemplo.net
# Para proto udp6/tcp6:
getent ahostsv6 vpn.exemplo.net
ip -brief link show > ~/vpn-test/links-before.txt

Substitua o host e a família pelos valores de remote e proto. Um perfil pode conter várias linhas remote. Se a família permanecer aberta, verifique as duas saídas e, em seguida, mantenha o endereço realmente anunciado pelo OpenVPN no log. A própria conexão OpenVPN permanece o teste útil do protocolo e da porta, seja UDP ou TCP.

Iniciar o cliente em primeiro plano e manter o log

Inicie o cliente em primeiro plano. O terminal deve então mostrar o endereço contatado e o primeiro erro explorável. Instale o pacote se openvpn estiver ausente:

command -v openvpn || { sudo apt update && sudo apt install openvpn; }
sudo openvpn --config ~/vpn-test/client.ovpn --verb 3

Com --verb 3, mantenha o primeiro erro explícito, o endereço do servidor e a fase onde o cliente para.

• Options error ou um arquivo não encontrado indicam um caminho, uma diretiva ou um certificado a ser corrigido antes de uma nova tentativa.
• TLS Error após a tentativa de conexão exige uma verificação do servidor, da porta, do protocolo UDP/TCP, do filtragem de rede, de tls-auth ou tls-crypt, dos certificados, do horário do sistema e dos parâmetros criptográficos do perfil.
• Um pedido de identificador pode vir de auth-user-pass. Digite-o no prompt ou use o mecanismo previsto por seu fornecedor, sem adicionar o segredo a client.ovpn.
• A mensagem Initialization Sequence Completed confirma que o cliente terminou sua inicialização. Isso ainda não prova que o recurso interno esperado está acessível.

Mantenha o comando aberto durante a próxima verificação. Pare-o com Ctrl+C somente após ter verificado a interface, as rotas e o serviço interno.

Verificar a interface e a rota após a conexão

Registre as interfaces antes da conexão e, em seguida, compare-as após. tun transporta pacotes IP, tap emula uma interface Ethernet. A diretiva dev também pode impor um nome. Use apenas o nome realmente criado. ip route get mostra o dispositivo que o Linux escolheria, sem enviar pacotes.

# Após « Initialization Sequence Completed »:
ip -brief link show | diff -u ~/vpn-test/links-before.txt -
VPN_IF='nome-da-interface-criada'
ip -brief address show dev "$VPN_IF"
ip route get 10.8.0.10
ip route get 1.1.1.1
ip route get "$SSH_CLIENT_IP"

Substitua 10.8.0.10 por um alvo interno documentado pela equipe que fornece o VPN. Sua rota deve mencionar a interface do túnel se essa rede passar pelo OpenVPN. Releia também a rota para SSH_CLIENT_IP se você tiver uma sessão remota antes do teste.

A rota não prova que o serviço interno responde. Em seguida, teste o serviço esperado com o endereço e a porta documentados pela sua equipe. Para um serviço HTTPS que expõe uma página de saúde, por exemplo:

getent hosts intranet.exemplo.lan
curl --fail --silent --show-error --connect-timeout 5 --max-time 10 --output /dev/null --write-out '%{http_code}n' https://intranet.exemplo.lan:443/health

Substitua este nome, a porta e o caminho pelos do serviço real. O primeiro comando deve retornar um endereço interno. O segundo deve exibir o código esperado por esse serviço, por exemplo 200 ou 204. curl também verifica o certificado TLS: instale a CA interna ou utilize a documentação do serviço, se necessário, sem adicionar --insecure. Para um DNS interno, consulte um nome e um resolvedor documentados por sua equipe.

Eu escolheria essa execução pontual antes de um serviço openvpn-client@... em um servidor, pois o diagnóstico fica separado do início. Após Ctrl+C, verifique se a interface desapareceu, se a rota para o alvo interno não está mais utilizando o túnel e se a rota para o endereço SSH anotado retorna ao dispositivo esperado. Um perfil com scripts down ou route-pre-down impõe esse controle, não permitindo supor que a limpeza foi bem-sucedida.

ip link show "$VPN_IF"
ip route get 10.8.0.10
ip route get "$SSH_CLIENT_IP"

O primeiro comando deve indicar que a interface não existe mais. Compare as duas rotas com suas saídas registradas antes e durante o túnel. Uma rota ainda vinculada à interface excluída ou um script de limpeza com erro requer verificação antes de uma nova tentativa.