Prefixo de anfitrião no WireGuard: porque é que um endereço funciona e os restantes não

O túnel está de pé, o handshake acontece a cada dois minutos, e exatamente um endereço do outro lado responde. Os pings para o endereço do túnel do par funcionam; nada atrás dele funciona. Alguém lê a configuração da interface, vê um prefixo de anfitrião e conclui que a máscara está errada. Alargá-la para um /24 resolve o ping durante algum tempo e depois quebra outra coisa. O prefixo nunca foi o problema, e a rota que faltava não é a que a máscara controla.

O que o prefixo da interface cria realmente

No Linux, atribuir um endereço a uma interface cria uma rota conectada para esse prefixo. Se atribuir um prefixo de anfitrião, a rota conectada cobre um endereço. Se atribuir um /24, cobre 256, e cada um deles passa a ser considerado alcançável por essa ligação.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

Um prefixo de anfitrião é uma escolha completamente normal para um túnel ponto a ponto, porque existe exatamente um par do outro lado. O terceiro comando é o que responde à pergunta do utilizador: diz qual interface o kernel usaria para esse destino, e não mostra nada de útil se nenhuma rota corresponder.

É toda a explicação do sintoma. Um endereço responde porque existe uma rota conectada para ele, ou porque a lista permitida do par, por acaso, o inclui. Tudo o resto não tem rota e é descartado antes de o WireGuard ser envolvido. O túnel está saudável durante todo o tempo, e é por isso que o contador de handshakes continua a parecer tranquilizador.

AllowedIPs são duas regras com um só nome

A lista permitida por par do WireGuard faz dois trabalhos ao mesmo tempo, e a sintaxe de configuração faz com que pareçam um. À entrada, autoriza que endereços de origem um par pode apresentar. À saída, seleciona para que par um pacote é enviado, ao encontrar a correspondência mais específica.

Nenhum dos dois trabalhos é encaminhamento. O kernel ainda tem de decidir que um pacote pertence à interface do túnel antes de o WireGuard olhar para ele, e essa decisão vem da tabela de rotas. Uma entrada de par com uma lista permitida ampla não instala uma rota por si só.

É por isso que uma configuração pode parecer completa e comportar-se de forma assimétrica. O cliente envia para o outro extremo porque existe uma rota, e as respostas nunca chegam porque a lista permitida do outro extremo não autoriza a origem do cliente, ou porque o outro extremo não tem caminho de volta. Ambas as direções são decisões separadas com modos de falha separados. Anotar qual está a testar é metade do diagnóstico.

De onde vem a rota

Se usar o wg-quick, as rotas são geradas por si a partir da lista permitida de cada par, a menos que tenha definido Table = off e assumido o controlo. É esse o comportamento que a ferramenta documenta, e é a razão pela qual uma configuração sem diretivas de rota explícitas continua a funcionar.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Compare a lista permitida com as rotas que existem de facto. Um par que permite uma sub-rede inteira mas produziu apenas uma rota de anfitrião significa que o auxiliar nunca correu, ou que está a gerir a interface diretamente com wg e ip, e nesse caso nada está a gerar rotas por si.

Quando o gere à mão, a rota é uma linha e a sua forma é explícita: o destino através da interface, sem gateway porque a ligação é ponto a ponto. Acrescentá-la não é uma solução de recurso para um prefixo mau; é a metade que faltava de um desenho que decidiu assumir o encaminhamento.

Alargar o prefixo não acrescenta a entrada do par

A correção tentadora é mudar o endereço para um /24 para que a rota conectada cubra a LAN do servidor. Parece funcionar, e a razão pela qual parece funcionar é que a rota conectada agora corresponde, não que o WireGuard tenha aprendido algo novo.

O que também fez foi reivindicar todo o intervalo como diretamente alcançável por essa ligação, incluindo endereços que pertencem a outros pares ou a uma LAN que está de facto atrás do servidor. O tráfego para esses endereços entra agora no túnel, e se sai do outro lado depende do encaminhamento e das listas permitidas do próprio servidor.

O lado criptográfico não é afetado de qualquer forma. O WireGuard continua a precisar de uma entrada na lista permitida que cubra o destino para escolher um par, e o outro extremo continua a precisar de uma entrada que cubra a sua origem para a aceitar. Um prefixo de interface mais amplo não consegue fornecer nenhuma delas.

Confirme ambas as direções antes de mudar alguma coisa

Trabalhe os dois extremos em separado e anote o que cada um diz. No cliente, a rota e a entrada do par; no servidor, a imagem espelhada mais o seu próprio caminho de volta:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

A captura é o que resolve as discussões sobre a direção. Se os pacotes de saída aparecem na interface do túnel e o servidor não regista nada, o extremo remoto está a rejeitá-los, normalmente porque a sua origem está fora da lista permitida dele. Se não aparecer nada de todo, falta a rota ou aponta para outro sítio.

Depois corrija o extremo mais estreito. Uma entrada na lista permitida do lado do servidor para o endereço do seu cliente e uma entrada do lado do cliente para a sub-rede de destino é a forma normal, e deixa o prefixo da interface em paz. Só alargue o prefixo se o plano de endereçamento quiser realmente uma sub-rede partilhada nessa ligação, e faça-o como uma alteração de plano em vez de um passo de depuração.