WireGuard: duas meias rotas contra 0.0.0.0/0 no wg-quick

Dois prefixos /1 cobrem exatamente os mesmos endereços IPv4 que um único /0, e essa igualdade só vale dentro da lista de prefixos permitidos do peer. Deixa de valer no momento em que a ferramenta de configuração decide como encaminhar, porque o Linux wg-quick trata um prefixo padrão como caso especial e não como aritmética. O ramo especial instala uma tabela dedicada, duas regras de política, uma marca de socket e ajustes de caminho inverso que um par de meias rotas nunca recebe. Assim, quando um proxy ou um navegador deixa de funcionar após a edição, os prefixos são a parte menos interessante da mudança.

A lista de prefixos não é toda a configuração

AllowedIPs faz dois trabalhos ao mesmo tempo, e só um deles diz respeito à cobertura. Para o próprio WireGuard a lista é encaminhamento por chave criptográfica: decide quais destinos são cifrados na direção de um peer e quais endereços de origem esse peer pode usar. Para wg-quick a mesma lista também funciona como especificação de rotas, e a rota que produz depende de qual ramo a lista por acaso corresponde. Cobertura idêntica em duas formas de lista diferentes não diz, portanto, nada sobre um estado de host idêntico.

A configuração padrão tira essa decisão das suas mãos, porque Table é automática por padrão e a ferramenta escolhe onde as rotas caem. Outro gerenciador de rede, um invólucro de distribuição ou um valor Table personalizado voltam a mudar o resultado, e é por isso que um conselho escrito para um host pode parecer errado no seguinte.

O que o ramo padrão acrescenta além de uma rota

Uma entrada /0 envia o wg-quick para o caminho da rota padrão: uma tabela de encaminhamento separada recebe a rota padrão, uma regra de política manda para lá o tráfego sem marca, uma segunda regra mantém as rotas mais específicas da tabela principal como autoritativas, e a interface recebe uma marca de firewall no seu próprio socket. Essa marca é o guardião do laço. Os datagramas cifrados que carregam o tráfego do túnel saem com a marca definida, para que a regra que dirige todo o resto ao túnel não engula os pacotes de transporte do próprio túnel.

Um par de entradas /1 segue, em vez disso, o caminho de rota comum. Duas rotas caem na tabela configurada, e nada da maquinaria ao redor aparece, não porque seja desnecessária, mas porque esse caminho de código nunca foi percorrido.

Onde os dois arranjos divergem

A divergência aparece primeiro como recursão. Com as meias rotas na tabela principal, o endereço de transporte do próprio peer cai dentro de um prefixo do túnel, então o pacote que deveria carregar o túnel coincide com uma rota que aponta para dentro do túnel. Algo tem de isentá-lo: uma rota de host para o endpoint atual, uma marca aplicada à mão ou uma regra específica da interface. Uma rota de host funciona até o endereço do endpoint mudar, o que acontece com endpoints baseados em DNS, clientes itinerantes e configurações com vários peers.

Em segundo lugar, tudo o que raciocina sobre marcas muda de comportamento. Um proxy transparente que redireciona conexões localmente cria sockets novos cujas marcas e origens diferem do fluxo original do cliente, e as regras de política geradas pelo ramo padrão faziam parte do que separou esses fluxos. Ler a conexão de saída do próprio proxy é um exercício diferente de testar se o destino original é alcançável.

Leia as regras e as marcas antes de editar

Capture o estado atual enquanto o túnel está saudável e de novo depois da mudança, e compare os dois despejos em vez de raciocinar a partir do ficheiro de configuração. Inclua as regras de política, todas as tabelas, a marca da interface e os endpoints registados.

ip rule show
ip -4 route show table all | grep -E 'default|wg1'
wg show wg1 fwmark
wg show wg1 endpoints

Se a primeira linha da saída perdeu a regra do tráfego sem marca e a tabela dedicada está vazia, o ramo padrão não está em execução e nenhuma aritmética de prefixos restaurará os seus efeitos. Uma marca zero numa interface que antes levava uma é o mesmo sinal, visível num único valor.

Ensaiad a perda do túnel antes de implementar

Se a disposição de meias rotas é a escolha deliberada, tem de fornecer explicitamente as peças em falta: um caminho de endpoint que sobreviva a mudanças de endereço, o comportamento pretendido quando o túnel cai e o tratamento equivalente para IPv6. Escrevei isso como requisitos em vez de o descobrir durante uma falha. Depois ensaiad a falha, porque um túnel completo que recai silenciosamente sobre a ligação física é pior do que um que deixa de funcionar.

sudo ip -4 route add 198.51.100.20/32 via 192.0.2.1 dev eth0
ip -4 route get 198.51.100.20
sudo wg-quick down wg1

A consulta de rota deveria resolver o endpoint pela interface física sem atravessar o túnel, e baixar a interface deveria deixar o host no estado que o desenho prometeu. Um proxy que funciona após a substituição prova que o estado de host gerado importava; não prova que a prevenção de laços e o comportamento em estado desligado sobreviveram à edição.