Como Configurar o WireGuard no Ubuntu

Introdução

WireGuard é uma Rede Privada Virtual (VPN) leve que suporta conexões IPv4 e IPv6. Uma VPN permite que você navegue por redes não confiáveis como se estivesse em uma rede privada. Ela oferece a capacidade de acessar a internet de forma mais segura a partir de dispositivos como laptops ou telefones celulares ao se conectar a redes não confiáveis, incluindo Wi-Fi público.

A criptografia do WireGuard depende de chaves públicas e privadas para que os pares possam estabelecer túneis criptografados entre si. Cada versão do WireGuard usa um conjunto fixo de métodos criptográficos modernos, o que ajuda a manter o protocolo simples e previsível. Esse design evita negociações em tempo de execução e reduz o risco de erros de configuração.

Em comparação, outros softwares de VPN, como OpenVPN e IPsec, dependem do Transport Layer Security e de certificados para autenticar e estabelecer túneis criptografados. Embora essa abordagem ofereça flexibilidade e suporte a uma ampla variedade de clientes, ela também aumenta a complexidade da configuração e torna o comportamento operacional mais difícil de entender.

Neste tutorial, você configurará o WireGuard em um servidor Ubuntu e configurará outra máquina para se conectar a ele como um peer usando IPv4 e IPv6, comumente chamado de configuração dual-stack. Você também aprenderá como rotear o tráfego do peer através do servidor WireGuard em uma configuração de gateway, além de como usar a VPN para comunicação ponto a ponto criptografada.

Além da configuração básica, este guia aborda tópicos práticos que são importantes para implantações no mundo real. Isso inclui entender a arquitetura ponto a ponto do WireGuard, gerenciar e rotacionar chaves, lidar corretamente com IPv6 e roteamento em pilha dupla, melhorar a confiabilidade para peers atrás de NAT, ajustar o desempenho e entender como o WireGuard se compara ao OpenVPN em termos de protocolos de transporte e comportamento de firewall.

Para os fins deste tutorial, outro sistema Ubuntu é usado como o Peer do WireGuard. Tutoriais posteriores desta série abordam a instalação e o uso do WireGuard no Windows, macOS, Android e iOS.

Pré-requisitos

Para seguir este tutorial, você precisará de:

• Um servidor Ubuntu com um usuário não-root com privilégios sudo e um firewall habilitado. Para configurar isso, você pode seguir nosso tutorial Configuração Inicial do Servidor com Ubuntu. Nos referiremos a ele como o Servidor WireGuard ao longo deste guia.

• Você precisará de uma máquina cliente que você usará para se conectar ao seu Servidor WireGuard. Neste tutorial, nos referiremos a essa máquina como o Peer WireGuard. Para os fins deste tutorial, é recomendado que você use sua máquina local como o Peer WireGuard, mas você pode usar servidores remotos ou celulares como clientes, se preferir. Se você estiver usando um sistema remoto, certifique-se de seguir todas as seções opcionais mais adiante neste tutorial, caso contrário, você pode se trancar fora do sistema.

• Para usar o WireGuard com IPv6, você também precisará garantir que seu servidor esteja configurado para suportar esse tipo de tráfego. Se você deseja habilitar o suporte a IPv6 com o WireGuard e estiver usando um Droplet da Linux-Console.net, consulte esta página de documentação Como Habilitar IPv6 em Droplets. Você pode adicionar suporte a IPv6 ao criar um Droplet ou posteriormente seguindo as instruções dessa página.

Visão Geral da Arquitetura do WireGuard

Antes de configurar o WireGuard, é útil entender como sistemas, pares e o tráfego de rede interagem. O WireGuard utiliza uma arquitetura deliberadamente simples que evita planos de controle, autoridades certificadoras e a negociação de parâmetros de configuração em tempo de execução. Toda a criptografia, autenticação e comportamento de roteamento são definidos explicitamente por meio de arquivos de configuração.

Terminologia de Design e Topologia Peer-to-Peer

O WireGuard é, fundamentalmente, um protocolo ponto a ponto. O mesmo software e módulo de kernel do WireGuard são executados em todos os sistemas participantes, e não há um binário distinto de servidor ou cliente.

Neste tutorial, o termo Servidor WireGuard se refere a um hub central em uma topologia hub-and-spoke. Este sistema é publicamente acessível e atua como ponto de coordenação para outros peers. O termo Peer WireGuard se refere aos dispositivos que se conectam a este hub. Esses termos descrevem a topologia de rede usada neste guia, e não diferentes funções ou capacidades de software.

Compreender essa distinção é importante porque o WireGuard não possui opções de configuração apenas para servidor. Qualquer sistema pode atuar como um hub, um ponto final ou ambos, dependendo inteiramente de como chaves, endereços e regras de roteamento são definidos.

Componentes Principais em uma Implementação do WireGuard

Uma implantação do WireGuard consiste em um pequeno número de componentes claramente definidos, cada um com uma responsabilidade específica.

• Peer Central (Hub): O peer central é um sistema acessível publicamente que escuta tráfego UDP criptografado em uma única porta. Ele hospeda uma interface de túnel virtual, comumente chamada wg0, e armazena as chaves públicas de outros peers autorizados a se comunicar com ele. O hub não descobre peers de forma dinâmica nem aceita conexões implicitamente. O tráfego é aceito apenas de peers cujas chaves públicas e faixas de IP permitidas estejam explicitamente configuradas.

• Conectando Peers (Spokes): Peers conectados são dispositivos que estabelecem túneis criptografados com o peer central. Esses dispositivos podem ser laptops, servidores, máquinas virtuais ou sistemas móveis. Cada peer possui um par de chaves criptográficas único e um ou mais endereços IP privados atribuídos à sua interface de túnel. Um peer envia tráfego para o túnel apenas quando suas regras de roteamento instruem que isso seja feito.

• Interface de Túnel (wg0): A interface de túnel é um dispositivo de rede virtual criado em cada sistema participante. Todo o tráfego criptografado entra e sai através desta interface. Do ponto de vista do sistema operacional, wg0 se comporta como uma interface de rede padrão, o que permite que tabelas de roteamento, regras de firewall e comportamento de encaminhamento normais sejam aplicados.

Criptografia, Autenticação e Handshakes

O WireGuard usa criptografia de chave pública para autenticar os pares e criptografar o tráfego. Cada par gera uma chave privada de longo prazo que permanece no sistema local e nunca é transmitida. A chave pública correspondente é compartilhada com outros pares e adicionada às suas configurações.

Quando a comunicação começa, o WireGuard realiza uma troca de chave criptográfica silenciosa e automática baseada na estrutura do protocolo Noise. Essa troca estabelece chaves de sessão efêmeras e fornece Sigilo Perfeito Adiante. Essas chaves de sessão são rotacionadas periodicamente sem intervenção do usuário.

O WireGuard não negocia suítes de cifra, métodos de autenticação ou versões de protocolo. Todos os primitivos criptográficos são fixos por design. Isso elimina uma classe inteira de erros de configuração, ao mesmo tempo em que fornece garantias de segurança modernas.

Padrões de Fluxo de Tráfego Suportados

O WireGuard suporta múltiplos padrões de tráfego dependendo de como o roteamento e o encaminhamento são configurados. Este tutorial foca nos dois casos de uso mais comuns.

Acesso Peer-to-Peer ou à Rede Interna

Em uma configuração ponto a ponto ou de acesso interno, o tráfego é criptografado apenas entre os sistemas que fazem parte da VPN. O ponto central atua como um endpoint seguro ou relay, mas não encaminha tráfego para redes externas.

Essa configuração é normalmente usada para acessar serviços privados, administrar a infraestrutura ou conectar sistemas isolados. O tráfego é direcionado pelo túnel apenas quando o endereço de destino corresponde aos intervalos de IP privados definidos na configuração do par.

Modo Gateway VPN

No modo gateway, o peer central encaminha o tráfego de outros peers para redes externas, incluindo a Internet pública. Os peers enviam parte ou todo o seu tráfego para o túnel, e o peer central encaminha esse tráfego usando encaminhamento de IP e tradução de endereços de rede.

Esta configuração requer configurações adicionais do sistema, incluindo encaminhamento do kernel e regras de firewall. Quando o modo gateway está ativado, o tráfego de saída dos pares parece se originar do endereço IP público do par central.

O Papel Duplo de AllowedIPs

A diretiva AllowedIPs possui dois propósitos distintos no WireGuard.

Primeiro, ele define o comportamento de roteamento de saída. Quando o endereço de destino de um pacote corresponde a uma entrada em AllowedIPs, esse pacote é roteado pelo túnel WireGuard.

Em segundo lugar, AllowedIPs funciona como uma lista de controle de acesso de entrada rigorosa. Quando um pacote é recebido de um par, o WireGuard verifica o endereço IP de origem do pacote. Se o endereço de origem não estiver listado em AllowedIPs desse par, o pacote é descartado imediatamente.

Essa função dupla é intencional e é uma das fontes mais comuns de erros de configuração. Apenas o roteamento correto não é suficiente. Os endereços IP de origem que um par tem permissão para usar também devem ser explicitamente autorizados.

Automação de Roteamento e Ferramentas de Ajuda

O próprio módulo de kernel do WireGuard não modifica rotas do sistema, configurações de DNS ou regras de firewall. Ele apenas criptografa e descriptografa pacotes e os associa aos pares.

A automação de roteamento é gerenciada por ferramentas auxiliares, como wg-quick. Esta utilidade lê o arquivo de configuração do WireGuard e aplica as entradas necessárias na tabela de roteamento, configurações de DNS e regras de firewall quando um túnel é ativado ou desativado.

Se o WireGuard for configurado usando ferramentas alternativas, como comandos brutos wg, systemd-networkd ou scripts personalizados, essas alterações de roteamento devem ser gerenciadas manualmente.

Essa separação mantém o protocolo principal simples, enquanto permite uma integração flexível com diferentes pilhas de rede do sistema.

Passo 1 — Instalando o WireGuard e Gerando um Par de Chaves

O primeiro passo deste tutorial é instalar o WireGuard em seu servidor. Para começar, atualize o índice de pacotes do seu servidor WireGuard e instale o WireGuard usando os seguintes comandos. Você pode ser solicitado a fornecer a senha do seu usuário sudo se esta for a primeira vez que estiver usando sudo nesta sessão:

sudo apt update

sudo apt install wireguard

Agora que você instalou o WireGuard, o próximo passo é gerar um par de chaves privada e pública para o servidor. Você usará os comandos incorporados wg genkey e wg pubkey para criar as chaves e, em seguida, adicionará a chave privada ao arquivo de configuração do WireGuard.

Você também precisará alterar as permissões da chave que acabou de criar usando o comando chmod, já que, por padrão, o arquivo pode ser lido por qualquer usuário do seu servidor.

Crie a chave privada para o WireGuard e altere suas permissões usando os seguintes comandos:

wg genkey | sudo tee /etc/wireguard/private.key

sudo chmod go= /etc/wireguard/private.key

O comando sudo chmod go=... remove quaisquer permissões do arquivo para usuários e grupos que não sejam o usuário root, garantindo que apenas ele possa acessar a chave privada.

Você deve receber uma única linha de saída codificada em base64, que é a chave privada. Uma cópia da saída também é armazenada no arquivo /etc/wireguard/private.key para referência futura pela parte tee do comando. Anote cuidadosamente a chave privada que é gerada, pois você precisará adicioná-la ao arquivo de configuração do WireGuard mais adiante nesta seção.

O próximo passo é criar a chave pública correspondente, que é derivada da chave privada. Use o seguinte comando para criar o arquivo da chave pública:

sudo cat /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.key

Este comando consiste em três comandos individuais que são encadeados usando o operador | (pipe):

• sudo cat /etc/wireguard/private.key: este comando lê o arquivo da chave privada e o exibe no fluxo de saída padrão.
• wg pubkey: o segundo comando pega a saída do primeiro comando como sua entrada padrão e a processa para gerar uma chave pública.
• sudo tee /etc/wireguard/public.key: o comando final pega a saída do comando de geração da chave pública e a redireciona para o arquivo chamado /etc/wireguard/public.key.

Quando você executar o comando, receberá novamente uma única linha de saída codificada em base64, que é a chave pública do seu servidor WireGuard. Copie-a para algum lugar como referência, pois você precisará distribuí-la para qualquer peer que se conectar ao servidor.

Etapa 2 — Escolhendo Endereços IPv4 e IPv6

Na seção anterior, você instalou o WireGuard e gerou um par de chaves que será usado para criptografar o tráfego de e para o servidor. Nesta seção, você criará um arquivo de configuração para o servidor e configurará o WireGuard para iniciar automaticamente quando o servidor for reiniciado. Você também definirá endereços IPv4 e IPv6 privados para usar com seu servidor e peers do WireGuard.

Se você planeja usar endereços IPv4 e IPv6, siga ambas as seções. Caso contrário, siga as instruções na seção apropriada de acordo com as necessidades de rede do seu VPN.

Etapa 2(a) — Escolhendo um intervalo IPv4

Se você está usando seu servidor WireGuard com peers IPv4, o servidor precisa de um intervalo de endereços IPv4 privados para usar com os clientes e para sua interface de túnel. Você pode escolher qualquer intervalo de endereços IP a partir dos seguintes blocos de endereços reservados (se você quiser saber mais sobre como esses blocos são alocados, visite a especificação RFC 1918):

• 10.0.0.0 a 10.255.255.255 (prefixo 10/8)
• 172.16.0.0 a 172.31.255.255 (prefixo 172.16/12)
• 192.168.0.0 a 192.168.255.255 (prefixo 192.168/16)

Para os fins deste tutorial, usaremos 10.8.0.0/24 como um bloco de endereços IP a partir do primeiro intervalo de IPs reservados. Esse intervalo permitirá até 255 conexões de pares diferentes e, geralmente, não deve ter endereços sobrepostos ou conflitantes com outros intervalos de IP privados. Sinta-se à vontade para escolher um intervalo de endereços que funcione com a configuração da sua rede, caso este intervalo de exemplo não seja compatível com suas redes.

O servidor WireGuard usará um único endereço IP da faixa para seu endereço IPv4 de túnel privado. Usaremos 10.8.0.1/24 aqui, mas qualquer endereço na faixa de 10.8.0.1 a 10.8.0.255 pode ser usado. Anote o endereço IP que você escolher caso use algo diferente de 10.8.0.1/24. Você adicionará este endereço IPv4 ao arquivo de configuração que definir em Criando uma Configuração de Servidor WireGuard.

Etapa 2(b) — Escolhendo um Intervalo IPv6

Se você estiver usando o WireGuard com IPv6, precisará gerar um prefixo de endereço unicast IPv6 local único com base no algoritmo do RFC 4193. Os endereços que você usar com o WireGuard serão associados a uma interface de túnel virtual. Será necessário concluir algumas etapas para gerar um prefixo IPv6 aleatório e único dentro do bloco reservado fd00::/8 de endereços IPv6 privados.

De acordo com a RFC, a maneira recomendada de obter um prefixo IPv6 exclusivo é combinar a hora do dia com um valor de identificação único de um sistema, como um número de série ou ID do dispositivo. Esses valores são então processados por uma função de hash e truncados, resultando em um conjunto de bits que podem ser usados como um endereço único dentro do bloco reservado privado fd00::/8 de IPs.

Para começar a gerar um intervalo IPv6 para o seu Servidor WireGuard, obtenha um timestamp de 64 bits usando a ferramenta date com o seguinte comando:

date +%s%N

Você receberá um número como o seguinte, que é o número de segundos (o %s no comando date) e nanossegundos (o %N) desde 1970-01-01 00:00:00 UTC combinados:

1628101352127592197

Registre o valor em algum lugar para usá-lo mais tarde nesta seção. Em seguida, copie o valor machine-id do seu servidor a partir do arquivo /var/lib/dbus/machine-id. Esse identificador é único para o seu sistema e não deve mudar enquanto o servidor existir.

cat /var/lib/dbus/machine-id

Você receberá uma saída como a seguinte:

/var/lib/dbus/machine-id
20086c25853947c7aeee2ca1ea849d7d

Agora você precisa combinar o carimbo de data/hora com o machine-id e gerar um hash do valor resultante usando o algoritmo SHA-1. O comando usará o seguinte formato:

printf <timestamp><machine-id> | sha1sum

Execute o comando substituindo pelos valores do seu carimbo de data/hora e identidade da máquina:

printf 162810135212759219720086c25853947c7aeee2ca1ea849d7d | sha1sum

Você receberá um valor de hash como o seguinte:

4f267c51857d6dc93a0bca107bca2f0d86fac3bc  -

Observe que a saída do comando sha1sum está em hexadecimal, então a saída usa dois caracteres para representar um único byte de dados. Por exemplo, 4f e 26 na saída de exemplo são os dois primeiros bytes dos dados hashados.

O algoritmo no RFC requer apenas os 40 bits menos significativos (trailing), ou 5 bytes, do resultado do hash. Use o comando cut para imprimir os últimos 5 bytes codificados em hexadecimal do hash:

printf 4f267c51857d6dc93a0bca107bca2f0d86fac3bc | cut -c 31-

O argumento -c indica ao comando cut para selecionar apenas um conjunto específico de caracteres. O argumento 31- indica ao cut para imprimir todos os caracteres da posição 31 até o final da linha de entrada.

Você deve receber uma saída como a seguinte:

0d86fac3bc

Neste exemplo de saída, o conjunto de bytes é: 0d 86 fa c3 bc.

Agora você pode construir seu prefixo de rede IPv6 único anexando os 5 bytes que você gerou com o prefixo fd, separando a cada 2 bytes com um cólon : para facilitar a leitura. Como cada sub-rede em seu prefixo único pode conter um total de 18.446.744.073.709.551.616 endereços IPv6 possíveis, você pode limitar a sub-rede a um tamanho padrão de /64 para simplificação.

Usando os bytes gerados anteriormente com o tamanho de sub-rede /64, o prefixo resultante será o seguinte:

Unique Local IPv6 Address Prefix
fd0d:86fa:c3bc::/64

Este intervalo fd0d:86fa:c3bc::/64 é o que você usará para atribuir endereços IP individuais às suas interfaces de túnel WireGuard no servidor e nos peers. Para alocar um IP para o servidor, adicione um 1 após os caracteres finais ::. O endereço resultante será fd0d:86fa:c3bc::1/64. Os peers podem usar qualquer IP dentro do intervalo, mas normalmente você incrementa o valor em um a cada vez que adiciona um peer, por exemplo, fd0d:86fa:c3bc::2/64. Faça uma anotação do IP e prossiga configurando o Servidor WireGuard na próxima seção deste tutorial.

Considerações sobre Configuração de IPv6 e Dual-Stack

Os passos existentes neste tutorial explicam como gerar endereços IPv6 e atribuí-los às interfaces WireGuard. No entanto, o comportamento do IPv6 no WireGuard difere de várias maneiras importantes do IPv4, especialmente quando o WireGuard é usado como um gateway VPN. Compreender essas diferenças ajuda a evitar falhas de roteamento, túneis parciais e vazamentos comuns de IPv6.

Suporte a IPv6 no WireGuard

O WireGuard suporta IPv6 como um protocolo de primeira classe. O tráfego IPv6 é criptografado, autenticado e roteado usando os mesmos mecanismos do tráfego IPv4. Não existe um modo IPv6 separado ou uma configuração adicional. Se endereços IPv6 forem atribuídos à interface do túnel e as regras de roteamento permitirem, o tráfego IPv6 flui pelo túnel automaticamente.

Ao contrário do IPv4, o IPv6 é projetado para evitar NAT usando endereços roteáveis globalmente, mas na prática muitos ambientes de VPN e nuvem ainda usam NAT por simplicidade operacional. No entanto, esse comportamento depende do ambiente de rede. Em muitas configurações de gateway VPN, como instâncias de VPS na nuvem ou roteadores domésticos, o servidor não recebe um prefixo IPv6 delegado que possa ser roteado para os pares VPN.

Nesses cenários comuns, os pares recebem endereços IPv6 privados, normalmente de um intervalo de Endereço Local Único (ULA). Quando endereços IPv6 privados são usados e o servidor não possui um prefixo roteável para eles, a mascaramento IPv6 ainda é necessário. Isso geralmente é implementado com regras ip6tables -t nat, semelhante ao mascaramento IPv4, para permitir que os pares da VPN acessem a Internet pública.

O IPv6 pode evitar NAT completamente quando a delegação de prefixo adequada está disponível. No entanto, a maioria das implantações simples de gateway VPN ainda depende da mascaramento IPv6 para manter o roteamento gerenciável.

Comportamento de Pilha Dupla Explicado

Uma configuração de pilha dupla permite tanto IPv4 quanto IPv6 na mesma interface WireGuard. Nesta configuração, a interface wg0 recebe um endereço IPv4 e um endereço IPv6, e cada protocolo é roteado de forma independente.

O sistema operacional avalia as rotas IPv4 e IPv6 separadamente. Um par pode rotear com sucesso o tráfego IPv4 pelo túnel enquanto o tráfego IPv6 o contorna, ou vice-versa. Esse comportamento é esperado e quase sempre indica um problema de configuração, e não um problema com o próprio WireGuard.

Para que o roteamento dual-stack funcione corretamente, várias condições devem ser atendidas. Tanto o servidor quanto o par devem ter endereços IPv4 e IPv6 atribuídos às suas interfaces WireGuard. A diretiva AllowedIPs deve incluir faixas de IPv4 e IPv6. O encaminhamento de IP deve ser habilitado separadamente para IPv4 e IPv6. As regras de firewall devem permitir o encaminhamento e o tráfego de retorno para ambos os protocolos.

Atribuição de Endereço e Comprimentos de Prefixo

Para IPv4, as implantações do WireGuard geralmente usam faixas de endereços privados, como 10.0.0.0/8 ou 192.168.0.0/16. Cada par normalmente recebe um único endereço IPv4.

Para o IPv6, é comum definir a rede VPN como um prefixo /64, como fd00::/64. Enquanto as redes Ethernet exigem um /64 para descoberta de vizinhos e autoconfiguração de endereços, o WireGuard opera como uma interface ponto a ponto de Camada 3 e não utiliza esses mecanismos.

Por causa disso, é seguro e frequentemente recomendado atribuir a cada peer um endereço IPv6 /128, como fd00::2/128. Usar endereços /128 garante um comportamento de roteamento estrito e impede que os peers tentem se comunicar diretamente com outros endereços na sub-rede sem as regras de roteamento adequadas.

Definir a rede como um /64 enquanto atribui endereços /128 aos pares proporciona clareza e evita roteamento ambíguo.

Roteando Todo o Tráfego com IPv6

Quando o WireGuard é configurado como um gateway VPN, o tráfego IPv6 deve ser roteado explicitamente da mesma forma que o tráfego IPv4.

Para IPv4, rotear todo o tráfego utiliza o prefixo 0.0.0.0/0. Para IPv6, o prefixo equivalente é ::/0. Ambos os prefixos devem ser incluídos se o objetivo for rotear todo o tráfego através da VPN.

Se apenas 0.0.0.0/0 estiver configurado, o tráfego IPv4 é enviado através da VPN enquanto o tráfego IPv6 continua a usar a interface de rede local. Essa situação é conhecida como um vazamento de IPv6. Isso geralmente resulta em consultas DNS, tráfego web ou conexões de aplicativos passando pela VPN via IPv6 enquanto o tráfego IPv4 permanece protegido.

Vazamentos de IPv6 são uma fonte frequente de confusão e devem sempre ser testados quando a rede dual-stack está ativada.

Firewall, Encaminhamento e ICMPv6

O encaminhamento IPv6 deve ser ativado independentemente do encaminhamento IPv4. Ativar um não habilita automaticamente o outro. Ambas as configurações são necessárias ao rotear o tráfego entre interfaces.

As regras de firewall também devem ser definidas explicitamente para IPv6. Ferramentas como ufw, iptables e nftables tratam IPv4 e IPv6 como conjuntos de regras separados. A ausência de regras para IPv6 pode bloquear o tráfego silenciosamente, mesmo quando a conectividade IPv4 parece funcionar.

É especialmente importante permitir o tráfego ICMPv6. Diferente do IPv4, o IPv6 depende do ICMPv6 para funções essenciais, como a Descoberta do MTU do Caminho. Se o ICMPv6 for bloqueado, as conexões podem ficar travadas ou falhar quando pacotes maiores forem transmitidos, mesmo que pacotes pequenos pareçam funcionar.

Erros Comuns em Pilhas Duplas

Vários problemas ocorrem comumente em implementações WireGuard com dupla pilha. As rotas IPv6 podem estar ausentes na diretiva AllowedIPs, fazendo com que o tráfego IPv6 contorne o túnel. O encaminhamento de IPv6 pode não estar habilitado no servidor, impedindo que o tráfego saia da interface do túnel. Regras de firewall podem permitir tráfego IPv4, mas bloquear tráfego IPv6 ou ICMPv6. Resolvedores DNS podem retornar endereços IPv6 mesmo que o roteamento IPv6 não esteja configurado corretamente.

Esses problemas frequentemente aparecem como falhas intermitentes e são frequentemente diagnosticados incorretamente como problemas de aplicativo ou protocolo.

Escolhendo Entre IPv4-Only, IPv6-Only e Dual-Stack

Em alguns ambientes, usar um único protocolo simplifica as operações.

Implantações apenas com IPv4 são mais fáceis de integrar com sistemas legados e ferramentas existentes. Implantações apenas com IPv6 eliminam a necessidade de NAT em IPv4 e evitam o esgotamento de endereços, mas exigem suporte consistente a IPv6 por parte dos provedores e das redes clientes.

Implantações de pilha dupla oferecem a maior flexibilidade, mas também exigem o planejamento, a configuração e a validação mais cuidadosos.

Passo 3 — Criando uma Configuração de Servidor WireGuard

Antes de criar a configuração do seu Servidor WireGuard, você precisará das seguintes informações:

• Certifique-se de que você tenha a chave privada disponível em Instalando o WireGuard e Gerando um Par de Chaves.
• Se você estiver usando WireGuard com IPv4, precisará do endereço IP que escolheu para o servidor em Escolhendo um Intervalo IPv4, que neste exemplo é 10.8.0.1/24.
• Se você estiver usando WireGuard com IPv6, precisará do endereço IP do servidor que você gerou em Escolhendo um intervalo IPv6. Neste exemplo, o IP é fd0d:86fa:c3bc::1/64.

Depois de ter a chave privada e o(s) endereço(s) IP necessários, crie um novo arquivo de configuração usando nano ou seu editor preferido executando o seguinte comando:

sudo nano /etc/wireguard/wg0.conf

Adicione as seguintes linhas ao arquivo, substituindo sua chave privada no lugar do valor destacado base64_encoded_private_key_goes_here, e o(s) endereço(s) IP na linha Address. Você também pode alterar a linha ListenPort se quiser que o WireGuard esteja disponível em uma porta diferente:

/etc/wireguard/wg0.conf
[Interface]
PrivateKey = base64_encoded_private_key_goes_here
Address = 10.8.0.1/24, fd0d:86fa:c3bc::1/64
ListenPort = 51820
SaveConfig = true

A linha SaveConfig garante que, quando uma interface WireGuard for desligada, quaisquer alterações serão salvas no arquivo de configuração.

Salve e feche o arquivo /etc/wireguard/wg0.conf. Se você estiver usando o nano, pode fazer isso com CTRL+X, depois Y e ENTER para confirmar. Agora você tem uma configuração inicial do servidor que pode ser expandida dependendo de como planeja usar seu servidor VPN WireGuard.

Passo 4 — Ajustando a Configuração de Rede do Servidor WireGuard

Se você estiver usando o WireGuard para conectar um peer ao Servidor WireGuard com o objetivo de acessar serviços **apenas no servidor**, então você não precisa completar esta seção. Se você quiser rotear o tráfego da Internet do seu Peer WireGuard através do Servidor WireGuard, será necessário configurar o encaminhamento de IP seguindo esta seção do tutorial.

Para configurar o encaminhamento, abra o arquivo /etc/sysctl.conf usando o nano ou seu editor preferido:

sudo nano /etc/sysctl.conf

Se você estiver usando IPv4 com WireGuard, adicione a seguinte linha no final do arquivo:

net.ipv4.ip_forward=1

Se você estiver usando IPv6 com o WireGuard, adicione esta linha ao final do arquivo:

net.ipv6.conf.all.forwarding=1

Se você estiver usando tanto IPv4 quanto IPv6, certifique-se de incluir ambas as linhas. Salve e feche o arquivo quando terminar.

Para ler o arquivo e carregar os novos valores para sua sessão atual do terminal, execute:

sudo sysctl -p

net.ipv6.conf.all.forwarding = 1
net.ipv4.ip_forward = 1

Agora o seu servidor WireGuard poderá encaminhar o tráfego de entrada do dispositivo Ethernet virtual da VPN para outros no servidor, e a partir daí para a Internet pública. Usar essa configuração permitirá que você roteie todo o tráfego da web do seu Peer do WireGuard através do endereço IP do seu servidor, e o endereço IP público do seu cliente ficará efetivamente escondido.

No entanto, antes que o tráfego possa ser roteado corretamente através do seu servidor, você precisará configurar algumas regras de firewall. Essas regras garantirão que o tráfego de e para o seu Servidor e Peers do WireGuard flua corretamente.

Passo 5 — Configurando o Firewall do Servidor WireGuard

Nesta seção, você editará a configuração do servidor WireGuard para adicionar regras de firewall que garantirão que o tráfego de e para o servidor e os clientes seja roteado corretamente. Como na seção anterior, pule esta etapa se você estiver usando seu VPN WireGuard apenas para uma conexão máquina a máquina para acessar recursos que são restritos à sua VPN.

Para permitir o tráfego da VPN WireGuard através do firewall do servidor, você precisará ativar o mascaramento, que é um conceito do iptables que fornece tradução dinâmica de endereços de rede (NAT) em tempo real para rotear corretamente as conexões dos clientes.

Primeiro, encontre a interface de rede pública do seu servidor WireGuard usando o subcomando ip route:

ip route list default

A interface pública é a string encontrada na saída deste comando que segue a palavra “dev”. Por exemplo, este resultado mostra a interface chamada eth0, que está destacada abaixo:

default via 203.0.113.1 dev eth0 proto static

Anote o nome do seu dispositivo, pois você irá adicioná-lo às regras do iptables na próxima etapa.

Para adicionar regras de firewall ao seu Servidor WireGuard, abra o arquivo /etc/wireguard/wg0.conf com o nano ou seu editor preferido novamente.

sudo nano /etc/wireguard/wg0.conf

Na parte inferior do arquivo, após a linha SaveConfig=true, cole as seguintes linhas:

/etc/wireguard/wg0.conf
. . .
PostUp = ufw route allow in on wg0 out on eth0
PostUp = iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PostUp = ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PreDown = ufw route delete allow in on wg0 out on eth0
PreDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PreDown = ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

As linhas PostUp serão executadas quando o servidor WireGuard iniciar o túnel VPN virtual. No exemplo aqui, ele adicionará três regras ufw e iptables:

• ufw route allow in on wg0 out on eth0: Esta regra permitirá o encaminhamento de tráfego IPv4 e IPv6 que entra pela interface VPN wg0 para a interface de rede eth0 no servidor. Ela funciona em conjunto com os valores net.ipv4.ip_forward e net.ipv6.conf.all.forwarding do sysctl que você configurou na seção anterior.
• iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE: Esta regra configura mascaramento e reescreve o tráfego IPv4 que chega pela interface VPN wg0 para que pareça originar diretamente do endereço IPv4 público do servidor WireGuard.
• ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE: Esta regra configura mascaramento e reescreve o tráfego IPv6 que chega pela interface VPN wg0 para que pareça originar-se diretamente do endereço IPv6 público do servidor WireGuard.

As regras PreDown são executadas quando o servidor WireGuard interrompe o túnel VPN virtual. Essas regras são o inverso das regras PostUp e funcionam para desfazer as regras de encaminhamento e mascaramento da interface VPN quando a VPN é parada.

Em ambos os casos, edite a configuração para incluir ou excluir as regras de IPv4 e IPv6 que sejam apropriadas para o seu VPN. Por exemplo, se você estiver usando apenas IPv4, pode excluir as linhas com os comandos ip6tables.

Por outro lado, se você estiver usando apenas IPv6, edite a configuração para incluir apenas os comandos ip6tables. As linhas ufw devem existir para qualquer combinação de redes IPv4 e IPv6. Salve e feche o arquivo quando terminar.

A última parte da configuração do firewall no seu servidor WireGuard é permitir o tráfego de entrada e saída para a porta UDP do WireGuard. Se você não alterou a porta no arquivo /etc/wireguard/wg0.conf do servidor, a porta que você deverá abrir é 51820. Se você escolheu uma porta diferente ao editar a configuração, certifique-se de substituí-la no comando UFW a seguir.

Caso você tenha esquecido de abrir a porta SSH ao seguir o tutorial de pré-requisitos, adicione-a aqui também:

sudo ufw allow 51820/udp

sudo ufw allow OpenSSH

Depois de adicionar essas regras, desative e reative o UFW para reiniciá-lo e carregar as alterações de todos os arquivos que você modificou:

sudo ufw disable

sudo ufw enable

Você pode confirmar se as regras estão em vigor executando o comando ufw status. Execute-o, e você deve receber uma saída como a seguinte:

sudo ufw status

Status: active

To                         Action      From
--                         ------      ----
51820/udp                  ALLOW       Anywhere                  
22/tcp                     ALLOW       Anywhere                  
51820/udp (v6)             ALLOW       Anywhere (v6)             
22/tcp (v6)                ALLOW       Anywhere (v6)

Seu servidor WireGuard agora está configurado para lidar corretamente com o tráfego da VPN, incluindo encaminhamento e mascaramento para os pares. Com as regras de firewall em vigor, você pode iniciar o próprio serviço WireGuard para ouvir as conexões dos pares.

Passo 6 — Iniciando o Servidor WireGuard

O WireGuard pode ser configurado para rodar como um serviço systemd usando seu script interno wg-quick. Embora você possa usar manualmente o comando wg para criar o túnel toda vez que quiser usar a VPN, isso é um processo manual que se torna repetitivo e propenso a erros. Em vez disso, você pode usar o systemctl para gerenciar o túnel com a ajuda do script wg-quick.

Usar um serviço systemd significa que você pode configurar o WireGuard para iniciar na inicialização, permitindo que você se conecte à sua VPN a qualquer momento, desde que o servidor esteja em execução. Para fazer isso, habilite o serviço wg-quick para o túnel wg0 que você definiu, adicionando-o ao systemctl:

sudo systemctl enable wg-quick@wg0.service

Agora inicie o serviço:

sudo systemctl start wg-quick@wg0.service

Verifique novamente se o serviço WireGuard está ativo com o seguinte comando. Você deve ver o serviço listado como ativo. Note que wg-quick sai após configurar a interface, então ativo (saído) é normal.

sudo systemctl status wg-quick@wg0.service

● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
     Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor preset: enabled)
     Active: active (exited) since Wed 2021-08-25 15:24:14 UTC; 5s ago
       Docs: man:wg-quick(8)
             man:wg(8)
             https://www.wireguard.com/
             https://www.wireguard.com/quickstart/
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8
             https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
    Process: 3245 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS)
   Main PID: 3245 (code=exited, status=0/SUCCESS)

Aug 25 15:24:14 wg0 wg-quick[3245]: [#] wg setconf wg0 /dev/fd/63
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip -4 address add 10.8.0.1/24 dev wg0
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip -6 address add fd0d:86fa:c3bc::1/64 dev wg0
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip link set mtu 1420 up dev wg0
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ufw route allow in on wg0 out on eth0
Aug 25 15:24:14 wg0 wg-quick[3279]: Rule added
Aug 25 15:24:14 wg0 wg-quick[3279]: Rule added (v6)
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
Aug 25 15:24:14 wg0 wg-quick[3245]: [#] ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
Aug 25 15:24:14 wg0 systemd[1]: Finished WireGuard via wg-quick(8) for wg0.

A saída mostra os comandos ip que são usados para criar o dispositivo virtual wg0 e atribuir a ele os endereços IPv4 e IPv6 que você adicionou ao arquivo de configuração. Você pode usar essas regras para solucionar problemas no túnel ou com o próprio comando wg, se quiser tentar configurar manualmente a interface VPN.

Com o servidor configurado e em funcionamento, o próximo passo é configurar sua máquina cliente como um Peer do WireGuard e se conectar ao Servidor WireGuard.

Passo 7 — Configurando um Peer do WireGuard

Configurar um Peer do WireGuard é semelhante a configurar o Servidor WireGuard. Depois de instalar o software do cliente, você vai gerar um par de chaves pública e privada, decidir sobre um endereço IP ou endereços para o peer, definir um arquivo de configuração para o peer e então iniciar o túnel usando o script wg-quick.

Você pode adicionar quantos pares de usuários quiser à sua VPN gerando um par de chaves e configuração usando os seguintes passos. Se você adicionar múltiplos pares de usuários à VPN, certifique-se de acompanhar seus endereços IP privados para evitar colisões.

Para configurar o Peer do WireGuard, certifique-se de que você tenha o pacote WireGuard instalado usando os seguintes comandos apt. No Peer do WireGuard, execute:

sudo apt update

sudo apt install wireguard

Criando o Par de Chaves do Peer do WireGuard

Em seguida, você precisará gerar o par de chaves no peer usando os mesmos passos que usou no servidor. A partir da sua máquina local ou servidor remoto que servirá como peer, prossiga e crie a chave privada para o peer usando os seguintes comandos:

wg genkey | sudo tee /etc/wireguard/private.key

sudo chmod go= /etc/wireguard/private.key

Novamente, você receberá uma única linha de saída codificada em base64, que é a chave privada. Uma cópia da saída também é armazenada em /etc/wireguard/private.key. Anote cuidadosamente a chave privada que foi exibida, pois você precisará adicioná-la ao arquivo de configuração do WireGuard mais adiante nesta seção.

Em seguida, use o seguinte comando para criar o arquivo da chave pública:

sudo cat /etc/wireguard/private.key | wg pubkey | sudo tee /etc/wireguard/public.key

Você receberá novamente uma única linha de saída codificada em base64, que é a chave pública do seu Peer do WireGuard. Copie-a em algum lugar para referência, pois você precisará distribuir a chave pública para o servidor WireGuard a fim de estabelecer uma conexão criptografada.

Criando o Arquivo de Configuração do Peer do WireGuard

Agora que você tem um par de chaves, pode criar um arquivo de configuração para o peer que contenha todas as informações necessárias para estabelecer uma conexão com o servidor WireGuard.

Você precisará de algumas informações para o arquivo de configuração:

• A chave privada codificada em base64 que você gerou no peer.
• Os intervalos de endereços IPv4 e IPv6 que você definiu no Servidor WireGuard.
• A chave pública base64 codificada do servidor WireGuard.
• O endereço IP público e o número da porta do Servidor WireGuard. Normalmente, este será o endereço IPv4, mas se o seu servidor tiver um endereço IPv6 e sua máquina cliente tiver uma conexão IPv6 com a internet, você pode usar isso em vez do IPv4.

Com todas essas informações em mãos, abra um novo arquivo /etc/wireguard/wg0.conf na máquina Peer do WireGuard usando nano ou seu editor preferido:

sudo nano /etc/wireguard/wg0.conf

Adicione as seguintes linhas ao arquivo, substituindo os vários dados nas seções destacadas conforme necessário:

/etc/wireguard/wg0.conf
[Interface]
PrivateKey = base64_encoded_peer_private_key_goes_here
Address = 10.8.0.2/24
Address = fd0d:86fa:c3bc::2/64

[Peer]
PublicKey = U9uE2kb/nrrzsEU58GD3pKFU3TLYDMCbetIsnV8eeFE=
AllowedIPs = 10.8.0.0/24, fd0d:86fa:c3bc::/64
Endpoint = 203.0.113.1:51820

Observe como a primeira linha Address usa um endereço IPv4 do sub-rede 10.8.0.0/24 que você escolheu anteriormente. Esse endereço IP pode ser qualquer um dentro da sub-rede, contanto que seja diferente do IP do servidor. Incrementar os endereços em 1 a cada vez que você adiciona um peer geralmente é a maneira mais fácil de alocar IPs.

Da mesma forma, observe como a segunda linha Address usa um endereço IPv6 da sub-rede que você gerou anteriormente e incrementa o endereço do servidor em um. Novamente, qualquer IP dentro do intervalo é válido se você decidir usar um endereço diferente.

A outra parte notável do arquivo é a última linha AllowedIPs. Esses dois intervalos de IPv4 e IPv6 instruem o peer a enviar tráfego pela VPN apenas se o sistema de destino tiver um endereço IP em um dos intervalos. Usando a diretiva AllowedIPs, você pode restringir a VPN no peer para conectar-se apenas a outros peers e serviços na VPN, ou pode configurar o ajuste para encaminhar todo o tráfego pela VPN e usar o Servidor WireGuard como gateway.

Se você estiver usando apenas IPv4, então omita o intervalo final fd0d:86fa:c3bc::/64 (incluindo a vírgula ,). Por outro lado, se você estiver usando apenas IPv6, inclua apenas o prefixo fd0d:86fa:c3bc::/64 e deixe de fora o intervalo IPv4 10.8.0.0/24.

Em ambos os casos, se você quiser enviar todo o tráfego do seu par pela VPN e usar o Servidor WireGuard como um gateway para todo o tráfego, então você pode usar 0.0.0.0/0, que representa todo o espaço de endereços IPv4, e ::/0 para todo o espaço de endereços IPv6.

(Opcional) Configurando um Par para Roteamento de Todo o Tráfego pelo Túnel

Se você optou por rotear todo o tráfego do par através do túnel usando as rotas 0.0.0.0/0 ou ::/0 e o par for um sistema remoto, então será necessário completar os passos nesta seção. Se o seu par for um sistema local, é melhor pular esta seção.

Para pares remotos que você acessa via SSH ou algum outro protocolo usando um endereço IP público, você precisará adicionar algumas regras extras ao arquivo wg0.conf do par. Essas regras garantirão que você ainda possa se conectar ao sistema de fora do túnel quando ele estiver conectado. Caso contrário, quando o túnel for estabelecido, todo o tráfego que normalmente seria tratado na interface de rede pública não será roteado corretamente para contornar a interface de túnel wg0, tornando o sistema remoto inacessível.

Primeiro, você precisará determinar o endereço IP que o sistema usa como gateway padrão. Execute o seguinte comando ip route:

ip route list table main default

Você receberá uma saída como a seguinte:

default via 203.0.113.1 dev eth0 proto static

Anote o endereço IP destacado do gateway 203.0.113.1 para uso posterior, e o dispositivo eth0. O nome do seu dispositivo pode ser diferente. Se for o caso, substitua-o no lugar de eth0 nos comandos a seguir.

Em seguida, encontre o IP público do sistema examinando o dispositivo com o comando ip address show:

ip -brief address show eth0

Você receberá uma saída como a seguinte:

eth0             UP             203.0.113.5/20 10.20.30.40/16 2604:a880:400:d1::3d3:6001/64 fe80::68d5:beff:feff:974c/64

Neste exemplo de saída, o IP 203.0.113.5 destacado (sem o /20 no final) é o endereço público que é atribuído ao dispositivo eth0 e que você precisará adicionar à configuração do WireGuard.

Agora abra o arquivo /etc/wireguard/wg0.conf do Peer do WireGuard com o nano ou seu editor preferido.

sudo nano /etc/wireguard/wg0.conf

Antes da linha [Peer], adicione as seguintes 4 linhas:

PostUp = ip rule add table 200 from 203.0.113.5
PostUp = ip route add table 200 default via 203.0.113.1
PreDown = ip rule delete table 200 from 203.0.113.5
PreDown = ip route delete table 200 default via 203.0.113.1

[Peer]
. . .

Essas linhas criarão uma regra de roteamento personalizada e adicionarão uma rota personalizada para garantir que o tráfego público para o sistema use o gateway padrão.

• PostUp=ip rule add table 200 from 203.0.113.5 - Este comando cria uma regra que verifica qualquer entrada de roteamento na tabela de número 200 quando o IP corresponde ao endereço público do sistema 203.0.113.5.
• PostUp=ip route add table 200 default via 203.0.113.1 - Este comando garante que qualquer tráfego sendo processado pela tabela 200 use o gateway 203.0.113.1 para roteamento, em vez da interface WireGuard.

As linhas PreDown removem a regra e a rota personalizadas quando o túnel é encerrado.

Se você estiver roteando todo o tráfego do par através da VPN, certifique-se de que configurou as regras corretas de sysctl e iptables no Servidor WireGuard em Ajustando a Configuração de Rede do Servidor WireGuard e Configurando o Firewall do Servidor WireGuard.

(Opcional) Configurando os resolvedores DNS do Peer do WireGuard

Se você estiver usando o Servidor WireGuard como um gateway VPN para todo o tráfego dos seus peers, será necessário adicionar uma linha na seção [Interface] que especifique os resolvedores de DNS. Se você não adicionar essa configuração, suas solicitações de DNS podem não ser protegidas pela VPN, ou podem ser reveladas ao seu Provedor de Serviços de Internet ou a outros terceiros.

Se você estiver usando o WireGuard apenas para acessar recursos na rede VPN ou em uma configuração ponto a ponto, você pode pular esta seção.

Para adicionar resolvers DNS à configuração do seu peer, primeiro determine quais servidores DNS o seu Servidor WireGuard está usando. Execute o seguinte comando no Servidor WireGuard, substituindo o nome do seu dispositivo Ethernet no lugar de eth0 se for diferente deste exemplo:

resolvectl dns eth0

Você deve receber uma saída como a seguinte:

Link 2 (eth0): 67.207.67.2 67.207.67.3 2001:4860:4860::8844 2001:4860:4860::8888

Os endereços IP exibidos são os resolvedores DNS que o servidor está usando. Você pode escolher usar qualquer um ou todos eles, ou apenas IPv4 ou IPv6, dependendo das suas necessidades. Faça uma anotação dos resolvedores que você usará.

Em seguida, você precisará adicionar os resolvedores escolhidos ao arquivo de configuração do Peer do WireGuard. De volta ao Peer do WireGuard, abra o arquivo /etc/wireguard/wg0.conf usando o nano ou seu editor preferido:

sudo nano /etc/wireguard/wg0.conf

Antes da linha [Peer], adicione o seguinte:

DNS = 67.207.67.2 2001:4860:4860::8844

[Peer]
. . .

Novamente, dependendo da sua preferência ou dos seus requisitos para IPv4 e IPv6, você pode editar a lista de acordo com suas necessidades.

Global: 67.207.67.2 67.207.67.3
. . .

Com todas essas configurações de resolvedor DNS em vigor, você agora está pronto para adicionar a chave pública do peer ao servidor e, em seguida, iniciar o túnel WireGuard no peer.

Passo 8 — Adicionando a Chave Pública do Peer ao Servidor WireGuard

Antes de conectar o peer ao servidor, é importante adicionar a chave pública do peer ao Servidor WireGuard. Esta etapa garante que você poderá se conectar e rotear o tráfego pela VPN. Sem completar esta etapa, o servidor WireGuard não permitirá que o peer envie ou receba qualquer tráfego pelo túnel.

Certifique-se de que você possui uma cópia da chave pública codificada em base64 do Peer do WireGuard executando:

sudo cat /etc/wireguard/public.key

PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg=

Agora faça login no servidor WireGuard e execute o seguinte comando:

sudo wg set wg0 peer PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg= allowed-ips 10.8.0.2,fd0d:86fa:c3bc::2

Observe que a parte allowed-ips do comando aceita uma lista separada por vírgulas de endereços IPv4 e IPv6. Você pode especificar IPs individuais se quiser restringir o endereço IP que um par pode se atribuir, ou um intervalo como no exemplo se seus pares puderem usar qualquer endereço IP no intervalo da VPN. Também observe que nenhum par pode ter a mesma configuração de allowed-ips.

Se você quiser atualizar o allowed-ips para um peer existente, você pode executar o mesmo comando novamente, mas alterando os endereços IP. Vários endereços IP são suportados. Por exemplo, para alterar o WireGuard Peer que você acabou de adicionar para incluir um IP como 10.8.0.100 aos IPs existentes 10.8.0.2 e fd0d:86fa:c3bc::2, você deve executar o seguinte:

sudo wg set wg0 peer PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg= allowed-ips 10.8.0.2,10.8.0.100,fd0d:86fa:c3bc::2

Depois de executar o comando para adicionar o peer, verifique o status do túnel no servidor usando o comando wg:

sudo wg

interface: wg0
 public key: U9uE2kb/nrrzsEU58GD3pKFU3TLYDMCbetIsnV8eeFE=
 private key: (hidden)
 listening port: 51820

peer: PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg=
 allowed ips: 10.8.0.2/32, fd0d:86fa:c3bc::/128

Observe como a linha peer mostra a chave pública do Peer do WireGuard e os endereços IP, ou faixas de endereços, que ele tem permissão para usar ao se atribuir um IP.

Agora que você definiu os parâmetros de conexão do par no servidor, o próximo passo é iniciar o túnel no par.

Passo 9 — Conectando o Peer do WireGuard ao Túnel

Agora que seu servidor e o peer estão configurados para suportar sua escolha de IPv4, IPv6, encaminhamento de pacotes e resolução de DNS, é hora de conectar o peer ao túnel VPN.

Como você pode querer que a VPN esteja ativa apenas para certos casos de uso, usaremos o comando wg-quick para estabelecer a conexão manualmente. Se você quiser automatizar a inicialização do túnel como fez no servidor, siga esses passos na seção Iniciando o Servidor WireGuard em vez de usar o comando wg-quick.

Caso você esteja roteando todo o tráfego através da VPN e tenha configurado o encaminhamento de DNS, será necessário instalar o utilitário resolvconf no Peer do WireGuard antes de iniciar o túnel. Execute o seguinte comando para configurar isso:

sudo apt install resolvconf

Para iniciar o túnel, execute o seguinte no Peer do WireGuard:

sudo wg-quick up wg0

Você receberá uma saída como a seguinte:

[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.8.0.2/24 dev wg0
[#] ip -6 address add fd0d:86fa:c3bc::2/64 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a tun.wg0 -m 0 -x

Observe os endereços IPv4 e IPv6 destacados que você atribuiu ao par.

Se você definir o AllowedIPs no peer como 0.0.0.0/0 e ::/0 (ou usar faixas diferentes das que você escolheu para a VPN), então sua saída será semelhante ao seguinte:

[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.8.0.2/24 dev wg0
[#] ip -6 address add fd0d:86fa:c3bc::2/64 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a tun.wg0 -m 0 -x
[#] wg set wg0 fwmark 51820
[#] ip -6 route add ::/0 dev wg0 table 51820
[#] ip -6 rule add not fwmark 51820 table 51820
[#] ip -6 rule add table main suppress_prefixlength 0
[#] ip6tables-restore -n
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] iptables-restore -n

Neste exemplo, observe as rotas destacadas que o comando adicionou, que correspondem aos AllowedIPs na configuração do par.

Você pode verificar o status do túnel no peer usando o comando wg:

sudo wg

interface: wg0
 public key: PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg=
 private key: (hidden)
 listening port: 49338
 fwmark: 0xca6c

peer: U9uE2kb/nrrzsEU58GD3pKFU3TLYDMCbetIsnV8eeFE=
 endpoint: 203.0.113.1:51820
 allowed ips: 10.8.0.0/24, fd0d:86fa:c3bc::/64
 latest handshake: 1 second ago
 transfer: 6.50 KiB received, 15.41 KiB sent

Você também pode verificar o status no servidor novamente, e receberá uma saída semelhante.

Verifique se seu colega está usando a VPN utilizando os comandos ip route e ip -6 route. Se você estiver usando a VPN como gateway para todo o seu tráfego de Internet, confira qual interface será usada para o tráfego destinado aos resolvedores DNS da CloudFlare 1.1.1.1 e 2606:4700:4700::1111.

ip route get 1.1.1.1

1.1.1.1 dev wg0 table 51820 src 10.8.0.2 uid 1000
   cache

Observe que o dispositivo wg0 está sendo usado e o endereço IPv4 10.8.0.2 que você atribuiu ao peer. Da mesma forma, se você estiver usando IPv6, execute o seguinte:

ip -6 route get 2606:4700:4700::1111

2606:4700:4700::1111 from :: dev wg0 table 51820 src fd0d:86fa:c3bc::2 metric 1024 pref medium

Observe novamente a interface wg0 e o endereço IPv6 fd0d:86fa:c3bc::2 que você atribuiu ao peer.

Se o seu colega tiver um navegador instalado, você também pode visitar ipleak.net e ipv6-test.com para confirmar que ele está roteando seu tráfego pelo VPN.

Quando estiver pronto para desconectar da VPN no peer, use o comando wg-quick:

sudo wg-quick down wg0

Você receberá uma saída como a seguinte indicando que o túnel VPN está desligado:

[#] ip link delete dev wg0
[#] resolvconf -d tun.wg0 -f

Se você definir o AllowedIPs no peer como 0.0.0.0/0 e ::/0 (ou usar faixas diferentes das que você escolheu para a VPN), então sua saída será semelhante à seguinte:

[#] ip rule delete table 200 from 203.0.113.5
[#] ip route delete table 200 default via 203.0.113.1
[#] ip -4 rule delete table 51820
[#] ip -4 rule delete table main suppress_prefixlength 0
[#] ip -6 rule delete table 51820
[#] ip -6 rule delete table main suppress_prefixlength 0
[#] ip link delete dev wg0
[#] resolvconf -d tun.wg0 -f
[#] iptables-restore -n
[#] ip6tables-restore -n

Para reconectar à VPN, execute o comando wg-quick up wg0 novamente no peer. Se você quiser remover completamente a configuração de um peer do Servidor WireGuard, você pode executar o seguinte comando, certificando-se de substituir a chave pública correta pelo peer que deseja remover:

sudo wg set wg0 peer PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg= remove

Normalmente, você só precisará remover a configuração de um peer se o peer não existir mais, ou se suas chaves de criptografia forem comprometidas ou alteradas. Caso contrário, é melhor deixar a configuração no lugar para que o peer possa reconectar à VPN sem que seja necessário adicionar sua chave e allowed-ips toda vez.

Gerenciando e Rotacionando Chaves do WireGuard

WireGuard depende de pares de chaves públicas e privadas estáticas para autenticação e criptografia. Esse design reduz significativamente a complexidade da configuração, mas também coloca a responsabilidade pelo gerenciamento das chaves inteiramente sobre o administrador. Para implantações de VPN de longa duração, infraestrutura compartilhada ou ambientes com vários peers, o gerenciamento cuidadoso das chaves é essencial para manter a segurança e a estabilidade operacional.

Entendendo os Tipos de Chaves do WireGuard

Cada Peer do WireGuard usa duas categorias de chaves criptográficas.

• Chaves privadas de longo prazo: Uma chave privada identifica exclusivamente um peer e deve permanecer secreta o tempo todo. Esta chave é usada durante os handshakes criptografados para autenticar o peer e derivar chaves de sessão de curta duração. Se uma chave privada for exposta, qualquer sistema que possua essa chave pode se passar pelo peer.

• Chaves públicas de longo prazo: Uma chave pública é derivada de uma chave privada e é compartilhada com outros participantes. No hub central, as chaves públicas determinam quais participantes estão autorizados a se comunicar e quais endereços IP eles podem usar.

Além dessas chaves de longo prazo, o WireGuard deriva automaticamente chaves de sessão efêmeras durante os handshakes criptografados. Essas chaves de sessão são rotacionadas periodicamente e oferecem Sigilo Perfeito à Frente sem a intervenção do administrador.

Práticas Recomendada de Gerenciamento de Chaves

As seguintes práticas ajudam a reduzir riscos e simplificar as operações contínuas:

• Atribua um par de chaves exclusivo para cada dispositivo: Cada dispositivo deve ter seu próprio par de chaves privada e pública. Usar chaves exclusivas permite que o acesso seja revogado para um único dispositivo sem afetar os outros. Reutilizar chaves em vários sistemas aumenta o impacto de uma violação e complica a auditoria.

• Limite o acesso aos materiais da chave privada: Arquivos de chave privada devem ser legíveis apenas pelo usuário root. Em sistemas Linux, isso normalmente significa definir as permissões para 600 usando um comando como chmod 600 /etc/wireguard/private.key. Restringir o acesso aos arquivos ajuda a prevenir a divulgação acidental através de backups, logs ou usuários sem privilégios.

• Mantenha um inventário explícito de pares: Mantenha um registro que associe a chave pública de cada par ao nome do dispositivo, aos endereços IPv4 e IPv6 atribuídos e ao propósito previsto. Essa documentação se torna cada vez mais importante à medida que o número de pares aumenta e simplifica a solução de problemas, auditorias e a manutenção de rotina.

• Remova rapidamente pares não utilizados ou inativos: Quando um dispositivo é desativado ou não necessita mais de acesso VPN, remova sua chave pública da configuração central de pares. Deixar chaves não utilizadas aumenta a superfície de ataque e torna revisões futuras mais difíceis.

Situações que Exigem a Troca de Chaves

A rotação de chaves deve ser realizada em vários cenários comuns:

• Suscita suspeita ou confirmação de exposição da chave: Se uma chave privada pode ter sido copiada, vazada ou acessada por uma pessoa não autorizada, ela deve ser substituída imediatamente para prevenir falsificação de identidade.

• Dispositivos perdidos ou roubados: Quando um dispositivo é perdido ou roubado, trocar suas chaves garante que ele não possa mais se conectar à VPN, mesmo que a configuração original seja recuperada.

• Requisitos de segurança organizacional: Alguns ambientes exigem a rotação periódica de chaves para atender às políticas internas ou aos padrões de conformidade, mesmo que não haja suspeita de comprometimento.

• Mudanças na propriedade ou função do dispositivo: Quando um dispositivo é reassigned a outro usuário ou finalidade, rotacionar suas chaves previne acessos contínuos indesejados.

Rotacionando com Segurança as Chaves de um Par

O WireGuard mapeia endereços IP internos para chaves públicas específicas usando uma tabela de roteamento criptográfico. Por causa desse design, o mesmo endereço IP interno não pode ser atribuído com segurança a duas chaves públicas ao mesmo tempo. Portanto, a rotação de chaves geralmente envolve uma breve interrupção na conectividade enquanto a configuração é atualizada.

Para rotacionar as chaves de um par, siga este processo:

1. Gere um novo par de chaves privada e pública no peer.
2. Atualize a configuração do peer central para substituir a chave pública antiga pela nova, mantendo os mesmos valores de AllowedIPs. Não reinicie a interface ainda.
3. Atualize o arquivo de configuração do par para usar a nova chave privada.
4. Aplique a configuração atualizada no peer central, por exemplo, recarregando o serviço WireGuard ou usando wg syncconf. Neste ponto, o peer perderá temporariamente a conectividade.
5. Reinicie a interface WireGuard no peer para que ele comece a usar a nova chave privada.
6. Verifique se uma nova troca de aperto de mão é concluída e se o tráfego flui corretamente.
7. Remova quaisquer referências restantes à chave antiga, caso ainda existam.

Essa abordagem baseada em substituição reflete como o WireGuard aplica o roteamento criptográfico e evita configurações ambíguas ou conflitantes.

Rotacionando as Chaves no Par Central

Rotacionar a chave privada do peer central afeta todos os peers conectados. Cada configuração de peer deve ser atualizada com a nova chave pública antes que a conectividade possa ser restabelecida.

Porque essa mudança impacta todos os pares simultaneamente, a rotação da chave do par central deve ser planejada com cuidado e realizada durante uma janela de manutenção. Na prática, as chaves centrais são rotacionadas com menos frequência do que as chaves dos pares.

Gerenciando Chaves Pré-Compartilhadas (Opcional)

Além dos pares de chaves públicas e privadas, o WireGuard suporta uma Chave Pré-Compartilhada (PSK) opcional para cada peer. Uma PSK adiciona uma camada adicional de criptografia simétrica além da criptografia existente do WireGuard.

Chaves pré-compartilhadas são comumente usadas em ambientes de alta segurança como defesa contra avanços criptográficos futuros. Se o tráfego criptografado for registrado hoje e o algoritmo de chave pública subjacente for comprometido no futuro, uma PSK ainda impediria a descriptografia de sessões passadas.

Se PSKs forem usados, eles devem ser tratados como segredos sensíveis e rotacionados periodicamente. Rotacionar um PSK segue o mesmo padrão operacional de rotacionar chaves de pares e deve ser coordenado em ambos os lados da conexão.

Escolhendo uma Frequência de Rotação

O WireGuard não impõe um cronograma fixo de rotação de chaves. Os intervalos de rotação adequados dependem do ambiente.

• Implantações pessoais ou de curta duração podem não exigir rotação programada.
• Ambientes compartilhados ou de produção normalmente rotacionam chaves a cada 6 a 12 meses.
• Ambientes de alta segurança podem exigir rotações mais frequentes com base na política.

A rotação regular reduz o risco associado a credenciais de longa duração e alinha as implantações do WireGuard com práticas de segurança comuns.

WireGuard vs OpenVPN: Diferenças Práticas

WireGuard e OpenVPN são tecnologias de VPN amplamente utilizadas, mas elas adotam abordagens muito diferentes para criptografia, configuração e comportamento de rede. Entender essas diferenças ajuda os desenvolvedores a escolher a solução que melhor se adapta às suas restrições operacionais.

Configuração e Modelo Operacional

WireGuard utiliza um modelo de configuração estática baseado em pares de chaves públicas e privadas. Todos os pares são definidos explicitamente, e o comportamento de roteamento é controlado por valores de configuração fixos. Não há canal de controle, autoridade certificadora ou negociação dinâmica de parâmetros.

O OpenVPN depende de TLS e certificados X.509. Ele usa um canal de controle para autenticar clientes, negociar configurações de criptografia e gerenciar sessões. Esse modelo fornece flexibilidade, mas aumenta a complexidade de configuração e operação.

Na prática, as configurações do WireGuard são mais curtas, fáceis de auditar e menos propensas a erros sutis de configuração. As configurações do OpenVPN oferecem mais controle, mas exigem um gerenciamento cuidadoso para permanecerem seguras e consistentes.

Criptografia e Design de Segurança

O WireGuard usa um conjunto fixo de métodos criptográficos modernos. Essas escolhas não são configuráveis. Esse design elimina ataques de rebaixamento criptográfico e remove a necessidade de selecionar suítes de cifragem.

O OpenVPN suporta uma ampla variedade de algoritmos de criptografia e métodos de autenticação. Embora essa flexibilidade permita compatibilidade com sistemas legados, também aumenta o risco de configurações fracas ou inconsistentes.

Ambas as soluções suportam Perfect Forward Secrecy. O WireGuard realiza a rotação de chaves automaticamente através de seu mecanismo de handshake, enquanto o OpenVPN depende do comportamento da sessão TLS.

Características de Desempenho

O WireGuard é projetado para alto desempenho e baixa latência. Ele funciona no kernel do Linux e possui uma base de código pequena, o que reduz a sobrecarga e a troca de contexto. Na maioria dos ambientes, o WireGuard oferece maior taxa de transferência e latência mais consistente com ajustes mínimos.

Historicamente, o OpenVPN funciona no espaço do usuário e sofre uma sobrecarga adicional devido a trocas de contexto e ao gerenciamento de protocolos. As versões modernas do OpenVPN oferecem suporte ao Kernel Data Channel Offload (DCO), o que melhora significativamente o desempenho, mas esse recurso nem sempre está habilitado ou disponível em implantações padrão.

Mesmo com DCO, o WireGuard geralmente oferece um bom desempenho com menos variáveis de configuração.

Roaming de Rede e Travessia de Firewall

O WireGuard lida com mudanças de rede de forma eficiente. Se o endereço IP de um par mudar, como ao alternar entre WiFi e redes móveis, o túnel continua funcionando sem renegociação.

No entanto, o WireGuard opera exclusivamente sobre UDP. Embora o UDP seja eficiente, ele às vezes é bloqueado em redes WiFi públicas restritivas, firewalls corporativos ou redes institucionais. O WireGuard não possui alternativa nativa quando o tráfego UDP é bloqueado.

O OpenVPN suporta tanto UDP quanto TCP. Quando o UDP não está disponível, o OpenVPN pode ser configurado para rodar na porta TCP 443, fazendo com que o tráfego da VPN se pareça com o tráfego padrão de HTTPS. Essa capacidade torna o OpenVPN mais confiável em ambientes com regras rigorosas de firewall ou censura.

Para usuários que operam atrás de redes restritivas, o suporte a TCP frequentemente é o fator determinante na escolha do OpenVPN em vez do WireGuard.

Escopo de Funcionalidades e Extensibilidade

O OpenVPN inclui recursos que o WireGuard intencionalmente não oferece. Isso inclui autenticação baseada em usuário, atribuição dinâmica de endereços e integração com sistemas de identidade externos.

O WireGuard se concentra exclusivamente em túneis seguros. Fluxos de autenticação, controle de acesso e configuração dinâmica devem ser gerenciados fora do protocolo.

Isso torna o OpenVPN mais adequado para ambientes que exigem autenticação complexa ou gerenciamento centralizado de usuários, enquanto o WireGuard é mais adequado para VPNs em nível de infraestrutura e acesso baseado em pares.

Comparação Resumida

Escolhendo entre WireGuard e OpenVPN

O WireGuard é bem adequado para VPNs de infraestrutura, túneis site a site, clientes móveis e ambientes onde simplicidade, desempenho e previsibilidade são prioridades.

O OpenVPN continua sendo uma escolha sólida para ambientes corporativos que exigem tunelamento baseado em TCP, autenticação avançada ou operação confiável atrás de firewalls restritivos.

Em muitas implementações modernas, o WireGuard substitui o OpenVPN não porque ofereça mais recursos, mas porque oferece menos recursos com um comportamento mais claro.

Ajuste de Desempenho e Otimização

O WireGuard apresenta bom desempenho com suas configurações padrão, mas as condições reais da rede podem afetar a confiabilidade e a taxa de transferência. Fatores como tamanho dos pacotes, alcance do roteamento, comportamento do NAT e resolução de DNS influenciam como o túnel se comporta durante o uso contínuo ou intermitente.

Vamos analisar as áreas de afinação mais comuns e quando os ajustes são apropriados.

Seleção de MTU e Fragmentação de Pacotes

A Unidade Máxima de Transmissão (MTU) define o maior tamanho de pacote que pode ser transmitido sem fragmentação. O WireGuard criptografa e encapsula os pacotes, o que reduz a MTU efetiva em comparação a uma interface de rede física.

Por padrão, o WireGuard utiliza um MTU de 1420. Esse valor leva em conta a sobrecarga combinada dos cabeçalhos IPv6, UDP e da encapsulação do WireGuard e funciona bem para a maioria das redes baseadas em Ethernet. Alguns ambientes exigem um MTU menor. Isso é comum em redes móveis, conexões PPPoE e plataformas de nuvem com camadas adicionais de encapsulamento. Quando o MTU é muito grande, pacotes podem ser descartados ou fragmentados. Isso frequentemente resulta em conexões que funcionam para solicitações pequenas, mas travam ou falham para transferências maiores. Se esses sintomas ocorrerem, é recomendado reduzir o MTU de forma incremental. Valores como 1360, ou em ambientes mais restritos 1280, que é o MTU mínimo do IPv6, muitas vezes resolvem esses problemas com impacto mínimo na taxa de transferência.

O MTU deve ser definido explicitamente na seção [Interface] do arquivo de configuração para garantir um comportamento consistente após reinicializações.

Escopo e Impacto de AllowedIPs

A diretiva AllowedIPs influencia tanto o comportamento de roteamento quanto o desempenho. Faixas de endereços amplas fazem com que mais tráfego atravesse o túnel, o que aumenta a sobrecarga de criptografia e a carga no servidor. Usar valores estreitos de AllowedIPs limita o túnel apenas ao tráfego que requer proteção. Isso reduz o uso da CPU e evita encapsulamento desnecessário.

Quando 0.0.0.0/0 ou ::/0 está configurado, todo o tráfego é roteado através da VPN. Esta configuração é apropriada quando a privacidade, o controle centralizado de saída ou redes não confiáveis são uma preocupação, mas aumenta a latência e o uso de recursos para o tráfego geral da Internet.

A otimização de desempenho frequentemente envolve restringir AllowedIPs sempre que possível e evitar o roteamento de túnel completo, a menos que seja necessário.

Travessia NAT e Estabilidade de Conexão (PersistentKeepalive)

O WireGuard permanece intencionalmente silencioso quando nenhum dado está sendo transmitido. Por padrão, ele não envia pacotes de keepalive periodicamente. Em ambientes que usam NAT, como roteadores domésticos, redes móveis ou muitas redes em nuvem, esse silêncio pode fazer com que o dispositivo NAT feche a associação da conexão. Quando isso acontece, o tráfego de entrada do servidor é bloqueado até que o peer envie tráfego novamente. Esse comportamento é frequentemente percebido como lentidão, conexões atrasadas ou falhas intermitentes.

Para prevenir isso, o WireGuard fornece a configuração PersistentKeepalive. Esta opção pode ser adicionada à seção [Peer] da configuração do peer. Ela faz com que o peer envie um pequeno pacote de manutenção em intervalos fixos para manter o mapeamento NAT aberto. Um valor de 25 segundos é comumente usado e funciona bem com a maioria dos dispositivos NAT. Se uma conexão funciona inicialmente, mas falha após ficar ociosa, habilitar PersistentKeepalive=25 é a principal e recomendada solução.

Resolução de DNS e Comportamento do Túnel

A configuração de DNS tem um impacto significativo na percepção do desempenho da VPN. Quando os resolvedores de DNS não estão corretamente roteados pelo túnel, os aplicativos podem parecer lentos ou instáveis, mesmo quando o próprio túnel está funcionando corretamente.

Em configurações de gateway, as consultas DNS devem ser enviadas através da VPN para garantir um roteamento consistente e evitar vazamentos. Isso requer definir explicitamente os resolvedores DNS na configuração do peer. Quando o DNS está mal configurado, os sintomas comuns incluem carregamento lento de páginas, conectividade inconsistente ou tráfego sendo roteado fora da VPN, mesmo com um túnel ativo.

Selecionar resolvedores que sejam acessíveis através do túnel e respondam rapidamente melhora tanto a confiabilidade quanto a experiência do usuário.

Diferenças de Desempenho entre IPv4 e IPv6

Em ambientes de pilha dupla, o IPv4 e o IPv6 podem se comportar de maneira diferente. Os caminhos IPv6 podem ter diferentes limitações de MTU, políticas de roteamento ou comportamento de firewall.

Testar ambos os protocolos de forma independente ajuda a identificar problemas específicos de cada protocolo. Ferramentas como ping, tracepath e ip route get são úteis para validar o roteamento e o comportamento do MTU para cada família de endereços.

Se o desempenho do IPv6 parecer inconsistente, verifique se o tráfego ICMPv6 está permitido. O ICMPv6 é necessário para a Descoberta de MTU do Caminho, e bloqueá-lo pode fazer com que as conexões parem em pacotes maiores.

CPU e Sobrecarga de Criptografia

O WireGuard utiliza criptografia moderna que é eficiente na maioria dos sistemas. No entanto, a criptografia ainda consome recursos da CPU.

Em máquinas virtuais pequenas, roteadores incorporados ou sistemas sem aceleração de hardware, configurações de túnel completo podem saturar a CPU sob carga contínua.

Monitorar o uso da CPU durante tráfego intenso ajuda a determinar se os problemas de desempenho são causados pela sobrecarga da criptografia em vez da configuração da rede. Nesses casos, pode ser necessário reduzir o tráfego tunelado ou atualizar a instância do servidor.

Validando Alterações de Desempenho

A otimização de desempenho deve ser feita de forma incremental. Após cada alteração, a conectividade e a estabilidade devem ser verificadas antes de aplicar ajustes adicionais.

Passos de validação úteis incluem verificar a estabilidade do handshake com wg, medir a latência e a taxa de transferência antes e depois das alterações, e confirmar o comportamento de roteamento com ip route e ip -6 route. Essa abordagem minimiza riscos e simplifica a resolução de problemas.

Perguntas Frequentes

1. O que é o WireGuard e como ele funciona no Ubuntu?

WireGuard é uma tecnologia moderna de VPN projetada para ser muito mais rápida e fácil de configurar do que opções antigas como OpenVPN ou IPsec. Você pode pensar nela como um túnel seguro que conecta seus dispositivos diretamente. Diferente das VPNs antigas, que são pesadas e complexas, o WireGuard é extremamente leve. No Ubuntu, ele funciona executando diretamente dentro do kernel do Linux, o núcleo do sistema operacional. Como ele opera profundamente no sistema, em vez de ser uma aplicação separada sobre o sistema, consome muito pouca bateria e processa dados de forma incrivelmente rápida.

Para estabelecer uma conexão, o WireGuard usa um método muito semelhante ao SSH. Ele gera um par de “chaves” para cada dispositivo: uma chave privada (que permanece secreta no dispositivo) e uma chave pública (que você compartilha com os outros dispositivos com os quais deseja se conectar). A conexão só acontece se as chaves corresponderem perfeitamente, tornando o handshake rápido e seguro.

2. O WireGuard é mais seguro que o OpenVPN?

Para a maioria dos usuários, o WireGuard é considerado mais seguro devido à sua simplicidade e design moderno. A principal razão é o tamanho do seu código. O WireGuard é construído com apenas cerca de 4.000 linhas de código, enquanto o OpenVPN possui mais de 100.000. Essa enorme diferença significa que é muito mais fácil para os especialistas em segurança lerem o código do WireGuard e encontrarem vulnerabilidades (bugs) antes que agentes mal-intencionados consigam.

O WireGuard também obriga você a usar os padrões de criptografia mais recentes e fortes disponíveis hoje. VPNs mais antigas permitem agilidade criptográfica, o que significa que podem rebaixar para métodos de criptografia mais fracos para suportar dispositivos antigos. O WireGuard elimina essa escolha, impedindo que atacantes enganem sua VPN para usar uma criptografia mais fraca. Além disso, o WireGuard é discreto por padrão; se um dispositivo não autorizado enviar um pacote para seu servidor, o WireGuard simplesmente não responderá. Isso torna seu servidor invisível para hackers que procuram por portas abertas.

3. Posso configurar o WireGuard no Ubuntu sem usar Docker?

Sim, você pode configurá-lo facilmente diretamente no sistema sem usar contêineres Docker. Na verdade, executá-lo diretamente é frequentemente o método preferido no Ubuntu, pois o software está incluído nos repositórios de software padrão do Ubuntu. Geralmente, você só precisa executar os comandos de instalação padrão abaixo, que irão buscar o software necessário diretamente da fonte oficial do Ubuntu.

sudo apt update
sudo apt install wireguard

4. Como adiciono múltiplos clientes (peers) do WireGuard?

O WireGuard usa um conceito de ponto a ponto, o que significa que cada dispositivo conectado é tratado como um “par”. Para adicionar vários dispositivos, como um laptop, um smartphone e um tablet, você simplesmente edita o arquivo de configuração do servidor (geralmente localizado em /etc/wireguard/wg0.conf).

Para cada novo dispositivo, você adiciona um novo bloco de texto rotulado como [Peer]. Dentro deste bloco, você deve colar a Chave Pública desse dispositivo específico e atribuir a ele um endereço IP interno único (como 10.0.0.2 para o primeiro dispositivo, 10.0.0.3 para o segundo, e assim por diante). É fundamental que esses endereços IP internos não se sobreponham.

Aqui está um bloco de configuração de exemplo simples:

[Interface]
# Server settings...
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = <Server_Private_Key>

[Peer]
# Client 1 (Laptop)
PublicKey = <Laptop_Public_Key>
AllowedIPs = 10.0.0.2/32

[Peer]
# Client 2 (Phone)
PublicKey = <Phone_Public_Key>
AllowedIPs = 10.0.0.3/32

5. Quais portas o WireGuard usa?

O WireGuard usa a porta UDP 51820 por padrão. Ele depende estritamente do protocolo UDP porque é mais rápido para tunelamento de dados do que o TCP. O TCP requer uma confirmação para cada pacote de dados enviado, o que pode desacelerar significativamente uma conexão VPN. O UDP apenas envia os dados sem esperar por um recebimento, o que é perfeito para a natureza de alta velocidade do WireGuard. Ao configurar o firewall do seu Ubuntu (UFW), você deve permitir especificamente o tráfego nessa porta UDP, caso contrário, as solicitações de conexão serão bloqueadas antes de chegarem ao software VPN.

6. Como faço para solucionar problemas de conexão do WireGuard?

Solucionar problemas do WireGuard geralmente é simples porque há menos partes móveis. Se você não conseguir se conectar, deve seguir esta sequência específica de verificações:

Primeiro, verifique o status da conexão executando sudo wg show no seu servidor. Se a conexão estiver saudável, você verá uma linha dizendo latest handshake seguida de um horário (por exemplo, “há 1 minuto”). Se essa linha estiver ausente, os dispositivos não estão se comunicando de forma alguma. Isso quase sempre é causado por um firewall bloqueando a porta UDP ou por uma incompatibilidade nas chaves pública/privada.

Em segundo lugar, se o handshake estiver funcionando, mas você não consegue navegar na internet, o problema provavelmente é o encaminhamento de IP. Você precisa garantir que seu servidor Ubuntu tenha permissão para rotear o tráfego da VPN para a internet. Você pode verificar isso analisando o arquivo /etc/sysctl.conf e garantindo que a linha net.ipv4.ip_forward=1 esteja ativa (não comentada).

7. O WireGuard suporta IPv6 no Ubuntu?

Sim, o WireGuard tem um excelente suporte para IPv6. Ele é muito flexível e pode encapsular (envolver) diferentes tipos de tráfego. Por exemplo, você pode acessar um site que só possui IPv4 através de uma conexão IPv6, ou vice-versa. Para habilitar isso, você só precisa incluir endereços IPv6 separados por vírgula no seu arquivo de configuração junto com seus endereços IPv4 padrão. Você deve adicioná-los tanto no campo Address (para o próprio IP do servidor) quanto no campo AllowedIPs (para os IPs dos clientes).

8. Como faço para habilitar o WireGuard para iniciar na inicialização?

Para garantir que sua VPN seja ativada automaticamente sempre que você reiniciar seu servidor Ubuntu, você precisa usar o systemd, que é o gerenciador de sistema do Linux. Você utiliza o comando enable para informar ao sistema que ele deve procurar seu arquivo de configuração específico (por exemplo, wg0) e carregá-lo durante a sequência de inicialização. Isso garante que, se seu servidor reiniciar por causa de uma atualização, sua conexão VPN volte a funcionar sem que você precise iniciá-la manualmente.

sudo systemctl enable wg-quick@wg0

Conclusão

Neste tutorial, você configura uma VPN WireGuard em um servidor Ubuntu e conecta um peer usando IPv4 e IPv6. Ao longo do caminho, você configurou as chaves, atribuiu endereços ao túnel e habilitou o servidor para roteamento seguro de tráfego, proporcionando uma VPN funcional que é fácil de entender e operar.

O guia também abordou alguns detalhes práticos que são importantes uma vez que a VPN esteja em uso regular, como gerenciar chaves ao longo do tempo, lidar com IPv6 e redes de pilha dupla, e melhorar a confiabilidade e o desempenho ajustando o MTU, keepalives e as configurações de DNS. Com esses elementos em prática, você deve estar bem preparado para rodar o WireGuard em ambientes reais ou adaptá-lo conforme suas necessidades mudem.

Se você quiser saber mais sobre o WireGuard, incluindo como configurar túneis mais avançados ou usar o WireGuard com contêineres, visite a documentação oficial do WireGuard. Para mais tutoriais relacionados à segurança dos seus sistemas Ubuntu, confira os artigos a seguir:

• Como Configurar um Firewall com UFW no Ubuntu
• UFW Essentials: Regras e Comandos Comuns de Firewall para Segurança no Linux
• VPC vs VPN: Qual se encaixa melhor às suas necessidades de rede segura?
• Como configurar e ajustar um servidor OpenVPN no Ubuntu

Obrigado por aprender com a comunidade Linux-Console.net.