AllowedIPs é uma lista de encaminhamento, não uma regra de firewall

A maioria das pessoas lê AllowedIPs como uma lista de permissões, o conjunto de endereços que podem ligar-se a um par, mais ou menos como uma regra de firewall escrita para um túnel. Não é isso. O campo é uma tabela de encaminhamento que funciona em ambas as direções: escolhe um par para um pacote de saída e valida a origem de um pacote de entrada. Lê-lo como lista de acesso produz configurações que encaminham tráfego que ninguém pediu.

Um campo, dois leitores: escolha de saída e verificação de origem

No cliente, os prefixos decidem quais destinos viajam para esse par e quais ficam na rede comum. Por isso uma entrada para 0.0.0.0/0 captura todos os destinos IPv4, e por isso importar um perfil de túnel completo envia a navegação comum pela máquina remota. As entradas estreitas fazem o contrário: encaminham apenas as redes que listou e deixam todo o resto onde estava. A secção sobre encaminhamento de criptochaves da documentação do WireGuard expõe as duas tarefas num só lugar: a seleção do par de saída e a validação da origem de entrada.

No servidor, o mesmo campo descreve que endereços de origem cada par pode usar. É uma verificação criptográfica e não um filtro de pacotes: um pacote cuja origem interna não coincida com a lista do par é descartado dentro do WireGuard antes de qualquer firewall do anfitrião o ver. As duas tarefas partilham uma só lista, e por isso exatamente uma lista copiada de outro lugar se comporta mal num ponto que não considerou.

O bloco do cliente é onde começa a maior parte desta confusão. Um túnel dividido nomeia as redes remotas, e um túnel completo é o mesmo campo com um prefixo predefinido:

[Peer]
# split tunnel: only these networks
AllowedIPs = 10.77.0.0/24, 192.168.30.0/24

[Peer]
# full tunnel: everything, both families
AllowedIPs = 0.0.0.0/0, ::/0

Ambas as formas são completas por si mesmas, e são alternativas e não passos. A primeira envia apenas essas duas redes pelo túnel; a segunda envia todos os destinos, com a entrada ::/0 a acrescentar IPv6 ao valor predefinido IPv4. Escolha a que escolher, esses prefixos são toda a decisão de encaminhamento para esse par assim que o wg-quick começa a instalar rotas.

O concentrador precisa de outra lista

Um concentrador lista o endereço de túnel de cada cliente como prefixo de anfitrião, mais qualquer rede que esteja realmente atrás desse cliente. Copiar a lista ampla de um cliente para cada par do concentrador diz ao concentrador que muitos pares podem usar os mesmos endereços como origem, e isso não é um plano de endereçamento. O campo Endpoint pertence a outra camada por completo: nomeia o endereço e a porta exteriores do par, nunca um destino dentro do túnel.

[Peer]
# laptop: tunnel address 10.77.0.2, office LAN behind it
AllowedIPs = 10.77.0.2/32, 192.168.30.0/24

O prefixo de anfitrião transporta o endereço do túnel e o prefixo de rede transporta o que está atrás do cliente, e ambos são necessários. Sem o prefixo de anfitrião o concentrador não pode devolver o tráfego do próprio cliente, e sem o prefixo de rede a LAN atrás fica inalcançável; um par sem nada atrás recebe apenas o prefixo de anfitrião.

Saltar a instalação de rotas deixa uma lacuna

O wg-quick, o auxiliar que levanta uma interface a partir de um ficheiro de configuração, instala endereços de interface e rotas como parte desse trabalho. Definir Table = off diz ao auxiliar para saltar o trabalho das rotas, o que não instala substitutos e não torna a rede privada alcançável. Quando as rotas automáticas já fazem o trabalho, nomear os prefixos de que precisa é a configuração mais clara. Desativar a gestão de rotas e deixar o substituto por escrever não é um desenho, é uma omissão.

A ferramenta base wg comporta-se de forma diferente: configura a interface e nunca toca nas rotas, por isso uma instalação construída diretamente sobre ela precisa dos seus próprios comandos de rota. Instruções escritas para uma ferramenta podem parecer erradas quando seguidas com a outra. Um ping bem-sucedido também é evidência fraca, porque exercita um só caminho em vez de todos os caminhos de aplicação de que precisa.

DNS e IPv6 decidem-se separadamente

Verifique o endereço do servidor DNS anunciado pelo túnel e confirme que existe uma rota para esse endereço através dos prefixos escolhidos. Uma definição do resolver não torna o resolver alcançável, e estreitar um túnel pode remover silenciosamente a rota que lá chegava. Inspecione também o IPv6 por si só, porque uma divisão IPv4 correta não diz nada sobre uma rota predefinida IPv6 que ainda aponta para a ligação física. Três decisões separadas podem mudar ao mesmo tempo quando edita um único bloco de par.

Depois abra um recurso privado e um site comum a partir de uma configuração inicial conhecida. Se o recurso responder e a navegação continuar a sair pela ligação local, a divisão faz o que pediu. Se a navegação quebrar no mesmo momento, o túnel tomou a rota predefinida e a lista de prefixos é o ponto onde olhar.