OpenVPN + SSH Proxy — Segurança, Casos de Uso e Lições Aprendidas

Esta é a terceira e última parte da série sobre o openvpn-ssh-proxy. Nos dois posts anteriores, apresentei o problema e a solução e depois detalhei toda a implementação técnica. Agora quero fechar o ciclo com o que considero igualmente importante: segurança, casos de uso reais e as lições que ficaram.

Boas Práticas de Segurança

Antes de qualquer coisa: nunca suba arquivos .ovpn com credenciais para repositórios públicos. Parece óbvio, mas é o tipo de coisa que acontece na pressa — um git add . descuidado e credenciais de VPN de um cliente ficam expostas. O .gitignore do projeto já bloqueia esse caminho, mas a responsabilidade é sempre do operador.

Segredos em produção

Para ambientes de desenvolvimento local, variáveis de ambiente são aceitáveis. Em produção, não são. As alternativas recomendadas são:

Docker Secrets — nativo no Docker Swarm, mantém segredos fora do ambiente de processo
HashiCorp Vault — solução madura e amplamente adotada para gerenciamento de segredos
AWS Secrets Manager — especialmente conveniente para quem já trabalha na AWS, com rotação automática e integração com IAM

O princípio é simples: segredo não é configuração, e não deve ser tratado como tal.

Acesso à porta SSH

O container expõe uma porta SSH no host. Isso significa que qualquer processo capaz de alcançar essa porta pode tentar se conectar. Em produção, restrinja o acesso com regras de firewall ou ACLs — libere apenas os IPs ou redes que realmente precisam desse acesso. Se o container estiver em uma instância EC2, um Security Group bem configurado resolve isso com facilidade.

Autenticação

O projeto, por padrão, usa autenticação por senha. Para cenários de uso pessoal e temporários, isso é suficiente. Para ambientes compartilhados ou de longa duração, autenticação baseada em chaves SSH é o caminho certo — elimina o risco de força bruta e simplifica a rotação de acesso.

Isolamento como benefício

Um ponto que valorizo nessa arquitetura: o container funciona como uma camada de isolamento natural. A VPN roda dentro do container, não na máquina host. Isso significa que o tráfego VPN fica contido, o roteamento da máquina host não é afetado, e remover o acesso é tão simples quanto parar o container.

Casos de Uso Reais

Quando criei esse projeto, resolvi um problema pontual. Com o tempo, percebi que o padrão se aplica a vários cenários:

Acesso a bancos de dados de produção em redes de clientes. Muitos clientes corporativos mantêm bancos de dados acessíveis apenas dentro da VPN deles. Com o proxy SSH rodando em um container dedicado, consigo criar um tunnel local e usar qualquer cliente de banco de dados normalmente, sem instalar o cliente VPN na minha máquina principal.

Múltiplos clientes simultaneamente. Esse é o cenário que mais justifica a abordagem containerizada. Cada cliente tem sua própria VPN, seu próprio container, sua própria porta SSH. Posso ter três tunnels abertos ao mesmo tempo, para três clientes diferentes, sem conflito nenhum. Tentar fazer isso com clientes VPN nativos normalmente resulta em conflitos de roteamento ou na necessidade de alternar manualmente entre conexões.

Pipelines de CI/CD que precisam de acesso VPN. Algumas implantações precisam alcançar infraestrutura que só está acessível via VPN. Com o container como proxy, o agente de CI pode abrir um tunnel SSH e executar os comandos necessários sem precisar de um cliente VPN instalado no runner.

Times de desenvolvimento compartilhando acesso VPN. Em vez de distribuir arquivos .ovpn para cada desenvolvedor e lidar com suporte a clientes de diferentes sistemas operacionais, o container pode rodar em um servidor compartilhado. Os desenvolvedores se conectam via SSH tunnel ao container e acessam os recursos necessários. Um ponto único de controle, mais fácil de auditar e revogar.

Lições Aprendidas

Docker e dispositivos de rede

A parte mais interessante do projeto do ponto de vista técnico foi lidar com o dispositivo tun. O OpenVPN precisa criar interfaces de rede virtuais, o que exige a capability NET_ADMIN e acesso ao /dev/net/tun. Docker abstrai muita coisa de rede, mas quando você precisa de controle de rede real dentro de um container, essas dependências aparecem.

Entender por que essas permissões são necessárias — e não simplesmente rodar o container em modo privilegiado — foi um exercício importante. Modo privilegiado funciona, mas é o equivalente de dar root irrestrito ao container. NET_ADMIN é específica e suficiente para o caso.

O valor de containerizar ferramentas de infraestrutura

Há uma tendência natural de instalar ferramentas de infraestrutura diretamente no sistema operacional — clientes VPN, tunnelings, proxies. Funciona, mas cria estado no sistema que é difícil de rastrear, auditar ou reproduzir.

Containerizar essas ferramentas muda a equação: a configuração fica declarativa, o ambiente é descartável e reproduzível, e a remoção é limpa. Isso se alinha com o princípio de tratar infraestrutura como código — mesmo quando a “infraestrutura” é uma conexão VPN temporária.

Mantenha simples

Tunnels SSH são uma tecnologia com décadas de uso em produção. São confiáveis, bem documentados e suportados em praticamente qualquer ambiente. A decisão de construir o proxy em cima de SSH, em vez de criar algo mais elaborado, foi deliberada — e correta. A solução funciona porque não tenta ser mais do que precisa.

Possíveis Evoluções

O projeto está funcional, mas há caminhos naturais de evolução:

WireGuard em vez de OpenVPN — protocolo mais moderno, mais performático, com handshake mais simples. Vale explorar para cenários onde performance é crítica.
Autenticação por chave SSH — substituir senhas por chaves é o próximo passo óbvio para uso em ambientes compartilhados.
Health checks e reconexão automática — VPNs caem. Um mecanismo de detecção e reconexão automática tornaria o container mais resiliente para uso contínuo.
Interface web para gerenciar conexões — para times menos técnicos, uma UI simples para iniciar, parar e monitorar conexões reduziria a barreira de uso.

Contribua

O projeto está no GitHub: github.com/mauricioj/openvpn-ssh-proxy. A imagem está disponível no Docker Hub em hub.docker.com/u/mauricioj.

Se você usa o projeto, encontrou um bug, tem uma sugestão ou quer contribuir com código — pull requests e issues são bem-vindos. Projetos open source crescem com uso real e feedback honesto.

Criar esse projeto foi um exercício que começou com um problema concreto e terminou com um entendimento mais profundo de rede em containers, segurança de credenciais e o valor de manter ferramentas simples e composíveis. Espero que seja útil para quem enfrenta os mesmos desafios.