WireGuard a fundo: como funciona e como chegou até aqui

Antes do WireGuard, as opções principais eram IPsec e OpenVPN. O IPsec é uma grande família de padrões, com uma infinidade de configurações, e fazer equipamentos de fabricantes diferentes conversarem é famoso pela dor de cabeça; o OpenVPN roda no espaço do usuário e depende de uma biblioteca TLS enorme — flexível, porém lento. Os dois têm tanto código que é difícil alguém auditá-los por inteiro.

O WireGuard fez o contrário: fazer uma única coisa e fazê-la direito. No sistema, ele aparece como uma placa de rede virtual (por exemplo, wg0); você configura nela a sua chave privada e as chaves públicas de alguns pares, e todo pacote enviado para ela sai criptografado, enquanto os pacotes recebidos saem dela já decifrados. Todo o resto — rotas, firewall, distribuição de endereços — fica com as ferramentas que o sistema já tem.

O que ele deixa de fazer de propósito também é bem claro: não negocia algoritmos, não lida com usuário e senha, não distribui endereços, não disfarça o tráfego. Essas coisas ou são vistas como fonte de falhas de segurança, ou ficam para ferramentas de camadas superiores.

No WireGuard, cada aparelho tem um par de chaves, e a chave pública é a sua identidade, num esquema parecido com o do SSH: cada lado coloca a chave pública do outro na própria configuração e pronto, a confiança está estabelecida — sem certificado, sem usuário e senha.

Na configuração, cada par recebe uma linha de “endereços permitidos” (AllowedIPs), que vale para os dois sentidos: ao enviar, o pacote é criptografado com a chave pública do par em cuja faixa permitida está o endereço de destino e vai para ele; ao receber, depois de decifrar, o WireGuard confere se o endereço de origem está na faixa permitida daquele par e, se não estiver, descarta. Esse esquema se chama cryptokey routing (roteamento por chave criptográfica): a tabela de rotas e o controle de acesso viram uma tabela só.

Por isso, colocar 0.0.0.0/0 como endereço permitido de um par significa “mandar todo o tráfego para ele” — a chamada VPN global; colocar só a faixa de uma rede interna faz o túnel ser usado apenas para acessar essa rede.

Antes da primeira comunicação, os dois aparelhos fazem um handshake: quem inicia manda um pacote, o outro responde com um pacote e pronto — numa única ida e volta, os dois obtêm chaves de sessão válidas só por aquele período. O handshake segue o framework do protocolo Noise: as chaves de longo prazo dos dois lados servem para autenticação mútua, e chaves temporárias garantem o sigilo futuro (forward secrecy) — mesmo que uma chave privada de longo prazo vaze depois, o tráfego gravado no passado continua impossível de decifrar.

As chaves de sessão são trocadas automaticamente a cada poucos minutos, de forma invisível para o usuário, e não existe isso de “reconectar”.

Os algoritmos são fixos: Curve25519 para a troca de chaves, ChaCha20-Poly1305 para criptografar os dados e BLAKE2s para o hash. Sem negociação, não há ataque de downgrade — o atacante não tem como induzir os dois lados a usar um algoritmo mais fraco. Se algum desses algoritmos for quebrado no futuro, a solução é lançar uma nova versão do protocolo inteira, e não acrescentar uma opção.

Também dá para acrescentar uma chave pré-compartilhada, somada ao mecanismo de chave pública, como precaução contra a ameaça que futuros computadores quânticos representam para os algoritmos de chave pública.

• Só UDP: o WireGuard criptografa cada pacote separadamente e o envia dentro de um pacote UDP. Não usar TCP é intencional — com TCP dentro de TCP, as duas camadas ficam retransmitindo e, quando há perda de pacotes, uma atrapalha a outra.
• Silêncio para desconhecidos: pacotes que não passam na autenticação nunca recebem resposta. Para quem varre portas, a porta parece fechada, e não há como saber que ali roda um WireGuard.
• Roaming: o WireGuard não reconhece “conexões”, só chaves públicas. Se o par muda de endereço — um celular que passa do Wi‑Fi para os dados móveis —, basta o próximo pacote dele passar na autenticação para que as respostas passem a ir para o novo endereço automaticamente. Por isso o túnel não cai quando você troca de rede.
• Silencioso: quando não há dados para enviar, o túnel não gera tráfego nenhum, o que economiza muita bateria no celular. Só quando o aparelho está atrás de um roteador e precisa continuar acessível para o outro lado é que vale ligar o keepalive periódico (PersistentKeepalive), que manda um pacotinho a cada algumas dezenas de segundos para manter o mapeamento no roteador.

• Roda no kernel: no Linux, o WireGuard é um módulo do kernel, e os pacotes não ficam sendo copiados entre o kernel e um programa de usuário; o OpenVPN tradicionalmente roda no espaço do usuário, e cada pacote dá uma volta a mais.
• Algoritmos bons para qualquer CPU: o ChaCha20 não depende de instruções especiais de aceleração em hardware, o que é uma vantagem e tanto em chips sem instruções AES, como os de celulares e roteadores.
• Handshake curto: com uma única ida e volta já dá para enviar dados, quase sem espera para estabelecer a conexão.
• Pouco código: o caminho é curto, e toda otimização possível foi feita nas poucas etapas críticas.
• Atenção: tudo isso fala do custo do protocolo e da implementação em si. Nas linhas internacionais, a velocidade real depende muito mais da perda de pacotes da linha e de como a operadora trata o UDP.

• Por volta de 2015: Jason A. Donenfeld começa a desenvolver e divulga o WireGuard, no início um módulo de kernel independente para Linux.
• 2017: o artigo descrevendo o projeto é publicado na conferência de segurança de redes NDSS, e o protocolo passa em seguida por várias verificações formais independentes. Por essa época, provedores de VPN como a Mullvad começam a oferecer acesso por WireGuard.
• 2018: o criador do Linux, Linus Torvalds, elogia o código numa lista de e-mails e diz que, comparado a OpenVPN e IPsec, ele é uma obra de arte — frase que tornou o WireGuard conhecido entre os desenvolvedores.
• 2019: a Cloudflare lança o BoringTun, uma implementação em espaço de usuário escrita em Rust, e passa a usar WireGuard no seu WARP; a NordVPN lança o NordLynx, baseado em WireGuard; e a Tailscale também nasce nessa época, com o WireGuard como plano de dados.
• Março de 2020: o WireGuard entra oficialmente na linha principal do kernel com o Linux 5.6, junto com a versão 1.0. A partir daí, as principais distribuições Linux já trazem o WireGuard, sem módulo extra. No mesmo ano, o OpenBSD também o incorpora ao kernel.
• 2021: chega ao Windows a implementação em modo kernel WireGuardNT, bem mais rápida que a antiga em espaço de usuário; o FreeBSD ganha a sua implementação de kernel logo depois.
• Hoje: há clientes oficiais para Windows, macOS, Linux, iOS e Android, sistemas de roteadores e NAS como OpenWrt e Synology têm suporte embutido, e a grande maioria das VPNs comerciais o oferece como protocolo padrão ou opcional.

• Não cuida da distribuição de chaves: a cada aparelho novo, a chave pública dele precisa ser colocada na configuração dos outros. Com muitos aparelhos fica impossível de gerenciar — e é exatamente por isso que existem ferramentas como o Tailscale.
• Não distribui endereços dinamicamente: o endereço interno de cada par fica fixo na configuração, sem o mecanismo do OpenVPN de “receber um endereço ao conectar”. As VPNs comerciais que o usam precisam construir mais uma camada por fora.
• Questões de privacidade: o servidor precisa lembrar o último endereço público de cada par para conseguir responder. Provedores de VPN que prometem “não guardar registros” normalmente precisam de um tratamento extra (como limpeza periódica ou dupla tradução de endereços).
• Só UDP: em redes que bloqueiam ou limitam o UDP, não funciona ou fica muito lento. Para fazê-lo passar por TCP ou pela porta 443, só envolvendo-o em outra ferramenta.
• Sem disfarce: o formato e o tamanho dos pacotes de handshake e de dados têm um padrão fixo, fácil de identificar. O objetivo do projeto é segurança e simplicidade, não resistir à censura.
• Sem sistema de contas: o protocolo não tem usuário, senha nem data de vencimento; só reconhece chaves públicas.

• Quantidade de código: o núcleo do WireGuard tem alguns milhares de linhas; o OpenVPN com a biblioteca TLS de que depende, e as várias implementações de IPsec, estão na casa das centenas de milhares.
• Transporte: o WireGuard só usa UDP; o OpenVPN aceita os dois e pode usar TCP 443, misturando-se à porta do tráfego HTTPS; o IPsec usa número de protocolo próprio e UDP 500 / 4500.
• Configuração: no WireGuard, cada par são poucas linhas; o arquivo do OpenVPN tem muitas opções, mas é muito flexível; o IPsec é o mais complicado.
• Desempenho: em redes limpas, o WireGuard costuma ser o mais rápido e o que menos gasta bateria; as versões novas do OpenVPN também ganharam aceleração no kernel (DCO), e a diferença vem diminuindo.
• Recursos: autenticação por usuário e senha, envio dinâmico de endereços e rotas e uso de TCP já vêm no OpenVPN; no WireGuard, tudo isso precisa vir de um sistema externo.
• Compatibilidade: o OpenVPN tem uma longa história, e roteadores antigos, NAS e todo tipo de aparelho embarcado quase sempre o reconhecem; o WireGuard já é comum nos sistemas dos últimos anos, mas nem sempre existe em aparelhos antigos.

• Tailscale: acrescenta ao WireGuard login, distribuição de chaves, travessia de NAT e retransmissão, criando uma rede automática entre aparelhos — veja Tailscale a fundo. O Headscale é uma implementação de código aberto do servidor de controle dele.
• Netmaker, NetBird, Firezone e outros: também produtos de rede entre aparelhos ou de confiança zero, com o WireGuard no plano de dados e uma camada de gerenciamento própria.
• Cloudflare WARP: um cliente WireGuard para o usuário comum, que leva o tráfego para dentro da rede da Cloudflare.
• Versões próprias de VPNs comerciais: como o NordLynx, que envolve o WireGuard numa camada de distribuição de endereços e de tratamento de privacidade.
• Variantes como o AmneziaWG: alteram cabeçalhos e preenchimento para esconder o padrão fixo do WireGuard, para uso em redes com inspeção rigorosa; não são compatíveis com os clientes WireGuard padrão.

• Funcionar ou não depende antes de tudo do UDP: muitas redes fixas e móveis limitam o UDP em grande volume, e o resultado é uma conexão rápida no começo que fica lenta depois de um tempo, ou que trava visivelmente no horário de pico.
• Conexões diretas para fora do país são fáceis de identificar: o handshake do WireGuard tem um padrão fixo e, nos links internacionais, pode ser reconhecido e sofrer interferência — o handshake não completa, ou o tráfego para depois de um tempo de uso. É a consequência direta de o protocolo não ter disfarce.
• Redes entre aparelhos dentro da China (escritório e casa, celular e NAS) não passam pelo link internacional e normalmente não têm esse problema; só são afetadas pela limitação de UDP e pela taxa de sucesso da travessia de NAT.
• Por isso ele serve melhor para redes entre aparelhos e acesso remoto; para atravessar a fronteira de forma estável e duradoura, é preciso combiná-lo com uma forma que tenha disfarce ou use TCP / TLS — a comparação entre protocolos está no comparativo de protocolos de VPN.

A seção da Rede privada do LeoTun usa Tailscale, e o plano de dados é o WireGuard: os túneis entre os seus aparelhos e até os servidores de saída de cada região são criptografados e transportados por ele. Você não precisa gerar chaves nem escrever configuração: depois de entrar com a conta do site, o cliente faz tudo sozinho. Como usar está em O que é a Rede privada (Tailscale), e o acesso fica na página da Rede privada.

Além da Rede privada, a mesma conta tem formas que não dependem de UDP: o Cisco (AnyConnect) vai sobre TLS, o OpenVPN pode usar TCP, e o Hiddify (Hysteria2) foi feito para lidar com perda de pacotes. Se na rede onde você está a Rede privada ficar lenta e instável, é só trocar de forma — veja Quando usar cada forma de conexão.