VPN auto-hospedada em um VPS: WireGuard em dez minutos, e a privacidade que ela realmente compra

O que uma VPN realmente faz — e a frase que a maioria das explicações pula

Uma VPN criptografa o seu tráfego e o envia a um servidor, que o descriptografa e o encaminha adiante. A consequência não é que o seu tráfego se torne invisível. É que o conjunto de pessoas capazes de vê-lo muda. Antes: o Wi-Fi do café, o hotel, a operadora móvel, o seu ISP doméstico, e qualquer middlebox nacional acima deles — todos eles veem quais sites você acessa e mais ou menos o quanto você faz ali. Depois: eles veem um único fluxo criptografado de longa duração até um único endereço, e nada sobre o que há dentro dele. Em troca, a rede em que o seu servidor está agora ocupa a posição que eles deixaram vaga.

Esse é todo o mecanismo, e vale a pena ser direto sobre isso porque a versão de marketing — "fique invisível online" — leva as pessoas a esperar uma proteção que o desenho técnico não oferece. Uma VPN é uma mudança de ponto de observação. Se ela ajuda ou não depende inteiramente de o novo ponto de observação ser melhor que o antigo para a coisa específica com que você se preocupa. Deslocar o observador de uma rede de hotel que você nunca tinha ouvido falar para um datacenter escolhido por você, num país escolhido por você, rodando um software configurado por você, costuma ser uma troca muito boa. Deslocá-lo do seu ISP doméstico para uma empresa que anuncia em podcasts é uma troca diferente, e bem menos óbvia.

A auto-hospedagem muda a segunda metade dessa frase e mais nada. A criptografia é idêntica — o design paper do WireGuard descreve o mesmo handshake, seja o peer seu ou de um provedor. O que muda é quem segura a chave privada do outro lado, quem poderia registrar logs se quisesse, de quem é o banco de dados de clientes, e quem mais compartilha o seu endereço de saída. Essas quatro diferenças são todo o argumento a favor e contra rodar a sua própria, e elas não apontam todas na mesma direção.

Sua própria saída ou uma comercial: a troca que você está realmente fazendo

O instinto é tratar a auto-hospedagem como a opção estritamente mais privada, e para a maioria dos modelos de ameaça ela é. Não há provedor guardando um registro de conta, nenhuma infraestrutura compartilhada que possa ser apreendida por conta de outra pessoa, nenhuma política de privacidade para aceitar por fé, e nenhuma possibilidade de uma mudança na política de logs sobre a qual você não foi avisado. Você segura a chave. Ninguém precisa ser confiável, porque ninguém está em posição de trair você.

Mas há uma dimensão em que uma VPN comercial vence de forma categórica, e não é uma dimensão pequena. O endereço de saída delas é compartilhado por centenas ou milhares de pessoas ao mesmo tempo, então um site que recebe uma requisição vinda dali não aprende quase nada sobre qual dessas pessoas a enviou. O seu endereço de saída é compartilhado só por você. Ele é estável, pertence a um único cliente, e todo site que você visita por ele vê o mesmo identificador — exatamente como um IP residencial, só que em outro país. Se o que você quer é desaparecer numa multidão, uma multidão de uma pessoa só não faz isso.

Leia essa tabela como duas perguntas diferentes, não como uma única pontuação. Se o seu adversário é a rede em que você está — um ISP que vende dados de navegação, um local de trabalho que inspeciona TLS, um café, um hotel, um firewall censor — a auto-hospedagem vence em toda linha que importa, porque aquilo de que você está se escondendo fica a montante do túnel e não consegue enxergar através dele. Se o seu adversário é o site que você está visitando, tentando ligar a sessão de hoje à do mês passado, então a multidão é a proteção, e uma saída privada é pior do que inútil. Poucas pessoas estão de fato na segunda situação, e a maioria das que estão deveria estar lendo sobre Tor, não sobre VPNs.

O motivo de as pessoas confundirem as duas coisas é que a indústria vende um único produto sob as duas descrições. A alegação real e defensável de uma VPN comercial é a multidão. Todo o resto do discurso — a promessa de sem logs, as auditorias, a jurisdição de constituição — é uma tentativa de compensar o fato de que você está entregando o seu tráfego a uma empresa. A auto-hospedagem remove a empresa. Ela não consegue fabricar uma multidão.

Quando a auto-hospedagem é a resposta certa

O caso mais claro é uma rede que você não controla e não pode confiar. Wi-Fi de conferência, hotéis, aeroportos, a conexão compartilhada do dono do imóvel, roaming móvel num país com um regime agressivo de interceptação legal. Em todos esses casos a ameaça é local e passiva, e um túnel para qualquer outro lugar a remove por completo. O fato de esse ser o caso de uso menos glamouroso não o torna o menos valioso — é o que se aplica a quase todo mundo, quase toda semana.

O segundo é a jurisdição. Um túnel que sai por Zurique significa que o tráfego que dali parte é regido pela lei suíça, transportado por um provedor de trânsito suíço, e fora do alcance de qualquer regime que governe a sua própria conexão. Isso não é uma abstração para pessoas em países onde o ISP é obrigado a reter e entregar registros de navegação. Escolher o país de saída deliberadamente é uma das poucas decisões de privacidade com um efeito limpo e legível, e vale a pena ler a comparação de jurisdições antes de implantar, não depois.

O terceiro é a censura. Firewalls nacionais bloqueiam VPNs comerciais enumerando as faixas de endereço delas, o que é fácil porque essas faixas são publicadas, vendidas e muito usadas. Um único endereço de VPS numa rede de hospedagem não está em nenhuma lista dessas — não porque seja algo esperto, mas porque ninguém tem motivo para tê-lo catalogado. É por isso que as configurações de contorno mais confiáveis sempre foram pequenas e pessoais, não grandes e comerciais, e é o único lugar em que a multidão é ativamente uma desvantagem.

O quarto é você querer uma saída estável, limpa e controlável para algo além de navegar: alcançar um home lab de fora, dar a uma equipe pequena acesso a serviços internos sem expô-los, rodar um serviço que precisa de um endereço de origem previsível, ou manter uma sessão de longa duração num endereço que não vai trocar debaixo de você. Esses são problemas de engenharia de rede que uma VPN comercial não consegue resolver de jeito nenhum, e um VPS de $8.50 resolve numa tarde. A página da carga de trabalho de VPN cobre o dimensionamento e as especificidades de rede.

E o caso contra: se você não consegue manter um servidor atualizado, não rode um. Um VPS sem manutenção com uma porta SSH aberta é um resultado de privacidade pior do que qualquer VPN comercial, porque uma saída comprometida vê tudo e responde a outra pessoa. A auto-hospedagem troca um problema de confiança por um problema operacional. Essa só é uma boa troca se você realmente for fazer a operação, o que a última seção deste guia reduz a cerca de dez minutos por mês.

WireGuard em dez minutos: a configuração inteira

O WireGuard é pequeno o bastante para se ler por inteiro. Ele vive no kernel do Linux, fala numa única porta UDP, usa um conjunto fixo de primitivas modernas sem negociação, e toda a sua superfície de configuração são dois tipos de bloco: um [Interface] descrevendo esta máquina, e um [Peer] para cada dispositivo autorizado a se conectar. Não há autoridades certificadoras, nenhuma cipher suite para escolher mal, e nenhum daemon para ajustar. Esse minimalismo é o motivo de ser difícil configurá-lo errado de um jeito perigoso, e o motivo de ele ter substituído as alternativas em quase todo lugar.

Comece instalando o pacote e gerando um par de chaves. Defina umask 077 primeiro para que a chave privada não seja gravada com leitura liberada para todos — o wg-quick vai reclamar bastante se estiver, e com razão. wg genkey produz a chave privada, wg pubkey deriva a metade pública a partir dela. Faça o mesmo em cada cliente. As chaves públicas são trocadas; as chaves privadas nunca saem da máquina que as gerou.

Depois escreva o /etc/wireguard/wg0.conf. A tabela abaixo é o arquivo completo para um servidor funcional — nada foi omitido por brevidade.

Duas coisas fora do arquivo também precisam ser verdadeiras. O kernel precisa estar disposto a encaminhar pacotes: defina net.ipv4.ip_forward=1 e net.ipv6.conf.all.forwarding=1, e escreva-as em /etc/sysctl.d/ para que sobrevivam a uma reinicialização. E a regra de NAT em PostUp precisa nomear a interface pública real — na maioria das imagens de nuvem isso é eth0, mas confira com ip route get 1.1.1.1 em vez de presumir. Um nome de interface errado é o motivo isolado mais comum de uma primeira configuração de WireGuard conectar e não ir a lugar nenhum.

Suba a interface com wg-quick up wg0, confirme com wg show que a interface existe e lista seus peers, depois rode systemctl enable --now wg-quick@wg0 para que ela volte após uma reinicialização. Do lado do cliente o arquivo é quase idêntico, com três diferenças que importam: AllowedIPs vira 0.0.0.0/0, ::/0 — significando roteie tudo por aqui em vez de aceite estas origens — uma linha Endpoint aponta para o endereço público e a porta do servidor, e PersistentKeepalive = 25 mantém o mapeamento vivo através de roteadores domésticos que, de outra forma, o derrubariam por timeout. Em celulares, passe a configuração do cliente por qrencode -t ansiutf8 e escaneie-a a partir do terminal. Não envie arquivos de configuração por um aplicativo de mensagens; a chave privada está ali dentro.

Os quatro vazamentos que contornam o túnel

Um túnel que carrega tráfego não é a mesma coisa que um túnel que carrega todo o tráfego, e a lacuna entre essas duas coisas é onde vive toda falha real de VPN. Cada um dos quatro casos abaixo é uma situação em que o túnel está funcionando perfeitamente e o seu tráfego está contornando-o, e nenhum deles se anuncia. Você precisa procurar.

DNS. Se o cliente continuar usando qualquer resolvedor que a rede local tenha distribuído, o túnel carrega o seu tráfego enquanto o servidor DHCP do café continua recebendo, ao vivo, todo domínio que você consulta. Os nomes sozinhos já são quase o quadro inteiro. Corrija isso definindo uma linha DNS = explícita na configuração do cliente, ou, melhor ainda, rode um resolvedor no VPS vinculado ao endereço do túnel e aponte os clientes para ele — assim as consultas também atravessam o túnel e terminam numa máquina que é sua. Verifique pelo lado do cliente, não do servidor, usando qualquer teste de vazamento de DNS; você deve ver exatamente um resolvedor, e ele deve ser o seu.

IPv6. A clássica falha silenciosa. Se o AllowedIPs no cliente diz apenas 0.0.0.0/0, você disse ao sistema operacional para rotear IPv4 pelo túnel e não disse nada sobre IPv6. Numa rede dual-stack — o que hoje descreve a maioria das redes domésticas e móveis — todo site que tem um registro AAAA é alcançado pelo seu endereço real, fora do túnel, enquanto um teste de vazamento que só checa v4 reporta que está tudo bem. Ou você adiciona ::/0 e distribui endereços v6 dentro do túnel, ou desativa o IPv6 no cliente de vez. Não fazer nenhum dos dois é o padrão, e o padrão é falho.

A ausência de um kill switch. Quando o túnel cai — o notebook suspende, o celular troca de torre, o servidor reinicia para uma atualização de kernel — o sistema operacional faz a gentileza de voltar para a rede local. O tráfego que você acreditava estar tunelado não está, e nada avisa você disso. No Linux, o wg-quick com a tabela de roteamento padrão já falha fechado para a maior parte do tráfego, mas a correção confiável é uma regra explícita de firewall que descarta tudo que não sair via wg0. No Android e no iOS, ative Always-on VPN e Block connections without VPN. Em clientes desktop, confira se a opção existe antes de presumir que existe.

MTU. Não é um vazamento de privacidade, mas é o motivo pelo qual as pessoas desistem. O encapsulamento do WireGuard custa 60 bytes para IPv4 e 80 para IPv6, então o MTU padrão de interface de 1420 cabe dentro de um caminho normal de 1500 bytes. Sobre PPPoE, algumas redes móveis, ou um segundo túnel, o caminho real é menor, e o sintoma é peculiar: pings funcionam, páginas pequenas carregam, e handshakes TLS grandes travam para sempre. Se isso descreve o que você está vendo, baixe o MTU do cliente para 1380 ou 1280 e ele simplesmente vai passar a funcionar.

Uma coisa que uma VPN não consegue corrigir, e vale a pena dizer isso para que você não espere que ela corrija: um observador capaz de vigiar as duas pontas ao mesmo tempo consegue correlacioná-las por tempo e volume, com ou sem túnel. Criptografia esconde conteúdo, não o formato de uma conversa. Defender-se desse adversário exige misturar o seu tráfego com o de outras pessoas através de múltiplos relays, que é para isso que o Tor serve e que uma VPN de salto único estruturalmente não serve. Se esse é o seu modelo de ameaça, uma VPN auto-hospedada é a ferramenta errada, e nenhuma configuração dela vai torná-la a certa.

Fazendo o endereço de saída se comportar lá fora

O endereço de onde o seu túnel sai pertence a uma rede de hospedagem, e boa parte da web moderna classifica endereços em residencial e datacenter antes de decidir como tratar você. Catálogos de streaming, alguns bancos, sites de venda de ingressos e boa parte das ferramentas antifraude tratam qualquer coisa vinda de uma rede de hospedagem como suspeita por padrão. Isso não é algo que uma mudança de configuração corrige — é uma propriedade de onde o servidor mora, e se aplica igualmente a um túnel auto-hospedado e a toda VPN comercial do mercado. Quem promete o contrário está descrevendo um jogo de gato e rato que está perdendo no momento.

O que de fato difere é em quais listas o seu endereço aparece. Faixas de VPN comercial são enumeradas, publicadas e vendidas como feeds justamente porque são grandes, estáticas e compartilhadas; um site que quer bloquear VPNs compra a lista. Um único endereço numa rede de hospedagem genérica não está nela. Na prática isso significa que saídas auto-hospedadas atravessam sem problema uma parte surpreendente da web comum que bloqueia provedores comerciais de cara, ainda que esbarrem numa parede nos serviços específicos que bloqueiam todo tráfego de datacenter. Espere um CAPTCHA extra ocasional, e nada muito além disso.

Algumas coisas valem a pena ser feitas uma única vez. Configure um registro de DNS reverso simples e sem graça no endereço em vez de deixar o padrão do provedor — muitos sistemas de reputação leem o PTR, e um hostname genérico pontua melhor do que algo que soa como infraestrutura. Mantenha o túnel totalmente fora da porta 25; e-mail de saída de um endereço de hospedagem recém-criado cai em pastas de spam não importa o que você faça, e o problema de entregabilidade é um projeto próprio de várias semanas. E se o endereço acabar envenenado — herdado de um inquilino anterior, ou por algo que um dos seus próprios peers fez — peça um re-IP em vez de brigar com isso. Fazemos o re-IP dos clientes para um endereço novo no mesmo prefixo, sem custo; abra um ticket no painel e fica pronto em um dia.

A última consideração é quem mais está atrás do seu túnel. Como todo peer compartilha um único endereço de saída, o comportamento de uma pessoa vira a reputação de todo mundo. Uma casa, sem problema. Um grupo de vinte conhecidos em que você não sabe o que metade deles está fazendo é assim que um endereço limpo vira um endereço bloqueado, e é assim que uma denúncia de abuso chega com o nome da sua conta nela. Se você está distribuindo peers além de pessoas por quem você se responsabilizaria, dê a elas a própria instância em vez disso — a $8.50 por mês essa é uma resposta mais barata do que a alternativa.

A camada que ninguém configura: como você pagou pela máquina

Eis a falha que desfaz tudo o que veio antes, e ela não tem nada a ver com o WireGuard. O tráfego sai do seu endereço de saída. O endereço pertence a um servidor. O servidor pertence a uma conta. A conta foi aberta com um endereço de e-mail e paga com um cartão no seu nome. Nesse ponto, a cadeia do tráfego de volta até você tem quatro saltos, está inteiramente documentada, e está sentada no banco de dados de faturamento de um provedor esperando alguém perguntar. Você não removeu um observador; você o moveu para um lugar com registros melhores.

Essa é a diferença entre uma VPN que muda a sua posição de rede e uma VPN que muda a sua exposição, e ela é decidida no checkout, não no arquivo de configuração. Se o motivo de você querer uma saída privada é que o seu ISP ou o seu governo não deveriam ter o seu histórico de navegação, e o servidor é alugado sob a sua identidade legal por meio de um pagamento com cartão, a configuração ainda funciona — o ISP genuinamente não consegue ver através do túnel. Mas isso é uma melhora de privacidade contra um observador específico, não contra um observador determinado. Seja claro consigo mesmo sobre qual das duas coisas você está comprando.

Fechar essa brecha significa que a conta não pode identificar você, e o pagamento também não. Isso significa nenhuma verificação de identidade no cadastro — um e-mail descartável e nada além disso, que é o que hospedagem sem KYC realmente significa na prática — e pagamento por um trilho que não carrega o seu nome. Monero é a resposta mais limpa porque os valores e as partes não estão em nenhum ledger público; o passo a passo leva cerca de cinco minutos do início ao fim. Bitcoin funciona, mas é um registro público permanente, então é só tão privado quanto as moedas que entraram nele, e a comparação entre os dois vale a pena ler antes de você decidir que isso não importa.

Depois há a jurisdição, que determina o que qualquer um poderia obrigar mesmo que perguntasse. Um provedor constituído fora da esfera dos 14-Eyes, com datacenters em países cuja lei de retenção não exige guardar registros de tráfego, é estruturalmente incapaz de entregar um histórico de navegação que nunca coletou. Essa é uma garantia mais forte do que uma promessa de não olhar. Para a versão completa desse argumento — o que é genuinamente rastreável num servidor alugado e o que não é — a resposta honesta está aqui, incluindo as partes menos reconfortantes do que o marketing.

Dimensionamento: quão pouco servidor um túnel realmente precisa

O WireGuard é notavelmente barato de rodar. Ele vive no kernel, então os pacotes nunca são copiados para o userspace; ele usa ChaCha20-Poly1305, que é rápido em qualquer CPU e não depende de aceleração AES para continuar rápido; e mantém apenas alguns kilobytes de estado por peer, e nada além disso. Um único núcleo moderno empurra algo em torno de um gigabit de throughput criptografado, e a memória praticamente nunca é a restrição. O limite prático num túnel de VPS é o uplink, não o processador.

O que significa que a maioria das pessoas escolhe um plano pelo motivo errado. Uma casa com cinco dispositivos navegando, assistindo streaming e fazendo videochamadas o dia todo está longe dos limites do menor plano — a CPU fica ociosa e a banda é ilimitada. Suba de plano quando você tiver muitos peers simultâneos empurrando tráfego real ao mesmo tempo, ou quando quiser mais margem no uplink, não porque um túnel parece que deveria ser exigente.

A localização importa mais do que o hardware para a sensação de uso do túnel. Todo pacote que você envia faz um desvio pelo servidor, então a sua latência para tudo vira a sua latência até o servidor mais a latência do servidor dali para frente. Escolha um datacenter perto de você se o túnel fica sempre ligado e a responsividade importa para você; escolha um perto daquilo que você está tentando alcançar se não for o caso. Amsterdã é o caminho mais curto de volta para a maior parte da Europa, Zurique e Reykjavík trocam alguns milissegundos por jurisdições com lei de privacidade mais forte, e Bucareste fica entre as duas em ambos os quesitos.

Mais uma coisa que vale a pena saber antes de escolher: o handshake do WireGuard tem um formato reconhecível no fio, e um firewall fazendo inspeção profunda de pacotes consegue identificá-lo e descartá-lo sem saber nada sobre o destino. Na maior parte do mundo isso nunca chega a ser um problema. Num punhado de redes, isso significa que o WireGuard sozinho não vai conectar, e você precisa de um transporte ofuscador na frente dele — Shadowsocks, uma pilha xray ou v2ray, ou um dos forks do WireGuard que preenche o handshake. Todos eles rodam na mesma instância; é uma camada adicionada por cima, não um plano diferente.

Rodando isso por anos sem precisar pensar a respeito

A carga operacional de um endpoint pessoal de WireGuard é próxima de zero, mas não é exatamente zero, e a diferença é o que separa uma saída privada de uma comprometida. Tudo abaixo é uma configuração feita uma única vez, exceto o último item, que leva cerca de dez minutos por mês.

Tranque a porta da frente primeiro. SSH apenas com chaves — PasswordAuthentication no, PermitRootLogin prohibit-password — e um firewall que aceita exatamente duas coisas vindas da internet: a porta UDP do WireGuard, e o SSH. Se você quiser ser rigoroso, mova o SSH para que ele escute apenas no endereço do túnel, o que significa que o único serviço alcançável na interface pública é o próprio WireGuard, e o WireGuard não responde a pacotes não autenticados de jeito nenhum. Um escaneamento de portas da máquina então não retorna nada, o que é uma propriedade genuinamente incomum para um servidor exposto à internet.

Ative as atualizações de segurança automáticas e deixe-as rodar. O kernel importa aqui de um jeito que não importa na maioria dos servidores, porque a implementação do WireGuard faz parte dele. Reinicie quando uma atualização de kernel chegar; o wg-quick@wg0 no systemd traz o túnel de volta sozinho, e clientes com PersistentKeepalive reconectam em segundos sem ninguém tocar em nada.

Trate as chaves como contas, porque é isso que elas são. Um par de chaves por dispositivo, nunca compartilhado entre dois. Revogar acesso é apagar aquele bloco [Peer] e rodar wg syncconf wg0 <(wg-quick strip wg0), o que aplica a mudança sem derrubar a sessão de mais ninguém. Faça backup de /etc/wireguard/ em algum lugar criptografado e fora da máquina — perdê-lo significa reinscrever cada dispositivo manualmente. Se o servidor guarda qualquer outra coisa com que você se importa, criptografia de disco completo é uma adição razoável, embora para um túnel puro haja muito pouco no disco que valha a pena criptografar além daquele único diretório.

Monitore sem registrar logs. O wg show te dá o horário do último handshake de cada peer, o que já basta para responder toda pergunta operacional que você realmente vai ter — está no ar, este dispositivo está conectado, quando ele checou pela última vez. Resista ao impulso de adicionar contabilização de tráfego ou logs de conexão: você construiu isso especificamente para que ninguém guarde um registro de para onde o seu tráfego vai, e a pessoa mais propensa a criar esse registro agora é você mesmo. Do nosso lado não há nada para desativar — sem netflow, sem espelhamento de portas, sem captura de tráfego de nenhum tipo, e tabelas ARP que expiram em 24 horas, o que está documentado na página de privacidade, não apenas prometido num rodapé.

Isso é todo o trabalho. Quinze linhas de configuração, um firewall, atualizações de segurança num cronograma, e uma olhada mensal no wg show. A parte difícil de uma VPN auto-hospedada nunca foi a VPN — é lembrar que o túnel só realoca o observador, e que tudo o que essa realocação vale depende dos quatro vazamentos acima estarem fechados e da conta por trás dele não levar de volta até você.