Como Configurar o WireGuard no Ubuntu

Introdução

WireGuard é uma rede privada virtual (VPN) leve que suporta tanto ligações IPv4 como IPv6. Uma VPN permite-lhe atravessar redes não confiáveis como se estivesse numa rede privada. Dá-lhe a capacidade de aceder à internet de forma mais segura a partir de dispositivos como computadores portáteis ou telemóveis quando ligado a redes não confiáveis, incluindo Wi-Fi público.

A encriptação do WireGuard baseia-se em chaves públicas e privadas para que os pares consigam estabelecer túneis encriptados entre si. Cada versão do WireGuard utiliza um conjunto fixo de métodos criptográficos modernos, o que ajuda a manter o protocolo simples e previsível. Este design evita a negociação em tempo de execução e reduz o risco de erros de configuração.

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

Neste tutorial, irá configurar o WireGuard num servidor Ubuntu e configurar outra máquina para se ligar a ele como par utilizando tanto IPv4 como IPv6, normalmente referido como uma configuração dual-stack. Também irá aprender como encaminhar o tráfego do par através do servidor WireGuard numa configuração de gateway, bem como como usar a VPN para comunicação criptografada entre pares.

Além da configuração básica, este guia aborda tópicos práticos que são importantes para implementações no mundo real. Estes incluem compreender a arquitectura ponto-a-ponto do WireGuard, gerir e rodar chaves, lidar corretamente com IPv6 e encaminhamento de pilha dupla, melhorar a fiabilidade para pares por trás de NAT, otimizar o desempenho e compreender como o WireGuard se compara ao OpenVPN em termos de protocolos de transporte e comportamento do firewall.

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

Pré-requisitos

Para seguir este tutorial, você precisará de:

• Um servidor Ubuntu com um utilizador não-root com privilégios sudo e um firewall ativado. Para configurar isto, pode seguir o nosso tutorial de Configuração Inicial de Servidor com Ubuntu. Referir-nos-emos a este como o Servidor WireGuard ao longo deste guia.

• Vai precisar de uma máquina cliente que irá usar para se conectar ao seu Servidor WireGuard. Neste tutorial, vamos referir-nos a esta máquina como WireGuard Peer. Para os propósitos deste tutorial, é recomendado que utilize a sua máquina local como o WireGuard Peer, mas pode usar servidores remotos ou telefones móveis como clientes, se preferir. Se estiver a usar um sistema remoto, certifique-se de seguir todas as secções opcionais mais adiante neste tutorial, caso contrário pode bloquear-se fora do sistema.

• Para usar o WireGuard com IPv6, também precisará de garantir que o seu servidor está configurado para suportar esse tipo de tráfego. Se desejar ativar o suporte a IPv6 com o WireGuard e estiver a utilizar um Droplet da Linux-Console.net, consulte esta página de documentação Como Ativar o IPv6 nos Droplets. 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 compreender como os sistemas, os pares e o tráfego de rede interagem. O WireGuard utiliza uma arquitetura deliberadamente simples que evita planos de controlo, autoridades de certificação e negociação em tempo de execução de parâmetros de configuração. Toda a encriptação, autenticação e comportamento de encaminhamento são definidos explicitamente através de ficheiros 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 existe um binário distinto de servidor ou cliente.

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

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

Componentes Principais numa Implementação do WireGuard

Uma implementação do WireGuard consiste num 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 encriptado numa única porta. Ele hospeda uma interface de túnel virtual, normalmente chamada wg0, e armazena as chaves públicas de outros peers autorizados a comunicar com ele. O hub não descobre peers de forma dinâmica nem aceita conexões implicitamente. O tráfego é aceite apenas de peers cujas chaves públicas e intervalos de IP permitidos estão configurados explicitamente.

• Peers de Conexão (Spokes): Peers de conexão são dispositivos que estabelecem túneis encriptados para o peer central. Estes dispositivos podem ser portáteis, 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 as suas regras de encaminhamento o instruem a fazê-lo.

• Interface de Túnel (wg0): A interface de túnel é um dispositivo de rede virtual criado em cada sistema participante. Todo o tráfego encriptado entra e sai através desta interface. Do ponto de vista do sistema operativo, o wg0 comporta-se como uma interface de rede normal, permitindo que sejam aplicadas tabelas de encaminhamento, regras de firewall e comportamentos de encaminhamento normais.

Criptografia, Autenticação e Apertos de Mão

O WireGuard utiliza criptografia de chave pública para autenticar pares e encriptar o tráfego. Cada par gera uma chave privada de longa duração que permanece no sistema local e nunca é transmitida. A chave pública correspondente é partilhada com outros pares e adicionada às suas configurações.

Quando a comunicação começa, o WireGuard realiza uma handshake criptográfica silenciosa e automática baseada na framework do protocolo Noise. Esta handshake estabelece chaves de sessão efémeras e fornece Sigilo Perfeito em Frente. Estas chaves de sessão são rotacionadas periodicamente sem intervenção do utilizador.

O WireGuard não negocia conjuntos de cifragem, métodos de autenticação ou versões de protocolo. Todos os elementos criptográficos são fixos por design. Isto elimina uma classe inteira de erros de configuração, ao mesmo tempo que continua a fornecer 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 encaminhamento e o roteamento estão configurados. Este tutorial foca-se nos dois casos de uso mais comuns.

Acesso Peer-to-Peer ou à Rede Interna

Numa configuração de acesso ponto-a-ponto ou interna, o tráfego é encriptado apenas entre os sistemas que fazem parte da VPN. O par central atua como um ponto final seguro ou relé, mas não encaminha tráfego para redes externas.

Esta configuração é normalmente utilizada para aceder a serviços privados, administrar a infraestrutura ou ligar sistemas isolados. O tráfego é encaminhado para o túnel apenas quando o endereço de destino corresponde às faixas de IP privadas definidas na configuração do par.

Modo Gateway VPN

No modo gateway, o par central encaminha o tráfego de outros pares para redes externas, incluindo a Internet pública. Os pares enviam parte ou todo o seu tráfego através do túnel, e o par central encaminha esse tráfego para a frente utilizando o encaminhamento de IP e a tradução de endereços de rede.

Esta configuração requer definiçõ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 originar-se do endereço IP público do par central.

O Papel Duplo de AllowedIPs

A diretiva AllowedIPs serve a dois propósitos distintos no WireGuard.

Primeiro, define o comportamento de encaminhamento de saída. Quando o endereço de destino de um pacote corresponde a uma entrada em AllowedIPs, esse pacote é encaminhado através do túnel WireGuard.

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

Este papel duplo é intencional e é uma das fontes mais comuns de erros de configuração. Um encaminhamento correto por si só 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 Encaminhamento e Ferramentas de Ajuda

O módulo do kernel do WireGuard em si não modifica rotas do sistema, definições de DNS ou regras de firewall. Ele apenas encripta e desencripta pacotes e os associa a pares.

A automatização do encaminhamento é gerida por ferramentas auxiliares como wg-quick. Esta utilidade lê o ficheiro de configuração do WireGuard e aplica as entradas necessárias na tabela de encaminhamento, as definições de DNS e as regras de firewall quando um túnel é activado ou desactivado.

Se o WireGuard for configurado utilizando ferramentas alternativas, como comandos wg puros, systemd-networkd ou scripts personalizados, estas alterações de roteamento devem ser geridas manualmente.

Esta separação mantém o protocolo principal simples, permitindo ao mesmo tempo uma integração flexível com diferentes pilhas de rede do sistema.

Passo 1 — Instalar o WireGuard e Gerar um Par de Chaves

O primeiro passo neste tutorial é instalar o WireGuard no seu servidor. Para começar, actualize o índice de pacotes do seu servidor WireGuard e instale o WireGuard utilizando os seguintes comandos. Pode ser solicitado que forneça a senha do seu utilizador sudo se for a primeira vez que está a usar sudo nesta sessão:

sudo apt update

sudo apt install wireguard

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

Também precisará de alterar as permissões da chave que acabou de criar usando o comando chmod, uma vez que, por defeito, o ficheiro pode ser lido por qualquer utilizador no seu servidor.

Crie a chave privada para o WireGuard e altere as 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 ficheiro para utilizadores e grupos que não sejam o utilizador root, garantindo que apenas ele pode aceder à chave privada.

Deverá receber uma única linha de saída codificada em base64, que é a chave privada. Uma cópia da saída também é armazenada no ficheiro /etc/wireguard/private.key para referência futura pela parte tee do comando. Faça uma nota cuidadosa da chave privada que é exibida, pois irá precisar de a adicionar ao ficheiro de configuração do WireGuard mais tarde nesta secção.

O próximo passo é criar a chave pública correspondente, que é derivada da chave privada. Utilize o seguinte comando para criar o ficheiro 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 estão ligados entre si usando o operador | (pipe):

• sudo cat /etc/wireguard/private.key: este comando lê o ficheiro da chave privada e apresenta-o no fluxo de saída standard.
• wg pubkey: o segundo comando recebe a saída do primeiro comando como entrada padrão e processa-a 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 ficheiro chamado /etc/wireguard/public.key.

Quando executa o comando, voltará a receber uma única linha de saída codificada em base64, que é a chave pública do seu Servidor WireGuard. Copie-a para algum lugar de referência, uma vez que precisará de distribuir a chave pública a qualquer par que se ligue ao servidor.

Passo 2 — Escolher Endereços IPv4 e IPv6

Na secção anterior instalou o WireGuard e gerou um par de chaves que será usado para encriptar o tráfego de e para o servidor. Nesta secção, irá criar um ficheiro de configuração para o servidor e configurar o WireGuard para iniciar automaticamente quando o seu servidor for reiniciado. Também irá definir endereços IPv4 e IPv6 privados para usar com o seu servidor e pares WireGuard.

Se planeia usar ambos os endereços IPv4 e IPv6, siga ambas as secções. Caso contrário, siga as instruções na secção apropriada para as necessidades de rede da sua VPN.

Passo 2(a) — Escolher um Intervalo IPv4

Se estiver a usar o seu servidor WireGuard com peers IPv4, o servidor precisa de um intervalo de endereços IPv4 privados para usar nos clientes e na sua interface de túnel. Pode escolher qualquer intervalo de endereços IP a partir dos seguintes blocos de endereços reservados (se quiser saber mais sobre como estes blocos são atribuídos, consulte 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, vamos usar 10.8.0.0/24 como um bloco de endereços IP a partir do primeiro intervalo de IPs reservados. Este intervalo permitirá até 255 ligações de pares diferentes e, geralmente, não deve ter endereços sobrepostos ou em conflito 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 se este intervalo de exemplo não for compatível com as suas redes.

O servidor WireGuard irá utilizar um único endereço IP da gama para o seu endereço IPv4 do túnel privado. Usaremos 10.8.0.1/24 aqui, mas qualquer endereço na gama de 10.8.0.1 a 10.8.0.255 pode ser utilizado. Faça uma nota do endereço IP que escolher caso utilize algo diferente de 10.8.0.1/24. Irá adicionar este endereço IPv4 ao ficheiro de configuração que definir em Criar uma Configuração de Servidor WireGuard.

Passo 2(b) — Escolher um Intervalo IPv6

Se estiver a usar o WireGuard com IPv6, então precisará de gerar um prefixo de endereço unicast IPv6 local único com base no algoritmo descrito na RFC 4193. Os endereços que utilizar com o WireGuard estarão associados a uma interface de túnel virtual. Será necessário completar alguns passos 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 forma recomendada de obter um prefixo IPv6 único é combinar a hora do dia com um valor de identificação único de um sistema, como um número de série ou ID de dispositivo. Esses valores são então submetidos a uma função de hash e truncados, resultando num conjunto de bits que pode ser usado 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 carimbo de data/hora de 64 bits usando a utilidade date com o seguinte comando:

date +%s%N

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

1628101352127592197

Registe o valor em algum lugar para utilização posterior nesta secção. De seguida, copie o valor machine-id do seu servidor a partir do ficheiro /var/lib/dbus/machine-id. Este identificador é único do seu sistema e não deverá alterar-se enquanto o servidor existir.

cat /var/lib/dbus/machine-id

Receberá uma saída como a seguinte:

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

Agora precisa de combinar o carimbo temporal com o machine-id e criar um hash do valor resultante usando o algoritmo SHA-1. O comando utilizará o seguinte formato:

printf <timestamp><machine-id> | sha1sum

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

printf 162810135212759219720086c25853947c7aeee2ca1ea849d7d | sha1sum

Receberá um valor de hash como o seguinte:

4f267c51857d6dc93a0bca107bca2f0d86fac3bc  -

Note que a saída do comando sha1sum está em hexadecimal, por isso a saída utiliza 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 com hash.

O algoritmo no RFC requer apenas os 40 bits menos significativos (finais), ou 5 bytes, do resultado do hash. Utilize 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é ao fim da linha de entrada.

Deverá receber uma saída como a seguinte:

0d86fac3bc

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

Agora pode construir o seu prefixo de rede IPv6 único, acrescentando os 5 bytes que gerou ao prefixo fd, separando cada 2 bytes com um cólon : para maior legibilidade. Como cada sub-rede no seu prefixo único pode conter um total de 18.446.744.073.709.551.616 endereços IPv6 possíveis, 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 irá utilizar para atribuir endereços IP individuais às interfaces do 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 incrementa-se o valor em um cada vez que adiciona um peer, por exemplo, fd0d:86fa:c3bc::2/64. Tome nota do IP e prossiga com a configuração do Servidor WireGuard na próxima secção deste tutorial.

Considerações sobre a 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 formas importantes em relação ao IPv4, especialmente quando o WireGuard é usado como um gateway VPN. Compreender estas diferenças ajuda a prevenir falhas de encaminhamento, túneis parciais e fugas comuns de IPv6.

Suporte a IPv6 no WireGuard

O WireGuard suporta IPv6 como um protocolo de primeira classe. O tráfego IPv6 é encriptado, autenticado e encaminhado utilizando os mesmos mecanismos que o tráfego IPv4. Não existe um modo IPv6 separado nem uma configuração adicional. Se forem atribuídos endereços IPv6 à interface do túnel e as regras de encaminhamento o permitirem, o tráfego IPv6 circula automaticamente através do túnel.

Ao contrário do IPv4, o IPv6 foi concebido para evitar NAT utilizando endereços globalmente roteáveis, mas na prática muitos ambientes de VPN e de cloud continuam a usar NAT por simplicidade operacional. No entanto, este comportamento depende do ambiente de rede. Em muitas configurações de gateways VPN, como instâncias de VPS na cloud ou routers domésticos, o servidor não recebe um prefixo IPv6 delegado que possa ser roteado para os pares da VPN.

Nestes cenários comuns, os pares recebem endereços IPv6 privados, normalmente de um intervalo de Endereços Locais Únicos (ULA). Quando são utilizados endereços IPv6 privados e o servidor não possui um prefixo roteável para eles, a mascaragem IPv6 ainda é necessária. Isto é geralmente implementado com regras ip6tables -t nat, de forma semelhante à mascaragem IPv4, para permitir que os pares VPN acedam à Internet pública.

O IPv6 pode evitar NAT completamente quando a delegação de prefixo adequada está disponível. No entanto, a maioria das implementações simples de gateways VPN ainda depende do mascaramento IPv6 para manter o encaminhamento gerível.

Comportamento Dual-Stack Explicado

Uma configuração de pilha dupla permite tanto IPv4 como IPv6 na mesma interface WireGuard. Nesta configuração, à interface wg0 é atribuído um endereço IPv4 e um endereço IPv6, e cada protocolo é encaminhado de forma independente.

O sistema operativo avalia as rotas IPv4 e IPv6 separadamente. Um par pode encaminhar com sucesso o tráfego IPv4 através do túnel enquanto o tráfego IPv6 o contorna, ou vice-versa. Este comportamento é esperado e quase sempre indica um problema de configuração em vez de um problema com o próprio WireGuard.

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

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

Para IPv4, as implementações do WireGuard normalmente utilizam intervalos de endereços privados, como 10.0.0.0/8 ou 192.168.0.0/16. Cada par é normalmente atribuído a um único endereço IPv4.

Para o IPv6, é comum definir a rede VPN como um prefixo /64, como fd00::/64. Enquanto as redes Ethernet requerem 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 estes mecanismos.

Por causa disso, é seguro e muitas vezes recomendado atribuir a cada par um endereço IPv6 /128, como fd00::2/128. Usar endereços /128 garante um comportamento de encaminhamento rigoroso e impede que os pares tentem comunicar-se diretamente com outros endereços na sub-rede sem regras de encaminhamento adequadas.

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

Encaminhar Todo o Tráfego com IPv6

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

Para IPv4, o encaminhamento de 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 encaminhar 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 utilizar a interface de rede local. Esta situação é conhecida como fuga de IPv6. Normalmente, resulta em consultas DNS, tráfego web ou ligações de aplicações a contornar a VPN via IPv6, enquanto o tráfego IPv4 permanece protegido.

Os vazamentos de IPv6 são uma fonte frequente de confusão e devem ser sempre testados quando a rede em pilha dupla está ativada.

Firewall, Encaminhamento e ICMPv6

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

As regras do firewall também devem ser definidas explicitamente para IPv6. Ferramentas como ufw, iptables e nftables tratam o IPv4 e o 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 estar a funcionar.

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

Erros Comuns em Pilhas Duplas

Vários problemas ocorrem frequentemente em implementações WireGuard com pilha dupla. As rotas IPv6 podem estar em falta na diretiva AllowedIPs, fazendo com que o tráfego IPv6 contorne o túnel. O encaminhamento IPv6 pode não estar ativado no servidor, impedindo que o tráfego saia da interface do túnel. As regras do firewall podem permitir tráfego IPv4, mas bloquear tráfego IPv6 ou ICMPv6. Os resolutores DNS podem devolver endereços IPv6 mesmo que a roteação IPv6 não esteja corretamente configurada.

Estes problemas surgem frequentemente como falhas intermitentes e são frequentemente diagnosticados de forma errada como problemas de aplicação ou de protocolo.

Escolher Entre Apenas IPv4, Apenas IPv6 e Duplo Empilhamento

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

As implementações apenas com IPv4 são mais fáceis de integrar com sistemas e ferramentas legadas. As implementações apenas com IPv6 eliminam a necessidade de NAT IPv4 e evitam o esgotamento de endereços, mas exigem suporte consistente a IPv6 por parte dos fornecedores e redes de clientes.

As implementações de pilha dupla proporcionam a maior flexibilidade, mas também exigem o planeamento, configuração e validação mais cuidadosos.

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

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

• Certifique-se de que possui a chave privada disponível em Instalar o WireGuard e Gerar um Par de Chaves.
• Se estiver a usar WireGuard com IPv4, vai precisar do endereço IP que escolheu para o servidor em Escolher um Intervalo IPv4, que neste exemplo é 10.8.0.1/24.
• Se estiver a usar o WireGuard com IPv6, vai precisar do endereço IP do servidor que gerou em Escolher 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 ficheiro de configuração usando nano ou o seu editor preferido, executando o seguinte comando:

sudo nano /etc/wireguard/wg0.conf

Adicione as seguintes linhas ao ficheiro, substituindo a sua chave privada pelo valor destacado base64_encoded_private_key_goes_here, e o(s) endereço(s) IP na linha Address. Também pode alterar a linha ListenPort se pretender que o WireGuard esteja disponível numa 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 guardadas no ficheiro de configuração.

Guarde e feche o ficheiro /etc/wireguard/wg0.conf. Se estiver a usar o nano, pode fazê-lo com CTRL+X, depois Y e ENTER para confirmar. Agora tem uma configuração inicial do servidor que pode expandir dependendo de como pretende usar o seu servidor WireGuard VPN.

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

Se estiver a usar o WireGuard para ligar um peer ao Servidor WireGuard apenas para aceder a serviços no servidor, então não precisa de completar esta secção. Se desejar encaminhar o tráfego de Internet do seu Peer WireGuard através do Servidor WireGuard, então precisará de configurar o encaminhamento de IP seguindo esta secção do tutorial.

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

sudo nano /etc/sysctl.conf

Se estiver a usar IPv4 com o WireGuard, adicione a seguinte linha no final do ficheiro:

net.ipv4.ip_forward=1

Se estiver a usar IPv6 com o WireGuard, adicione esta linha no final do ficheiro:

net.ipv6.conf.all.forwarding=1

Se estiver a usar tanto IPv4 como IPv6, certifique-se de incluir ambas as linhas. Guarde e feche o ficheiro quando terminar.

Para ler o ficheiro e carregar os novos valores para a sua sessão de terminal atual, 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 esta configuração permitir-lhe-á encaminhar todo o tráfego web do seu Peer WireGuard através do endereço IP do seu servidor, e o endereço IP público do seu cliente ficará efetivamente oculto.

No entanto, antes que o tráfego possa ser encaminhado corretamente através do seu servidor, será necessário configurar algumas regras de firewall. Estas regras garantirão que o tráfego de e para o seu Servidor WireGuard e os Clientes flua corretamente.

Passo 5 — Configurar o firewall do servidor WireGuard

Nesta secção, irá editar a configuração do Servidor WireGuard para adicionar regras de firewall que garantirão que o tráfego para e a partir do servidor e dos clientes seja encaminhado corretamente. Como na secção anterior, ignore este passo se estiver a usar o seu VPN WireGuard apenas para uma ligação máquina a máquina para aceder a recursos que estão restritos à sua VPN.

Para permitir o tráfego VPN do WireGuard através do firewall do servidor, será necessário ativar o mascaramento, que é um conceito do iptables que fornece tradução de endereços de rede (NAT) dinâmica em tempo real para encaminhar corretamente as ligaçõ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 cadeia 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 irá adicioná-lo às regras do iptables na próxima etapa.

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

sudo nano /etc/wireguard/wg0.conf

No final do ficheiro, 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, irão 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 na interface VPN wg0 para a interface de rede eth0 no servidor. Funciona em conjunto com os valores sysctl net.ipv4.ip_forward e net.ipv6.conf.all.forwarding que configurou na secção anterior.
• iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE: Esta regra configura a mascaragem e reescreve o tráfego IPv4 que entra na interface VPN wg0 para fazer parecer que se origina diretamente no 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 entra pela interface VPN wg0 para parecer que se origina 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. Estas regras são o inverso das regras PostUp e funcionam para desfazer as regras de encaminhamento e mascaramento para a interface VPN quando a VPN é interrompida.

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

Por outro lado, se estiver a usar 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. Guarde e feche o ficheiro quando terminar.

A última parte da configuração do firewall no seu servidor WireGuard é permitir o tráfego para e a partir da porta UDP do WireGuard em si. Se não alterou a porta no ficheiro /etc/wireguard/wg0.conf do servidor, a porta que deverá abrir é 51820. Se escolheu uma porta diferente ao editar a configuração, certifique-se de a substituir no seguinte comando UFW.

Caso 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 volte a ativar o UFW para o reiniciar e carregar as alterações de todos os ficheiros que modificou:

sudo ufw disable

sudo ufw enable

Pode confirmar que as regras estão em vigor executando o comando ufw status. Execute-o, e deverá receber uma saída semelhante à 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)

O seu servidor WireGuard está agora configurado para gerir corretamente o tráfego da VPN, incluindo encaminhamento e mascaramento para os pares. Com as regras de firewall em vigor, pode iniciar o próprio serviço WireGuard para começar a ouvir as ligações dos pares.

Passo 6 — Iniciando o Servidor WireGuard

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

Usar um serviço systemd significa que pode configurar o WireGuard para iniciar automaticamente no arranque, permitindo assim ligar-se à sua VPN a qualquer momento, desde que o servidor esteja a funcionar. Para fazer isto, active o serviço wg-quick para o túnel wg0 que 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. Deveria ver o serviço listado como ativo. Note que o wg-quick sai depois de configurar a interface, por isso ativo (terminado) é 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-lhe os endereços IPv4 e IPv6 que adicionou ao ficheiro de configuração. Pode usar estas regras para resolver 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 a sua máquina cliente como um Peer do WireGuard e ligar-se ao Servidor WireGuard.

Passo 7 — Configurar um Peer do WireGuard

Configurar um Peer WireGuard é semelhante a configurar o Servidor WireGuard. Uma vez que tenha o software do cliente instalado, irá gerar um par de chaves pública e privada, decidir sobre um endereço IP ou endereços para o peer, definir um ficheiro de configuração para o peer e depois iniciar o túnel usando o script wg-quick.

Pode adicionar quantos pares desejar à sua VPN gerando um par de chaves e uma configuração usando os seguintes passos. Se adicionar vários pares à VPN, certifique-se de acompanhar os seus endereços IP privados para evitar colisões.

Para configurar o Peer do WireGuard, certifique-se de que tem o pacote WireGuard instalado utilizando os seguintes comandos apt. No Peer do WireGuard, execute:

sudo apt update

sudo apt install wireguard

Criar o Par de Chaves do Peer do WireGuard

De seguida, precisarás de gerar o par de chaves no peer usando os mesmos passos que usaste no servidor. A partir da tua máquina local ou servidor remoto que irá servir como peer, continua e cria 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

Mais uma vez, 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 é exibida, pois você precisará adicioná-la ao ficheiro de configuração do WireGuard mais tarde nesta secção.

De seguida, utilize o seguinte comando para criar o ficheiro da chave pública:

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

Voltará a receber uma linha única de saída codificada em base64, que é a chave pública para o seu Peer WireGuard. Copie-a para algum lugar para referência, uma vez que precisará de distribuir a chave pública ao Servidor WireGuard para estabelecer uma ligação encriptada.

Criar o Ficheiro de Configuração do Peer do WireGuard

Agora que tem um par de chaves, pode criar um ficheiro de configuração para o peer que contenha toda a informação necessária para estabelecer uma ligação ao servidor WireGuard.

Vai precisar de algumas informações para o ficheiro de configuração:

• A chave privada codificada em base64 que gerou no peer.
• Os intervalos de endereços IPv4 e IPv6 que definiu no servidor WireGuard.
• A chave pública codificada em base64 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 a sua máquina cliente tiver uma ligação à Internet por IPv6, pode usá-lo em vez do IPv4.

Com toda esta informação à mão, abra um novo ficheiro /etc/wireguard/wg0.conf na máquina Peer do WireGuard utilizando o nano ou o editor da sua preferência:

sudo nano /etc/wireguard/wg0.conf

Adicione as seguintes linhas ao ficheiro, substituindo os vários dados nas secçõ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

Repare como a primeira linha Address usa um endereço IPv4 da sub-rede 10.8.0.0/24 que escolheu anteriormente. Este 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 cada vez que adiciona um peer é geralmente a forma mais fácil de alocar IPs.

Da mesma forma, repare como a segunda linha Address utiliza um endereço IPv6 da sub-rede que gerou anteriormente, e incrementa o endereço do servidor em uma unidade. Mais uma vez, qualquer IP dentro do intervalo é válido se decidir usar um endereço diferente.

A outra parte notável do ficheiro é a última linha AllowedIPs. Estes dois intervalos IPv4 e IPv6 instruem o par a enviar tráfego pela VPN apenas se o sistema de destino tiver um endereço IP em qualquer um dos intervalos. Usando a diretiva AllowedIPs, pode restringir a VPN no par para se conectar apenas a outros pares e serviços na VPN, ou pode configurar a definição para encaminhar todo o tráfego pela VPN e usar o Servidor WireGuard como gateway.

Se estiver a usar apenas IPv4, então omita o intervalo final fd0d:86fa:c3bc::/64 (incluindo a vírgula ,). Por outro lado, se estiver a usar 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 quiser enviar todo o tráfego do seu par através da VPN e usar o Servidor WireGuard como uma gateway para todo o tráfego, então 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) Configurar um Par para Encaminhar Todo o Tráfego Através do Túnel

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

Para pares remotos aos quais acede via SSH ou outro protocolo utilizando um endereço IP público, será necessário adicionar algumas regras extra no ficheiro wg0.conf do par. Estas regras irão garantir que ainda consegue ligar-se ao sistema a partir do exterior do túnel quando este estiver ativo. Caso contrário, quando o túnel estiver estabelecido, todo o tráfego que normalmente seria gerido na interface de rede pública não será encaminhado corretamente para contornar a interface de túnel wg0, levando a que o sistema remoto fique inacessível.

Primeiro, terá de determinar o endereço IP que o sistema utiliza como porta de acesso predefinida. Execute o seguinte comando ip route:

ip route list table main default

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 seguintes.

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

ip -brief address show eth0

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 endereço IP destacado 203.0.113.5 (sem o /20 no final) é o endereço público atribuído ao dispositivo eth0 que precisará de adicionar à configuração do WireGuard.

Agora abra o ficheiro /etc/wireguard/wg0.conf do Peer WireGuard com o nano ou o 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]
. . .

Estas linhas irão criar uma regra de encaminhamento personalizada e adicionar uma rota personalizada para garantir que o tráfego público para o sistema utilize o gateway predefinido.

• PostUp=ip rule add table 200 from 203.0.113.5 - Este comando cria uma regra que verifica qualquer entrada de encaminhamento na tabela número 200 quando o IP corresponde ao endereço público 203.0.113.5 do sistema.
• PostUp=ip route add table 200 default via 203.0.113.1 - Este comando garante que qualquer tráfego a ser processado pela tabela 200 irá usar 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 estiver a encaminhar 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 Ajustar a Configuração de Rede do Servidor WireGuard e Configurar o Firewall do Servidor WireGuard.

(Opcional) Configuração dos Resolvedores DNS do Peer WireGuard

Se estiver a usar o Servidor WireGuard como uma gateway VPN para todo o tráfego dos seus peers, precisará de adicionar uma linha na secção [Interface] que especifique os resolutores DNS. Se não adicionar esta configuração, os seus pedidos DNS podem não estar protegidos pela VPN, ou poderão ser revelados ao seu Provedor de Serviços de Internet ou a outros terceiros.

Se estiver apenas a usar o WireGuard para aceder a recursos na rede VPN ou numa configuração ponto a ponto, pode ignorar esta secção.

Para adicionar resolutores DNS à configuração do seu par, primeiro determine quais servidores DNS o seu Servidor WireGuard está a utilizar. 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

Deverá 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 resolutores DNS que o servidor está a utilizar. Pode escolher usar alguns ou todos eles, ou apenas IPv4 ou IPv6, dependendo das suas necessidades. Faça uma anotação dos resolutores que irá usar.

De seguida, será necessário adicionar os resolvers escolhidos ao ficheiro de configuração do Peer do WireGuard. No Peer WireGuard, abra o ficheiro /etc/wireguard/wg0.conf usando nano ou o 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, pode editar a lista conforme as suas necessidades.

Global: 67.207.67.2 67.207.67.3
. . .

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

Passo 8 — Adicionar a Chave Pública do Par ao Servidor WireGuard

Antes de ligar o peer ao servidor, é importante adicionar a chave pública do peer ao Servidor WireGuard. Este passo garante que poderá ligar-se e encaminhar o tráfego através da VPN. Sem completar este passo, o servidor WireGuard não permitirá que o peer envie ou receba qualquer tráfego através do túnel.

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

sudo cat /etc/wireguard/public.key

PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg=

Agora, inicie sessão no servidor WireGuard e execute o seguinte comando:

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

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

Se desejar atualizar os allowed-ips de um peer existente, pode executar o mesmo comando novamente, mas alterando os endereços IP. São suportados múltiplos endereços IP. Por exemplo, para alterar o Peer do WireGuard que acabou de adicionar para adicionar um IP como 10.8.0.100 aos IPs existentes 10.8.0.2 e fd0d:86fa:c3bc::2, você executaria 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 par, verifique o estado 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

Repare como a linha peer mostra a chave pública do Peer do WireGuard, e os endereços IP, ou intervalos de endereços que lhe é permitido usar para atribuir a si próprio um IP.

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

Passo 9 — Ligar o par WireGuard ao túnel

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

Como poderá querer que a VPN esteja activa apenas para certos casos de utilização, vamos usar o comando wg-quick para estabelecer a ligação manualmente. Se desejar automatizar o início do túnel como fez no servidor, siga esses passos na secção Iniciar o Servidor WireGuard em vez de usar o comando wg-quick.

Caso esteja a encaminhar todo o tráfego através da VPN e tenha configurado o encaminhamento DNS, será necessário instalar a ferramenta resolvconf no Peer 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

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

Repare nos endereços IPv4 e IPv6 destacados que atribuiu ao par.

Se definir o AllowedIPs no peer para 0.0.0.0/0 e ::/0 (ou para usar intervalos diferentes dos que escolheu para a VPN), então a sua saída será semelhante à 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, repare nas rotas destacadas que o comando adicionou, as quais correspondem aos AllowedIPs na configuração do par.

Pode verificar o estado 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

Também pode verificar o estado no servidor novamente, e receberá uma saída semelhante.

Verifique se o seu par está a utilizar a VPN usando os comandos ip route e ip -6 route. Se estiver a usar a VPN como gateway para todo o seu tráfego de Internet, verifique qual a interface que será utilizada para o tráfego destinado aos resolvers 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

Repare que o dispositivo wg0 é utilizado e no endereço IPv4 10.8.0.2 que atribuiu ao peer. Da mesma forma, se estiver a usar 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

Note novamente a interface wg0 e o endereço IPv6 fd0d:86fa:c3bc::2 que atribuíram ao par.

Se o seu colega tiver um navegador instalado, também pode visitar ipleak.net e ipv6-test.com para confirmar que o seu colega está a encaminhar o seu tráfego através da VPN.

Quando estiver pronto para desligar a VPN no par, utilize o comando wg-quick:

sudo wg-quick down wg0

Receberá uma saída semelhante à seguinte, indicando que o túnel VPN está desligado:

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

Se definir o AllowedIPs no peer para 0.0.0.0/0 e ::/0 (ou para usar intervalos diferentes dos que escolheu para a VPN), então a 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 novamente o comando wg-quick up wg0 no peer. Se quiser remover completamente a configuração de um peer do Servidor WireGuard, pode executar o seguinte comando, certificando-se de substituir pela chave pública correta do peer que deseja remover:

sudo wg set wg0 peer PeURxj4Q75RaVhBKkRTpNsBPiPSGb5oQijgJsTa29hg= remove

Normalmente, só precisará remover a configuração de um par se o par deixar de existir ou se as suas chaves de encriptação forem comprometidas ou alteradas. Caso contrário, é melhor deixar a configuração no lugar para que o par possa reconectar-se à VPN sem ser necessário adicionar a sua chave e os allowed-ips cada vez.

Gerir e Rodar Chaves WireGuard

O WireGuard baseia-se em pares de chaves públicas e privadas estáticas para autenticação e encriptação. Este design reduz significativamente a complexidade da configuração, mas também coloca a responsabilidade pela gestão das chaves inteiramente sobre o administrador. Para implementações de VPN de longa duração, infraestruturas partilhadas ou ambientes com vários pares, uma gestão cuidadosa das chaves é essencial para manter a segurança e a estabilidade operacional.

Compreender os Tipos de Chaves do WireGuard

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

• Chaves privadas de longo prazo: Uma chave privada identifica de forma única um par e deve permanecer secreta em todos os momentos. Esta chave é utilizada durante os protocolos de handshake encriptados para autenticar o par e gerar chaves de sessão de curta duração. Se uma chave privada for exposta, qualquer sistema que detenha essa chave poderá representar o par de forma fraudulenta.

• Chaves públicas de longo prazo: Uma chave pública é derivada de uma chave privada e é partilhada com outros pares. No hub central, as chaves públicas determinam quais pares têm permissão para comunicar e quais endereços IP podem usar.

Além destas chaves de longo prazo, o WireGuard deriva automaticamente chaves de sessão efémeras durante os apertos de mão encriptados. Estas chaves de sessão são rotacionadas periodicamente e proporcionam Sigilo Perfeito para o Futuro sem a intervenção do administrador.

Práticas Recomendada de Gestão de Chaves

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

• Atribuir um par de chaves único a cada par: Cada dispositivo deve ter o seu próprio par de chaves privada e pública. Usar chaves únicas permite revogar o acesso a um único dispositivo sem afetar os outros. Reutilizar chaves em múltiplos sistemas aumenta o impacto de uma violação e complica a auditoria.

• Limitar o acesso ao material da chave privada: Os ficheiros de chave privada devem ser legíveis apenas pelo utilizador root. Em sistemas Linux, isto normalmente significa definir permissões para 600 utilizando um comando como chmod 600 /etc/wireguard/private.key. Restringir o acesso aos ficheiros ajuda a prevenir a divulgação acidental através de backups, logs ou utilizadores não privilegiados.

• Manter um inventário explícito de pares: Mantenha um registo 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. Esta documentação torna-se cada vez mais importante à medida que o número de pares aumenta e simplifica a resolução de problemas, auditorias e manutenção de rotina.

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

Situações que Exigem a Rotação de Chaves

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

• Exposição suspeita ou confirmada de chave: Se uma chave privada poderá ter sido copiada, divulgada ou acedida por uma parte não autorizada, deve ser imediatamente substituída para prevenir usurpação de identidade.

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

• Requisitos de segurança organizacionais: Alguns ambientes exigem a rotação periódica de chaves para cumprir políticas internas ou normas de conformidade, mesmo que não se suspeite de qualquer comprometimento.

• Mudanças na propriedade ou função do dispositivo: Quando um dispositivo é reassigned a outro utilizador ou finalidade, girar as suas chaves previne o acesso continuado não intencional.

Rodando com Segurança as Chaves de um Colega

O WireGuard associa endereços IP internos a chaves públicas específicas usando uma tabela de encaminhamento de chaves criptográficas. Devido a este design, o mesmo endereço IP interno não pode ser atribuído com segurança a duas chaves públicas ao mesmo tempo. A rotação de chaves envolve, por conseguinte, geralmente uma breve interrupção da conectividade enquanto a configuração é atualizada.

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

1. Gerar um novo par de chaves privada e pública no peer.
2. Atualize a configuração do par 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 ficheiro 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 utilizando wg syncconf. Neste ponto, o peer irá perder temporariamente a conectividade.
5. Reinicie a interface WireGuard no peer para que comece a usar a nova chave privada.
6. Verifique se uma nova ligação é estabelecida e se o tráfego flui corretamente.
7. Remova quaisquer referências restantes à chave antiga, caso ainda existam.

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

Rodar Chaves no Peer Central

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

Porque esta alteração afeta todos os pares simultaneamente, a rotação da chave central do par deve ser planeada cuidadosamente 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.

Gestão de Chaves Pré-Partilhadas (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 encriptação simétrica por cima da criptografia já existente do WireGuard.

As Chaves Pré-Partilhadas são normalmente utilizadas em ambientes de alta segurança como uma defesa contra futuros avanços criptográficos. Se o tráfego encriptado for gravado hoje e o algoritmo de chave pública subjacente for comprometido no futuro, uma PSK ainda impediria a descodificação das sessões passadas.

Se forem utilizados PSKs, estes devem ser tratados como segredos sensíveis e rotacionados periodicamente. A rotação de um PSK segue o mesmo padrão operativo da rotação de chaves de pares e deve ser coordenada em ambos os lados da ligação.

Escolher 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 partilhados ou de produção normalmente rotacionam as 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 implementaçõ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 abordam a encriptação, a configuração e o comportamento da rede de forma muito diferente. Compreender estas diferenças ajuda os desenvolvedores a escolher a solução que melhor se adapta às suas restrições operacionais.

Configuração e Modelo Operacional

O WireGuard utiliza um modelo de configuração estática baseado em pares de chaves públicas e privadas. Todos os pares são definidos de forma explícita, e o comportamento do encaminhamento é controlado através de valores de configuração fixos. Não existe canal de controlo, autoridade de certificação ou negociação dinâmica de parâmetros.

O OpenVPN baseia-se em TLS e certificados X.509. Utiliza um canal de controlo para autenticar clientes, negociar definições de encriptação e gerir sessões. Este 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 subtilmente complexos. As configurações do OpenVPN oferecem mais controlo, mas exigem uma gestão cuidadosa para permanecerem seguras e consistentes.

Criptografia e Design de Segurança

O WireGuard utiliza um conjunto fixo de métodos criptográficos modernos. Estas escolhas não são configuráveis. Este design elimina ataques de rebaixamento criptográfico e elimina a necessidade de selecionar conjuntos de cifragem.

O OpenVPN suporta uma ampla variedade de algoritmos de encriptação e métodos de autenticação. Embora esta flexibilidade permita a compatibilidade com sistemas antigos, 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 do seu mecanismo de handshake, enquanto o OpenVPN depende do comportamento da sessão TLS.

Características de Desempenho

O WireGuard foi concebido para alto desempenho e baixa latência. 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 proporciona maior débito e uma latência mais consistente com ajustes mínimos.

Historicamente, o OpenVPN funciona no espaço do utilizador e acarreta uma sobrecarga adicional devido às alterações de contexto e ao processamento de protocolos. As versões modernas do OpenVPN suportam a Descarregamento de Canal de Dados no Kernel (DCO), o que melhora significativamente o desempenho, mas esta funcionalidade nem sempre está ativada ou disponível nas implementações padrão.

Mesmo com DCO, o WireGuard normalmente alcança um desempenho elevado com menos variáveis de configuração.

Roaming de Rede e Atravessamento de Firewall

O WireGuard lida com alterações 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 a funcionar sem necessidade de renegociação.

No entanto, o WireGuard funciona exclusivamente sobre UDP. Embora o UDP seja eficiente, por vezes é bloqueado em redes WiFi públicas restritivas, firewalls corporativos ou redes institucionais. O WireGuard não tem uma alternativa nativa quando o tráfego UDP é bloqueado.

O OpenVPN suporta tanto UDP como TCP. Quando o UDP não está disponível, o OpenVPN pode ser configurado para funcionar através da porta TCP 443, fazendo com que o tráfego da VPN se pareça com o tráfego HTTPS normal. Esta capacidade torna o OpenVPN mais fiável em ambientes com regras de firewall rigorosas ou censura.

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

Âmbito das Funcionalidades e Extensibilidade

O OpenVPN inclui funcionalidades que o WireGuard intencionalmente não fornece. Estas incluem autenticação baseada em utilizador, atribuição dinâmica de endereços e integração com sistemas de identidade externos.

O WireGuard concentra-se exclusivamente em túneis seguros. Os fluxos de autenticação, o controlo de acesso e a configuração dinâmica devem ser tratados fora do protocolo.

Isto faz com que o OpenVPN seja mais adequado para ambientes que exigem autenticação complexa ou gestão centralizada de utilizadores, enquanto o WireGuard é mais indicado para VPNs a nível de infraestrutura e acesso entre pares.

Comparação Sumária

Escolher Entre WireGuard e OpenVPN

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

O OpenVPN continua a ser uma escolha sólida para ambientes empresariais que exigem tunelamento baseado em TCP, autenticação avançada ou operação fiável por detrás de firewalls restritivos.

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

Ajuste de Desempenho e Otimização

O WireGuard apresenta um bom desempenho com as suas configurações padrão, mas as condições reais da rede podem afetar a fiabilidade e a largura de banda. Fatores como o tamanho dos pacotes, o alcance do encaminhamento, o comportamento do NAT e a resolução de DNS influenciam todos o comportamento do túnel durante o uso contínuo ou intermitente.

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

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

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

Por predefinição, o WireGuard utiliza um MTU de 1420. Este valor considera a sobrecarga combinada dos cabeçalhos IPv6, UDP e da encapsulação do WireGuard e funciona bem na maioria das redes baseadas em Ethernet. Alguns ambientes exigem um MTU menor. Isto é comum em redes móveis, ligações PPPoE e plataformas cloud com camadas adicionais de encapsulação. Quando o MTU é demasiado grande, os pacotes podem ser perdidos ou fragmentados. Isto costuma resultar em ligações que funcionam para pedidos pequenos, mas travam ou falham em transferências maiores. Se surgirem estes sintomas, recomenda-se diminuir o MTU de forma gradual. Valores como 1360, ou em ambientes mais restritos 1280, que é o MTU mínimo do IPv6, resolvem frequentemente estes problemas com impacto mínimo na taxa de transferência.

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

Âmbito e Impacto de AllowedIPs

A diretiva AllowedIPs influencia tanto o comportamento de roteamento como o desempenho. Intervalos de endereços amplos fazem com que mais tráfego atravesse o túnel, o que aumenta a sobrecarga de encriptação e a carga no servidor. Utilizar valores estreitos de AllowedIPs limita o túnel apenas ao tráfego que necessita de proteção. Isto reduz o uso da CPU e evita encapsulamentos desnecessários.

Quando 0.0.0.0/0 ou ::/0 está configurado, todo o tráfego é encaminhado através da VPN. Esta configuração é apropriada quando a privacidade, o controlo 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 encaminhamento por túnel completo, a menos que seja necessário.

Travessia NAT e Estabilidade da Conexão (PersistentKeepalive)

O WireGuard permanece intencionalmente silencioso quando não há dados a ser transmitidos. Por defeito, não envia pacotes de manutenção periódicos. Em ambientes que utilizam NAT, como routers domésticos, redes móveis ou muitas redes na cloud, este silêncio pode fazer com que o dispositivo NAT feche o mapeamento da ligação. Quando isto acontece, o tráfego de entrada do servidor é bloqueado até que o peer envie tráfego novamente. Este comportamento é frequentemente percebido como atraso, ligações demoradas ou falhas intermitentes.

Para prevenir isto, o WireGuard fornece a definição PersistentKeepalive. Esta opção pode ser adicionada à secção [Peer] da configuração do peer. Faz com que o peer envie um pequeno pacote de manutenção a intervalos fixos para manter o mapeamento NAT aberto. Um valor de 25 segundos é normalmente utilizado e funciona bem com a maioria dos dispositivos NAT. Se uma ligação funcionar inicialmente, mas falhar após estar inativa, ativar PersistentKeepalive=25 é a principal e recomendada solução.

Resolução DNS e Comportamento do Túnel

A configuração de DNS tem um impacto significativo na perceção do desempenho da VPN. Quando os resolvers de DNS não são corretamente encaminhados através do túnel, as aplicações podem parecer lentas ou pouco fiáveis, mesmo quando o próprio túnel está a funcionar corretamente.

Nas configurações de gateway, as consultas DNS devem ser enviadas através da VPN para assegurar um encaminhamento consistente e evitar fugas. Isto requer definir explicitamente os resolutores DNS na configuração do par. Quando o DNS está mal configurado, os sintomas comuns incluem carregamento lento de páginas, conectividade inconsistente ou tráfego a ser encaminhado fora da VPN, apesar de o túnel estar ativo.

Selecionar resolvedores que sejam acessíveis através do túnel e respondam rapidamente melhora tanto a fiabilidade como a experiência do utilizador.

Diferenças de desempenho entre IPv4 e IPv6

Em ambientes de pilha dupla, o IPv4 e o IPv6 podem comportar-se de forma diferente. Os caminhos IPv6 podem ter diferentes limitações de MTU, políticas de encaminhamento 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 comportamento de encaminhamento e MTU para cada família de endereços.

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

Sobrecarga da CPU e de Criptografia

O WireGuard utiliza criptografia moderna que é eficiente na maioria dos sistemas. No entanto, a encriptação continua a consumir recursos de CPU.

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

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

A validar alterações de desempenho

A afinaçã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 da ligação com wg, medir a latência e a largura de banda antes e depois das alterações, e confirmar o comportamento do encaminhamento com ip route e ip -6 route. Esta abordagem minimiza riscos e simplifica a resolução de problemas.

Perguntas Frequentes

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

WireGuard é uma tecnologia moderna de VPN concebida para ser muito mais rápida e fácil de configurar do que opções antigas como OpenVPN ou IPsec. Pode considerá-la como um túnel seguro que liga directamente os seus dispositivos. Ao contrário das VPNs mais antigas, que são pesadas e complexas, o WireGuard é extremamente leve. No Ubuntu, funciona executando-se directamente dentro do kernel do Linux; o núcleo do sistema operativo. Porque corre profundamente no sistema em vez de ser uma aplicação separada por cima, usa muito pouca bateria e processa dados de forma incrivelmente rápida.

Para estabelecer uma ligação, o WireGuard usa um método muito semelhante ao SSH. Gera um par de “chaves” para cada dispositivo: uma chave privada (que permanece secreta no dispositivo) e uma chave pública (que partilha com os outros dispositivos com os quais pretende ligar-se). A ligação só acontece se as chaves coincidirem perfeitamente, tornando o handshake rápido e seguro.

2. O WireGuard é mais seguro do que o OpenVPN?

Para a maioria dos utilizadores, 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 tem mais de 100.000. Esta 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 os maus atores o façam.

O WireGuard também obriga-o a usar os padrões de encriptação mais recentes e fortes disponíveis atualmente. VPNs mais antigas permitem agilidade criptográfica, o que significa que podem retroceder para métodos de encriptação mais fracos para suportar dispositivos antigos. O WireGuard remove essa escolha, impedindo que atacantes enganem a sua VPN para usar uma encriptação mais fraca. Além disso, o WireGuard é furtivo por padrão; se um dispositivo não autorizado enviar um pacote para o seu servidor, o WireGuard simplesmente não responde. Isso torna o seu servidor invisível para hackers que estejam a procurar portas abertas.

3. Posso configurar o WireGuard no Ubuntu sem Docker?

Sim, pode configurá-lo facilmente diretamente no sistema sem usar contêineres Docker. De facto, executá-lo diretamente é muitas vezes o método preferido no Ubuntu porque o software está incluído nos repositórios de software padrão do Ubuntu. Normalmente, só precisa de executar os comandos de instalação padrão abaixo, que irão obter o software necessário diretamente da fonte oficial do Ubuntu.

sudo apt update
sudo apt install wireguard

4. Como posso adicionar múltiplos clientes (pares) ao WireGuard?

O WireGuard utiliza um conceito de ponto a ponto, o que significa que cada dispositivo a que se liga é tratado como um “par”. Para adicionar vários dispositivos, como um portátil, um smartphone e um tablet, basta editar o ficheiro de configuração do servidor (normalmente localizado em /etc/wireguard/wg0.conf).

Para cada novo dispositivo, deves adicionar um novo bloco de texto rotulado [Peer]. Dentro deste bloco, deves colar a Chave Pública desse dispositivo específico e atribuir-lhe um endereço IP interno único (como 10.0.0.2 para o primeiro dispositivo, 10.0.0.3 para o segundo, e assim sucessivamente). É crucial que estes endereços IP internos não se sobreponham.

Aqui está um bloco de configuração 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 é que o WireGuard utiliza?

O WireGuard utiliza por defeito a porta UDP 51820. Ele depende estritamente do protocolo UDP porque é mais rápido para tunelizar dados do que o TCP. O TCP requer uma confirmação para cada pacote de dados enviado, o que pode atrasar significativamente uma ligação VPN. O UDP apenas envia os dados sem esperar por uma confirmação, o que é perfeito para a natureza de alta velocidade do WireGuard. Ao configurar o firewall do Ubuntu (UFW), deve permitir especificamente o tráfego nesta porta UDP, caso contrário, os pedidos de ligação serão bloqueados antes de chegarem ao software VPN.

6. Como posso resolver problemas de ligação do WireGuard?

A resolução de problemas do WireGuard é geralmente simples porque há menos componentes em movimento. Se não conseguir ligar-se, deve seguir esta sequência específica de verificações:

Primeiro, verifique o estado da ligação executando sudo wg show no seu servidor. Se a ligação estiver saudável, verá uma linha a dizer latest handshake seguida de uma hora (por exemplo, “há 1 minuto”). Se esta linha estiver em falta, os dispositivos não estão a comunicar entre si. Isto é quase sempre causado por um firewall a bloquear a porta UDP ou por uma incompatibilidade nas chaves Públicas/Privadas.

Em segundo lugar, se a ligação for bem-sucedida mas não conseguir navegar na internet, o problema é provavelmente o encaminhamento de IP. É necessário garantir que o seu servidor Ubuntu tem permissão para encaminhar o tráfego da VPN para a internet. Pode verificar isto ao consultar o ficheiro /etc/sysctl.conf e assegurar-se de que a linha net.ipv4.ip_forward=1 está activa (não comentada).

7. O WireGuard suporta IPv6 no Ubuntu?

Sim, o WireGuard tem um excelente suporte para IPv6. É muito flexível e pode encapsular (envelopar) diferentes tipos de tráfego. Por exemplo, pode aceder a um website apenas com IPv4 através de uma ligação IPv6, ou vice-versa. Para ativar isto, basta incluir endereços IPv6 separados por vírgulas no seu ficheiro de configuração junto com os seus endereços IPv4 normais. Deve adicioná-los tanto ao campo Address (para o próprio IP do servidor) como ao campo AllowedIPs (para os IPs dos clientes).

8. Como posso ativar o WireGuard para iniciar automaticamente ao arrancar?

Para garantir que a sua VPN seja ligada automaticamente sempre que reiniciar o seu servidor Ubuntu, precisa de usar o systemd, que é o gestor de sistema para Linux. Deve usar o comando enable para instruir o sistema a procurar o seu ficheiro de configuração específico (por exemplo, wg0) e carregá-lo durante a sequência de arranque. Isto assegura que, se o seu servidor reiniciar devido a uma atualização, a sua ligação VPN voltará a estar ativa sem necessidade de a iniciar manualmente.

sudo systemctl enable wg-quick@wg0

Conclusão

Neste tutorial, configurou uma VPN WireGuard num servidor Ubuntu e ligou um par usando tanto IPv4 como IPv6. Durante o processo, configurou chaves, atribuiu endereços ao túnel e ativou o servidor para encaminhar tráfego de forma segura, proporcionando-lhe uma VPN funcional que é fácil de compreender 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 gerir chaves ao longo do tempo, lidar com IPv6 e redes em modo dual-stack, e melhorar a fiabilidade e o desempenho através da afinação do MTU, dos keepalives e das configurações de DNS. Com estes elementos em prática, deverá estar bem preparado para usar o WireGuard em ambientes reais ou adaptá-lo conforme as suas necessidades mudem.

Se quiser saber mais sobre o WireGuard, incluindo como configurar túneis mais avançados ou usar o WireGuard com contentores, visite a documentação oficial do WireGuard. Para mais tutoriais relacionados com a proteção dos seus sistemas Ubuntu, consulte os seguintes artigos:

• Como Configurar um Firewall com UFW no Ubuntu
• Fundamentos do UFW: Regras e Comandos Comuns de Firewall para a Segurança no Linux
• VPC vs VPN: Qual se Adequa Melhor às Suas Necessidades de Rede Segura?
• Como configurar e estabelecer um servidor OpenVPN no Ubuntu

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