Monte sua própria VPN: WireGuard em um VPS offshore

Por que rodar sua própria VPN

Uma VPN comercial pede que você confie na alegação de no-logs de uma única empresa por milhares de usuários que compartilham um punhado de IPs de saída. Hospedar você mesmo o WireGuard em um VPS offshore inverte esse modelo de confiança: você guarda as chaves, define a política de logs, e os únicos metadados que existem são os que você escolhe manter. Para alguns modelos de ameaça essa é a troca certa — você deixa de confiar em peças de marketing e passa a confiar na sua própria configuração somada à jurisdição em que o servidor está.

O WireGuard é a escolha moderna para a tarefa. São alguns poucos milhares de linhas de código de kernel auditado com uma superfície de ataque minúscula ao lado do OpenVPN ou do IPsec, e ele vem com criptografia moderna fixa — Curve25519, ChaCha20-Poly1305, BLAKE2s — então não há suite de cifras para configurar errado e acabar com algo fraco. Os handshakes são rápidos, a transição entre Wi-Fi e dados móveis é perfeita e um túnel ocioso custa quase nada. Em um VPS offshore você ganha uma saída dedicada em uma jurisdição que você escolhe entre 6 regiões, online em cerca de 15 min, com a mitigação 1.5 Tbps de L3/4 e uma porta sem medição padrão em todos os planos.

O que um túnel auto-hospedado oculta — e o que não oculta

Seja honesto sobre o modelo antes de construí-lo. Um túnel auto-hospedado criptografa tudo entre o seu dispositivo e o VPS, ocultando-o da sua rede local e do seu provedor de internet, e substitui o seu IP doméstico pelo IP do VPS para tudo o que você roteia por ele. Isso é genuinamente útil em Wi-Fi hostil, para alcançar seus próprios serviços por trás de um endereço estável ou para manter seu provedor de acesso fora da sua navegação.

O que ele não faz é te tornar anônimo. O IP de saída é só seu — não há uma multidão de outros usuários para você se misturar, então qualquer um que consiga correlacionar as duas pontas da conexão, ou que obtenha uma ordem vinculante contra a hospedagem, pode atribuir aquele endereço à sua conta. Do lado da hospedagem, a postura é fixa: notificações de DMCA não são processadas nem respondidas — o DMCA é uma lei dos EUA sem força em nossas jurisdições, e só agimos diante de uma ordem vinculante de um tribunal com jurisdição sobre o servidor específico. Isso te protege de robôs de derrubada automatizada; não transforma uma VPN de usuário único em uma ferramenta de anonimato. Se o seu adversário for um observador passivo global, recorra ao Tor em vez disso. Um túnel auto-hospedado é uma ferramenta de confidencialidade e controle, não um manto de invisibilidade.

Escolha primeiro a localização e o plano

Uma VPN pessoal é limitada por banda, não por CPU, então o plano mais simples basta — o VPS Drift a $8.00/mês vai saturar sua porta muito antes de a vCPU se esforçar. Gaste seu orçamento de decisão no onde. Coloque o servidor perto de você quando a latência para uso interativo importar, ou longe de você quando a distância jurídica importar mais do que o tempo de ida e volta.

Romênia e Países Baixos são cobrados à tarifa base e têm a melhor conectividade europeia; Suíça, Islândia, Malásia e Panamá aplicam um modificador regional exibido ao vivo no configurador. A Malásia é a escolha para a Ásia-Pacífico; Panamá e Islândia pendem mais fortemente para a distância jurisdicional. Se estiver em dúvida, o guia complementar qual localização offshore você deve escolher? percorre os trade-offs região por região. Qualquer que seja sua escolha, abasteça seu saldo a partir de $30.00 com cripto e implante — não há verificação de identidade nem cartão registrado.

Como as peças se encaixam

O WireGuard modela uma VPN como um conjunto de peers, cada um identificado por uma chave pública, conversando sobre uma interface virtual (aqui wg0). O servidor recebe uma sub-rede privada — digamos 10.66.0.0/24 mais uma ULA IPv6 — e cada cliente assume um endereço dentro dela. O bloco [Interface] do servidor guarda sua chave privada e a porta de escuta; cada cliente é um bloco [Peer] que carrega a chave pública daquele cliente e os endereços que ele tem permissão de usar.

No lado do cliente, AllowedIPs = 0.0.0.0/0, ::/0 é o que faz disto uma VPN de túnel completo: diz ao cliente para rotear todo o tráfego através do wg0. O servidor então faz NAT desse tráfego pela sua interface de rede real com uma regra de masquerade, e é por isso que o encaminhamento de IP precisa estar habilitado no kernel. PersistentKeepalive = 25 mantém o caminho aberto através de firewalls com estado e do NAT da operadora. Defina o DNS no cliente para um resolvedor em que você confie, de modo que as consultas viajem dentro do túnel em vez de vazar para a sua rede local. O próprio WireGuard é sem conexão — não há sessão de longa duração para cair, então o enlace sobrevive a um laptop adormecido ou a um celular trocando de Wi-Fi para dados móveis sem nenhuma dança de reconexão. Se um caminho tiver um MTU complicado e pacotes grandes travarem, baixar o MTU da interface do cliente para cerca de 1380 normalmente resolve. Entenda essas quatro ideias — interface, peers, AllowedIPs, masquerade — e a configuração abaixo se lê como prosa.

Reforce o servidor já que está nele

Vale a pena reforçar a segurança de um endpoint de VPN. Mude o SSH para autenticação somente por chave e desative os logins por senha e por root em /etc/ssh/sshd_config (PasswordAuthentication no, PermitRootLogin prohibit-password), depois recarregue o sshd. Mantenha o firewall com negação padrão: as únicas portas de entrada de que uma máquina WireGuard precisa são o SSH e a UDP 51820. Todo o resto permanece fechado.

Mantenha os arquivos de chave do WireGuard em 0600 — o umask 077 nos passos abaixo cuida disso — e nunca copie uma chave privada para fora do host ao qual ela pertence. Ative as atualizações de segurança automáticas para que o kernel e o pacote wireguard continuem corrigidos sem precisar de babá. Teste vazamentos de DNS assim que o túnel estiver no ar — uma consulta que resolve pelo resolver que você escolheu, e não pelo seu provedor de acesso, confirma que as consultas realmente estão ficando dentro do wg0. Se você expuser outros serviços mais tarde, adicione o fail2ban e regras por serviço em vez de abrir mais o firewall. Nada disso depende do host: o VPS é seu, o root é seu, e o compromisso de uptime de 99.9% mantém a máquina acessível para que seu túnel continue no ar.

Adicione mais dispositivos e mantenha tudo funcionando

Todo dispositivo que se conecta precisa do seu próprio par de chaves e do seu próprio bloco [Peer] no servidor, cada um com um endereço exclusivo dentro da sub-rede — reutilizar um único par de chaves entre um notebook e um celular quebra o roaming e atrapalha qualquer diagnóstico. Gere um novo par client2.key/client2.pub, acrescente um peer e recarregue a interface com wg syncconf wg0 <(wg-quick strip wg0) ou reinicie-a com systemctl restart wg-quick@wg0.

Para celulares, dispense por completo a cópia de arquivos: gere a configuração do cliente como um QR code no servidor com qrencode -t ansiutf8 < client.conf e leia-o diretamente no app oficial do WireGuard. Para ver quem está conectado e quando cada peer fez o último handshake, execute wg show — é toda a história de monitoramento que uma implantação pessoal precisa. Snapshots antes de uma atualização de kernel garantem um rollback limpo caso uma nova versão um dia se comporte mal.

Quando uma VPN comercial ou o Tor é a ferramenta melhor

O self-hosting nem sempre é a resposta, e fingir o contrário seria desonesto. Se o seu objetivo é desaparecer no meio da multidão, uma VPN multiusuário de boa reputação lhe dá IPs de saída compartilhados que muitas pessoas usam ao mesmo tempo — um túnel de inquilino único não pode oferecer isso. Se você precisa alternar entre países de saída sob demanda, um serviço comercial com um app de troca por clique é simplesmente mais conveniente do que subir máquinas. E se você precisa de anonimato genuíno contra um adversário bem aparelhado, o roteamento onion do Tor foi projetado exatamente para o problema de correlação que uma VPN self-hosted não consegue resolver.

O ponto em que o self-hosting ganha é controle e confidencialidade: você não está confiando na política de logs de mais ninguém, ganha um IP dedicado estável para administração e allowlists, e você decide a jurisdição. Muita gente usa os dois — um túnel self-hosted para a confidencialidade do dia a dia e o Tor para a tarefa rara que exige anonimato. Escolha a ferramenta que combina com a ameaça, não a que tem a melhor landing page.

Passo a passo

1. 01

   Implante o VPS e instale o WireGuard

   Implante um VPS com Debian 13 ou Ubuntu 24.04, entre como root via SSH, depois atualize e instale os dois pacotes de que você precisa.

   apt update && apt full-upgrade -y
   apt install -y wireguard qrencode

2. 02

   Habilite o encaminhamento de IP

   Uma VPN de túnel completo encaminha o tráfego do cliente pela interface do servidor, então o kernel precisa permitir o encaminhamento para IPv4 e IPv6.

   cat > /etc/sysctl.d/99-wg.conf <<'EOF'
   net.ipv4.ip_forward=1
   net.ipv6.conf.all.forwarding=1
   EOF
   sysctl --system

3. 03

   Gere as chaves do servidor

   Trabalhe em /etc/wireguard com um umask restrito para que todo arquivo de chave fique em 0600.

   cd /etc/wireguard
   umask 077
   wg genkey | tee server.key | wg pubkey > server.pub

4. 04

   Gere um par de chaves do cliente

   Cada dispositivo recebe o seu próprio par de chaves. Crie o primeiro agora.

   wg genkey | tee client.key | wg pubkey > client.pub

5. 05

   Escreva a configuração do servidor

   Descubra a sua interface de rede real com ip route get 1.1.1.1 e substitua eth0 abaixo caso seja diferente (muitas vezes é enp1s0). As chamadas $(cat ...) inserem inline as chaves que você acabou de criar.

   cat > /etc/wireguard/wg0.conf <<EOF
   [Interface]
   Address = 10.66.0.1/24, fd86:ea04:1115::1/64
   ListenPort = 51820
   PrivateKey = $(cat server.key)
   PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
   PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
   
   [Peer]
   PublicKey = $(cat client.pub)
   AllowedIPs = 10.66.0.2/32, fd86:ea04:1115::2/128
   EOF

6. 06

   Escreva a configuração do cliente

   Crie o client.conf no mesmo diretório. Cole o conteúdo de client.key e server.pub onde indicado, e defina o Endpoint como o IP público do seu servidor. AllowedIPs = 0.0.0.0/0, ::/0 roteia tudo pelo túnel.

   [Interface]
   PrivateKey = <paste client.key>
   Address = 10.66.0.2/32, fd86:ea04:1115::2/128
   DNS = 9.9.9.9
   
   [Peer]
   PublicKey = <paste server.pub>
   Endpoint = YOUR_SERVER_IP:51820
   AllowedIPs = 0.0.0.0/0, ::/0
   PersistentKeepalive = 25

7. 07

   Abra o firewall

   Permita o SSH e a porta UDP do WireGuard, depois habilite o ufw. Mantenha a postura de negação padrão para todo o resto.

   ufw allow OpenSSH
   ufw allow 51820/udp
   ufw enable

8. 08

   Suba o túnel

   Habilite a interface para que ela sobreviva a reinicializações, depois confirme os peers e os handshakes.

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

9. 09

   Conecte um celular com um QR code

   Gere a configuração do cliente como um código escaneável e importe-a para o app móvel do WireGuard — sem necessidade de transferência de arquivos.

   qrencode -t ansiutf8 < client.conf