Dois peers do WireGuard partilham um intervalo: qual recebe o pacote

Dois peers listam intervalos que se tocam, e o tráfego chega ao errado. Nada está corrompido: o WireGuard escolhe um peer fazendo corresponder o destino aos intervalos configurados, e vence a correspondência mais específica. Antes de alargar o que quer que seja, decida qual peer deve possuir qual prefixo.

O prefixo mais longo vence dentro do WireGuard

Cada entrada de peer transporta um conjunto de prefixos de destino. Quando um pacote é encaminhado para a interface, a implementação procura a entrada com o prefixo correspondente mais específico — a mesma regra que uma tabela de encaminhamento aplica. Por isso, um /24 vence um /16 que o contenha, e o peer mais estreito recebe o tráfego.

As configurações road-warrior usam isto deliberadamente. Um peer possui um intervalo amplo para um site, e anfitriões individuais são recortados com entradas /32 que pertencem a outros peers. O padrão funciona porque os recortes são mais específicos, não por causa da ordem.

Registe a propriedade como uma tabela de prefixo e peer. Se duas entradas descrevem o mesmo prefixo, a configuração já não exprime uma intenção, exprime uma corrida.

O sistema operativo escolhe primeiro a interface

O WireGuard só escolhe entre os peers de uma interface. Qual interface recebe o pacote é decidido mais cedo, pela tabela de encaminhamento do anfitrião, e uma segunda rota predefinida ou uma rota obsoleta pode enviar o tráfego para um local que a lista de peers nunca vê. É por isso que um diagnóstico ao nível do peer pode estar correto e ainda assim não explicar a falha. Verifique a rota para o destino antes de ler a configuração do peer, porque uma rota que aponta para a interface física contorna toda a questão.

A ferramenta instala normalmente essas rotas a partir dos intervalos dos peers, o que significa que uma alteração na lista de um peer pode redirecionar silenciosamente tráfego que antes pertencia a outro. Editar um peer é, portanto, uma alteração de encaminhamento disfarçada. Reveja ambos ao mesmo tempo, ou vai reparar um e quebrar o outro.

Os pacotes recebidos são verificados pela origem

A lista de intervalos desempenha uma dupla função. Para o tráfego de saída escolhe um peer pelo destino, e para o tráfego de entrada autoriza um endereço de origem. Um pacote que chega de um endereço fora dos intervalos desse peer é descartado antes de qualquer firewall o ver.

Essa assimetria é fácil de ignorar quando se lê um lado da configuração. Um peer que consegue alcançar uma sub-rede não fica por isso autorizado a enviar a partir dessa sub-rede, e as duas direções são impostas por verificações diferentes.

Uma propriedade de origem estreita transforma isto numa vantagem. Dê a cada peer um /32 para o seu próprio endereço e a firewall a jusante tem uma origem fiável para comparar, em vez de um intervalo de todo o grupo que qualquer membro poderia reclamar.

Intervalos duplicados não são failover

Atribuir o mesmo prefixo a dois peers não cria um balanceador de carga nem um caminho de reserva. Não há verificação de estado nem afinidade de sessão: a entrada vencedora é decidida pela ordenação interna da implementação, que não é um contrato sobre o qual deva desenhar. Se precisar de saídas alternativas, exprima-as onde a seleção está definida. Uma política de encaminhamento, uma métrica ou um par de prefixos distintos com um proprietário documentado cada produzem um comportamento que pode prever e testar.

Alargar um intervalo para corrigir uma falha não relacionada é o outro erro comum. Afasta o tráfego do peer que estava a funcionar, e o novo sintoma chega antes de o antigo ser compreendido.

Verifique a seleção antes de editar

Três comandos respondem às três perguntas por ordem. O primeiro lista os intervalos que cada peer reclama. O segundo mostra qual interface o anfitrião usaria para um destino. O terceiro mostra o estado em direto dos peers depois de o tráfego ter fluído.

wg show wg0 allowed-ips
ip route get 10.66.8.20
wg show wg0
ip rule show

Execute-os antes e depois de uma alteração e compare. Se a saída da rota mudou mas o tráfego continua a chegar ao peer errado, as listas de prefixos sobrepõem-se de uma forma que ainda não registou. Se a saída da rota não mudou, a configuração do peer nunca foi o que estava a ser consultado.

Registe no ticket o destino, a interface escolhida e o peer escolhido. É esse trio que torna uma sobreposição verificável mais tarde, e é muito mais útil do que uma captura de ecrã da configuração.