Tutoriais de VPS
Montar um servidor OpenVPN em uma VPS (2026): Ubuntu 24.04, Easy-RSA, UFW e configuração do cliente
Monte um servidor OpenVPN em uma VPS Ubuntu: certificados Easy-RSA, UFW, NAT, configuração .ovpn do cliente, verificação de conexão e revogação de certificados.
O OpenVPN é indicado para cenários de acesso remoto que precisam de compatibilidade com Windows, macOS, Linux, Android, iOS e roteadores. Ele não é necessariamente mais rápido que o WireGuard, mas seus clientes são maduros e as permissões de certificado são claras, por isso ainda é comum em acesso à intranet corporativa, manutenção remota de dispositivos domésticos e criptografia em Wi-Fi público.
Este artigo usa o Ubuntu 22.04/24.04 como exemplo e monta um servidor com autenticação por certificado usando o OpenVPN e o Easy-RSA dos repositórios do sistema. No final, você terá um arquivo .ovpn que pode ser importado diretamente no OpenVPN Connect, além de tratar encaminhamento de IP, UFW, NAT e revogação de clientes.
| Número de usuários | Configuração recomendada | Cenários indicados |
|---|---|---|
| 1-5 pessoas | 1 núcleo / 1GB / 20GB SSD | SSH, painéis de intranet e navegação leve |
| 5-20 pessoas | 2 núcleos / 2GB / 40GB SSD | Acesso de escritório, serviços de arquivos e navegação diária |
| Mais de 20 pessoas | 4 núcleos / 4GB ou mais | Muitos clientes simultâneos; é preciso monitorar largura de banda e número de conexões |
A criptografia do OpenVPN depende bastante do desempenho de um único núcleo. A VPS também precisa de um IPv4 público, e o ambiente de virtualização deve permitir a criação de dispositivos TUN. Antes de implantar, execute:
test -c /dev/net/tun && echo "TUN available" || echo "TUN unavailable"
ip route show default
Se /dev/net/tun não existir, ative o TUN/TAP no painel de controle da VPS ou entre em contato com o provedor.
Primeiro atualize o sistema e instale o software necessário:
sudo apt update
sudo apt install -y openvpn easy-rsa ufw
openvpn --version | head -n 1
A documentação oficial do Ubuntu usa o Easy-RSA para criar uma CA privada e emitir certificados separados para o servidor e para cada cliente. Copie o diretório de trabalho:
sudo make-cadir /etc/openvpn/easy-rsa
sudo -i
cd /etc/openvpn/easy-rsa
./easyrsa init-pki
./easyrsa build-ca
build-ca vai pedir para definir uma senha da CA. Essa senha só é usada ao emitir ou revogar certificados; não baixe pki/private/ca.key em clientes comuns.
O serviço não pode esperar a digitação da senha da chave privada na inicialização, então a chave do servidor usa nopass:
cd /etc/openvpn/easy-rsa
./easyrsa gen-req server nopass
./easyrsa sign-req server server
./easyrsa gen-dh
openvpn --genkey secret /etc/openvpn/ta.key
Copie os arquivos de que o servidor precisa e restrinja as permissões da chave privada:
cp pki/ca.crt /etc/openvpn/
cp pki/issued/server.crt /etc/openvpn/
cp pki/private/server.key /etc/openvpn/
cp pki/dh.pem /etc/openvpn/
chmod 600 /etc/openvpn/server.key /etc/openvpn/ta.key
Crie /etc/openvpn/server.conf:
port 1194
proto udp4
dev tun
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn-ipp.txt
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh.pem
tls-crypt /etc/openvpn/ta.key
remote-cert-tls client
data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305
auth SHA256
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 1.1.1.1"
push "dhcp-option DNS 1.0.0.1"
keepalive 10 120
persist-key
persist-tun
user nobody
group nogroup
explicit-exit-notify 1
verb 3
redirect-gateway significa que todo o tráfego do cliente passa pela VPS. Se você quiser acessar apenas o servidor ou uma intranet doméstica, remova essa linha e publique sub-redes específicas, por exemplo:
push "route 192.168.10.0 255.255.255.0"
Ative o encaminhamento IPv4:
echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/50-enable-ipv4-forwarding.conf
sysctl -p /etc/sysctl.d/50-enable-ipv4-forwarding.conf
Primeiro verifique o nome da interface de rede pública; não presuma diretamente que é eth0:
WAN_IF=$(ip route show default | awk '/default/ {print $5; exit}')
echo "$WAN_IF"
Se o UFW já estiver ativado na VPS, libere primeiro o SSH e o OpenVPN. Se o SSH usar uma porta diferente de 22, substitua a regra correspondente:
ufw allow OpenSSH
ufw allow 1194/udp
Edite /etc/default/ufw e altere a política de encaminhamento para:
DEFAULT_FORWARD_POLICY="ACCEPT"
Adicione o bloco NAT no início do arquivo /etc/ufw/before.rules, em que eth0 deve ser substituído pela interface de rede pública que você acabou de encontrar:
*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
COMMIT
Confirme que o grupo de segurança da plataforma de nuvem também permite UDP 1194 e depois recarregue o UFW:
ufw enable
ufw reload
ufw status verbose
Antes de ativar o firewall, mantenha a sessão SSH atual aberta e confirme que as regras de SSH estão corretas. Se você se bloquear, consulte Checklist de autossocorro quando o SSH fica inacessível após ativar o UFW na VPS.
A documentação oficial do Ubuntu usa o serviço de template openvpn@配置文件名. Como o arquivo de configuração é /etc/openvpn/server.conf, o comando de inicialização é:
systemctl enable --now openvpn@server
systemctl status openvpn@server --no-pager
ip addr show tun0
Quando tudo está certo, o log mostra Initialization Sequence Completed e cria 10.8.0.1:
journalctl -u openvpn@server -n 100 --no-pager
ss -lunp | grep 1194
Alguns pacotes Debian/Ubuntu colocam a configuração do servidor em /etc/openvpn/server/server.conf, com o nome de serviço correspondente openvpn-server@server. Se openvpn@server informar que não encontrou a configuração, execute systemctl list-unit-files | grep openvpn para confirmar qual layout de diretórios o pacote atual usa.
Cada dispositivo usa seu próprio certificado; não deixe celular, computador e roteador compartilharem uma única chave privada de cliente:
cd /etc/openvpn/easy-rsa
./easyrsa gen-req phone nopass
./easyrsa sign-req client phone
Gere a configuração de arquivo único /root/phone.ovpn, substituindo YOUR_VPS_IP pelo IP público ou domínio do servidor:
cat > /root/phone.ovpn <<EOF
client
dev tun
proto udp4
remote YOUR_VPS_IP 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305
auth SHA256
verb 3
<ca>
$(cat pki/ca.crt)
</ca>
<cert>
$(sed -ne '/BEGIN CERTIFICATE/,$p' pki/issued/phone.crt)
</cert>
<key>
$(cat pki/private/phone.key)
</key>
<tls-crypt>
$(cat /etc/openvpn/ta.key)
</tls-crypt>
EOF
chmod 600 /root/phone.ovpn
Baixe esse arquivo com segurança via SFTP e importe-o no OpenVPN Connect. Não o encaminhe por drives em nuvem públicos ou grupos de chat, porque .ovpn contém a chave privada do cliente.
Depois que o cliente se conectar, verifique na ordem:
ping 10.8.0.1
curl https://ifconfig.me
No modo túnel completo, o segundo comando deve retornar o IP público da VPS. No servidor, veja as conexões dos clientes:
ip addr show tun0
journalctl -u openvpn@server -f
As principais diferenças entre OpenVPN e WireGuard são as seguintes:
| Comparação | OpenVPN | WireGuard |
|---|---|---|
| Compatibilidade de clientes | Muito ampla, comum em ambientes corporativos | Bom suporte em sistemas novos |
| Método de configuração | CA e certificados de cliente | Chaves pública/privada e Peers |
| Desempenho | Maior sobrecarga de criptografia e em espaço de usuário | Normalmente menor latência e maior throughput |
| Revogação de permissões | Revogar um certificado individual | Excluir o Peer correspondente |
Se você valoriza mais velocidade e configuração simples, consulte Tutorial para montar WireGuard VPN em uma VPS.
Se perder um celular ou computador, revogue o certificado correspondente imediatamente:
cd /etc/openvpn/easy-rsa
./easyrsa revoke phone
./easyrsa gen-crl
cp pki/crl.pem /etc/openvpn/crl.pem
chmod 644 /etc/openvpn/crl.pem
Adicione o seguinte à configuração do servidor:
crl-verify /etc/openvpn/crl.pem
Depois reinicie o serviço:
systemctl restart openvpn@server
Confirme que o UDP 1194 está liberado tanto no firewall do sistema quanto no grupo de segurança da nuvem, e verifique se o IP, a porta e proto do cliente coincidem com os do servidor:
ss -lunp | grep 1194
journalctl -u openvpn@server -n 100 --no-pager
Normalmente é causado por erro no encaminhamento de IP, no nome da interface NAT ou na política de encaminhamento do UFW:
sysctl net.ipv4.ip_forward
ip route show default
grep DEFAULT_FORWARD_POLICY /etc/default/ufw
iptables -t nat -L POSTROUTING -n -v
Reinicie o serviço primeiro e depois veja o erro específico:
systemctl restart openvpn@server
journalctl -u openvpn@server -xe --no-pager
Verifique principalmente os caminhos dos certificados, as permissões de arquivo e se tls-crypt coincide nas duas pontas. Não ative BF-CBC nem desative a verificação de certificados sem critério para ser compatível com clientes antigos; atualize o cliente.
- O TUN/TAP está disponível, o IP público da VPS é estável e o UDP 1194 está liberado no grupo de segurança.
- A chave privada da CA fica apenas no servidor ou em backup offline, e cada dispositivo tem seu próprio certificado.
net.ipv4.ip_forward=1está em vigor e o NAT usa a interface de rede pública correta.- A configuração do cliente não foi transmitida por canais públicos e as permissões do arquivo são
600. - O serviço está configurado para iniciar no boot e os logs não mostram erros persistentes de TLS ou de roteamento.
- Os passos de revogação de certificados foram documentados e
/etc/openvpn/easy-rsa/pkié copiado periodicamente.
A parte mais propensa a erros em uma implantação OpenVPN não é a geração de certificados, mas sim a porta, o firewall e a cadeia de encaminhamento. Primeiro faça o cliente conseguir chegar a 10.8.0.1 e depois investigue a saída pública; assim você distingue rapidamente problemas de TLS de problemas de NAT.