WireGuard: acesso interno sem expor porta na internet

Toda infraestrutura acumula serviços que precisam ser alcançáveis por poucas pessoas e por mais ninguém: o painel administrativo, o banco de dados, o ambiente de homologação, a ferramenta de monitoramento.

A saída mais comum é deixá-los públicos com senha, ou restringir por IP de origem. A primeira é frágil — senha é adivinhável, e o serviço fica exposto a qualquer falha que apareça nele. A segunda quebra no dia em que o IP de casa muda.

Uma VPN resolve os dois problemas de uma vez, e o WireGuard tornou isso simples o bastante para valer a pena mesmo em operação pequena.

Por que ele mudou a equação

VPN tinha fama de complicada, e a fama era merecida. Configurações antigas envolviam autoridade certificadora, dezenas de opções e diagnóstico difícil.

O WireGuard cabe em um arquivo de quinze linhas. Ele vive no kernel do Linux desde 2020, usa um conjunto fixo de algoritmos modernos — sem negociação, sem escolha ruim possível — e a autenticação é por par de chaves, no mesmo modelo do SSH.

O efeito prático é que a configuração inteira é legível de uma vez, e o diagnóstico costuma se resumir a duas perguntas: as chaves estão certas e o roteamento está certo.

Servidor

sudo apt install wireguard

umask 077
wg genkey | sudo tee /etc/wireguard/servidor.key | wg pubkey | \
  sudo tee /etc/wireguard/servidor.pub

# /etc/wireguard/wg0.conf
[Interface]
Address = 10.100.0.1/24
ListenPort = 51820
PrivateKey = <conteudo de servidor.key>

[Peer]
# notebook da Mariana
PublicKey = <chave publica do cliente>
AllowedIPs = 10.100.0.2/32

sudo systemctl enable --now wg-quick@wg0
sudo wg show

O umask 077 antes de gerar a chave não é detalhe: sem ele, o arquivo nasce legível por qualquer usuário da máquina, o que anula a segurança inteira. Vale o mesmo cuidado descrito no artigo sobre segredos no servidor.

Cada pessoa é um bloco [Peer] com chave pública própria e um endereço fixo na rede da VPN. Revogar acesso é remover o bloco e recarregar — sem trocar nada para os demais.

Cliente

# no notebook
[Interface]
Address = 10.100.0.2/32
PrivateKey = <chave privada do cliente>
DNS = 10.100.0.1

[Peer]
PublicKey = <chave publica do servidor>
Endpoint = 203.0.113.50:51820
AllowedIPs = 10.100.0.0/24, 10.0.0.0/24
PersistentKeepalive = 25

O AllowedIPs do lado do cliente é a linha que mais importa, e a que mais confunde. Ela define o que é roteado pelo túnel.

Listando apenas as redes internas, como acima, só o tráfego para elas passa pela VPN — a navegação comum continua saindo direto. É o que se quer na maioria dos casos: acesso à infraestrutura sem transformar o servidor em gargalo da internet de todo mundo.

Se o objetivo for o oposto — todo o tráfego pelo túnel, para sair com o IP do servidor —, o valor é 0.0.0.0/0. Aí o servidor precisa fazer NAT, como no artigo sobre NAT e redirecionamento.

O PersistentKeepalive mantém o túnel vivo quando o cliente está atrás de NAT, que é a situação de praticamente todo mundo. Sem ele, a conexão funciona ao sair do cliente e falha quando o servidor tenta iniciar.

Firewall: abrir uma porta para fechar várias

O ganho fica evidente aqui. Antes da VPN, o firewall precisava liberar várias portas para IPs variados. Depois, ele libera uma porta UDP e nada mais:

# Perímetro e host: só a porta do WireGuard
sudo ufw allow 51820/udp

# Serviços internos: apenas pela rede da VPN
sudo ufw allow from 10.100.0.0/24 to any port 5432 proto tcp
sudo ufw allow from 10.100.0.0/24 to any port 3000 proto tcp

Confirme na regra de firewall do painel que só a 51820 está aberta ao mundo. E note uma propriedade interessante do WireGuard: a porta não responde a quem não tem chave válida. Uma varredura não distingue um servidor com WireGuard de um endereço sem nada — o que reduz bastante o interesse de quem procura alvo.

Vale manter o SSH acessível por fora enquanto você testa. Mover o SSH para dentro da VPN é o passo seguinte, e fazê-lo antes de confirmar que a VPN funciona é o caminho mais rápido para precisar do console de emergência.

O que dá errado, e é sempre a mesma coisa

Três causas cobrem a maioria dos problemas.

Roteamento no `AllowedIPs`. No servidor, ele diz quais endereços pertencem àquele peer; no cliente, o que vai pelo túnel. Errar do lado do servidor faz o tráfego de retorno se perder.

sudo wg show
ip route | grep wg0

O wg show traz latest handshake e bytes trafegados. Handshake recente com bytes apenas em uma direção é sintoma clássico de roteamento errado — a ida funciona, a volta não.

Encaminhamento desligado, quando o servidor precisa dar acesso a outras máquinas:

sysctl net.ipv4.ip_forward

MTU. Um túnel adiciona cabeçalhos, e o pacote que cabia deixa de caber. O sintoma é peculiar: ping funciona, SSH conecta, e transferências grandes travam no meio.

[Interface]
MTU = 1380

Esse valor resolve a maioria dos casos em links residenciais brasileiros. Vale testar antes de assumir que o problema é outro — travamento intermitente em túnel é MTU com frequência alta.

Adicionar e remover pessoas

O fluxo é curto o bastante para virar rotina:

# gerar par para a pessoa nova
wg genkey | tee joao.key | wg pubkey > joao.pub

# adicionar no servidor, sem derrubar ninguém
sudo wg set wg0 peer $(cat joao.pub) allowed-ips 10.100.0.5/32
sudo wg-quick save wg0

O wg set aplica ao vivo; o wg-quick save grava no arquivo para sobreviver ao reinício. Esquecer o segundo é um clássico — funciona hoje e some no próximo boot.

Para revogar:

sudo wg set wg0 peer <chave-publica> remove
sudo wg-quick save wg0

O acesso cai na hora, sem afetar os demais. Compare com o modelo de restringir por IP, em que revogar exige saber qual IP era de quem — informação que ninguém mantém.

Onde isso muda a arquitetura

Adotar VPN permite uma decisão que reduz bastante a superfície exposta: serviços internos param de ter IP público.

O painel administrativo, o banco, a ferramenta de métricas e o ambiente de homologação passam a escutar apenas na rede interna. Deixam de aparecer em varredura, deixam de receber tentativa de acesso, e uma falha divulgada neles deixa de ser urgência de madrugada — porque não há como alcançá-los de fora.

Some a isso a economia de endereço público, que tem custo e é escasso, como discutido no artigo sobre IPv6.

Vale considerar a redundância antes de mover tudo para dentro. Se o servidor de VPN cair, o acesso administrativo cai junto — e é por isso que o console pela virtualização, que não depende da rede, continua sendo a porta de emergência. Ter esse caminho testado antes torna a decisão de fechar as portas bem menos arriscada.

Alta disponibilidade do acesso

Concentrar o acesso administrativo numa VPN cria um ponto único, e vale tratá-lo antes que ele apareça no pior momento.

Três medidas cobrem os cenários realistas:

• Um segundo servidor de VPN, em outra máquina, com o mesmo conjunto de peers. Os clientes ganham um segundo bloco [Peer] apontando para ele. Custa pouco e elimina o caso mais provável.
• Manter o SSH acessível por um caminho alternativo restrito por IP, mesmo que raramente usado. Uma porta a mais aberta para uma faixa conhecida é um preço razoável por não ficar sem acesso.
• O console pela virtualização testado antes de precisar. Ele não depende da rede da máquina, então continua funcionando com a VPN fora, com o firewall bloqueando tudo, e com o SSH parado.

A terceira é a que realmente fecha a questão, e é gratuita. Vale entrar por ela uma vez, em um momento tranquilo, só para saber onde fica e como se comporta — porque descobrir isso durante um incidente é uma experiência bem diferente.

Quando a VPN não é a resposta

Para acesso de aplicação a aplicação — a API que chama outra API, o servidor que acessa o banco —, VPN é a ferramenta errada. Ali a resposta é rede interna com firewall bem definido, sem túnel nenhum no caminho.

WireGuard resolve pessoas alcançando infraestrutura, e alguns casos de máquina em rede não confiável. Usá-lo entre servidores do mesmo ambiente adiciona uma camada que só complica o diagnóstico quando algo falhar.

O que muda para quem opera

Vale fechar com o efeito prático sobre o dia a dia, que é o argumento mais convincente para quem ainda hesita.

Antes: cada serviço interno tinha uma porta aberta, uma senha própria e uma regra de firewall com IPs que ninguém sabia mais de quem eram. Adicionar alguém significava compartilhar credenciais; remover significava trocá-las para todo mundo.

Depois: uma porta aberta, uma chave por pessoa, e os serviços internos deixando de existir para a internet. Adicionar é um bloco de três linhas; remover é apagá-lo.

O ganho de segurança é evidente. O que costuma surpreender é o ganho de organização: pela primeira vez existe uma lista explícita de quem tem acesso ao ambiente, e ela é o próprio arquivo de configuração.