WireGuard AllowedIPs: um campo que faz dois trabalhos (e porque o seu está errado)

Quase todos os problemas de configuração do WireGuard que sobrevivem a um handshake bem-sucedido resumem-se a um único campo, e ao facto de quase ninguém o ler corretamente. AllowedIPs parece uma diretiva de encaminhamento. É isso, e é outra coisa ao mesmo tempo.

O que o manual diz realmente

O manual do wg define-o numa frase que vale a pena ler devagar:

a comma-separated list of IP (v4 or v6) addresses with CIDR masks from which incoming traffic for this peer is allowed and to which outgoing traffic for this peer is directed

Duas orações, dois trabalhos diferentes. Saída: os pacotes cujo destino cai nessa lista são enviados para esse par. É a metade de encaminhamento, a que toda a gente conhece. Entrada: os pacotes que chegam desse par só são aceites se o seu endereço de origem cair na mesma lista. É uma lista de controlo de acesso, e é a metade que se ignora.

É a isto que o WireGuard chama cryptokey routing: a associação entre uma chave pública e um conjunto de endereços constitui todo o modelo de autorização. Não existe nenhuma regra de firewall separada a decidir que par pode reclamar que endereço.

A consequência que ninguém prevê

Ponha AllowedIPs = 0.0.0.0/0 num par e não encaminhou apenas todo o seu tráfego para ele. Declarou também que esse par lhe pode enviar um pacote que diga vir de qualquer endereço de origem da internet, e a sua interface aceita-o.

Num cliente cujo único par é o seu próprio servidor, é exatamente o que quer e é a configuração normal de túnel completo. Num servidor com vários pares, ou em qualquer máquina onde um par não seja de plena confiança, é um buraco aberto sem dar por isso.

Grande plano a preto e branco de caixas de correio metálicas numeradas, com os números 31 a 40 escritos à mão em pequenas etiquetas. Cada caixa tem exatamente um número e nenhum se repete: é a restrição que o AllowedIPs impõe entre pares.

Porque dois pares nunca podem partilhar um intervalo

Como a lista decide para que par um destino é enviado, o mesmo endereço não pode pertencer a dois pares ao mesmo tempo: a correspondência tem de ser inequívoca. Na prática é por isso que, do lado do servidor, cada cliente recebe o seu próprio /32 (ou /128 em IPv6) em vez da sub-rede inteira.

A assimetria surpreende. No cliente, AllowedIPs descreve o que quer alcançar através do túnel, muitas vezes tudo. No servidor, descreve quem esse par concreto tem direito a ser, normalmente um único endereço. O mesmo campo, lido de duas pontas, significa duas coisas diferentes.

O problema de excluir a rede local, e porque a subtração não existe

A pergunta real mais frequente é "como encaminho tudo menos a minha rede local". Não existe sintaxe de subtração. 0.0.0.0/0 menos 192.168.1.0/24 não se consegue exprimir, porque o campo é uma lista de intervalos e nada mais.

A resposta é enumerar o complemento: em vez de um curinga, lista os blocos CIDR que juntos cobrem todo o espaço de endereçamento exceto o intervalo que quer manter local. É ingrato, produz uma linha longa, e é a única forma correta. Os curingas estão documentados sem ambiguidade: 0.0.0.0/0 corresponde a todos os endereços IPv4 e ::/0 a todos os IPv6.

O sintoma que leva até aqui

Um handshake que se completa, e depois nada. O wg show mostra um handshake recente, os pares encontraram-se claramente, e não passa tráfego. Quando o handshake funciona, as chaves e o extremo estão corretos por definição: o problema está a jusante, e AllowedIPs é o primeiro sítio onde olhar. Ou o destino não está na lista do lado que envia, ou a origem não é aceite do lado que recebe.

Se for o próprio handshake a nunca se completar, o diagnóstico é outro e o nosso guia de resolução de problemas de handshake trata disso. E se os pacotes circulam mas as páginas ficam a meio, tem provavelmente um problema de MTU e não com este campo.

Não confundir com PersistentKeepalive

Confundem-se porque ambos aparecem na secção do par e ambos parecem tratar de "manter a ligação viva". Não têm relação. O manual descreve PersistentKeepalive como um intervalo, entre 1 e 65535 segundos, que regula de quanto em quanto tempo é enviado ao par um pacote vazio autenticado, para manter válida uma entrada de firewall com estado ou de NAT. Está desativado por omissão, e o manual acrescenta que a maioria dos utilizadores não vai precisar dele.

AllowedIPs decide o que é permitido. PersistentKeepalive decide com que frequência bate à porta para que uma caixa NAT não se esqueça de que existe.

Fazê-lo bem à primeira

Configure as entradas de par no servidor com um endereço por cliente e nada mais. Configure o cliente com os intervalos que realmente quer alcançar: os curingas para um túnel completo, as sub-redes concretas para um túnel dividido. Leia cada linha AllowedIPs duas vezes: uma como rota, outra como lista de convidados. Os nossos modelos de configuração prontos a usar aplicam essa separação.

O campo é pequeno, aceita quase tudo o que escrever, e falha em silêncio quando está errado. É essa combinação que lhe merece mais atenção do que costuma receber.

★ Datacenter GDPR em Nuremberg · ✓ IPv4 dedicado incluído · 200+ Mbps garantidos

Aloje a sua VPN no seu próprio VPS → ContaboAcesso root completo · IPv4 público · escolha a sua região→

Perguntas frequentes

Para que serve o AllowedIPs no WireGuard?

Faz duas coisas ao mesmo tempo. O manual do wg define-o como a lista de endereços de onde o tráfego de entrada desse par é permitido, e para onde o tráfego de saída destinado a esse par é dirigido. É portanto ao mesmo tempo uma regra de encaminhamento para o que envia e uma lista de controlo de acesso para o que aceita. A maioria dos erros vem de ler apenas a primeira metade.

Porque é que o meu handshake funciona e não passa tráfego?

Porque o handshake só prova que as chaves e o extremo estão corretos. O que acontece aos pacotes a seguir é decidido pelo AllowedIPs. Ou o destino que tenta alcançar não está listado do lado que envia e nada entra no túnel, ou o endereço de origem não está listado do lado que recebe e o pacote é descartado à chegada.

Dois pares podem ter o mesmo AllowedIPs?

Não, e a razão é estrutural e não uma regra de arrumação. Como a lista decide para que par um dado destino é enviado, um endereço pertencente a dois pares tornaria a escolha ambígua. Por isso cada cliente recebe normalmente o seu próprio /32 do lado do servidor em vez da sub-rede inteira.

Como excluo a minha rede local do túnel?

Enumerando o complemento, porque o campo não tem sintaxe de subtração. Em vez de um curinga, lista os blocos CIDR que juntos cobrem todo o espaço de endereçamento exceto o intervalo que quer manter local. O resultado é uma linha longa e é a única forma correta de o exprimir.

Qual é a diferença entre AllowedIPs e PersistentKeepalive?

Resolvem problemas sem relação. O AllowedIPs decide que tráfego é permitido em cada sentido. O PersistentKeepalive é um intervalo, entre 1 e 65535 segundos, que regula de quanto em quanto tempo é enviado um pacote vazio autenticado para que uma entrada de firewall com estado ou de NAT continue válida. Está desativado por omissão e o manual nota que a maioria não vai precisar dele.