Marcas do nftables e roteamento VPN: qual regra realmente vence

Uma marca definida no nftables deve enviar uma classe de tráfego pelo túnel, e o tráfego continua saindo pela interface física. O conjunto de regras parece correto isoladamente. O que costuma ter acontecido é que outra coisa escreveu a mesma marca, ou que a regra de roteamento corresponde a uma máscara que o novo valor já não satisfaz.

Verificação 1: leia a regra com que o núcleo corresponde

Comece pela regra de política e não pelo firewall. O núcleo consulta as regras por ordem de prioridade e a primeira correspondência decide a tabela. Leia o valor de fwmark e a máscara da própria regra e depois confirme que um pacote com a marca que definiu corresponde realmente a ela. Uma regra que espera um valor completo de 32 bits não corresponderá a um pacote que carrega apenas um bit.

Depois confirme qual tabela essa regra seleciona e o que a tabela contém. Uma regra que aponta para uma tabela vazia produz uma falha de procura, o que em muitos sistemas significa que o pacote cai para a regra seguinte e sai pela interface física.

Dois comandos resolvem isso: a lista de regras e a procura de rota para o destino nessa tabela.

Verificação 2: marca de pacote ou marca de conexão

O nftables pode definir uma marca no pacote e uma marca no registo de seguimento de conexões, e são objetos diferentes. A marca de pacote vive durante a passagem de processamento do pacote, enquanto a marca de conexão persiste para o fluxo e tem de ser copiada deliberadamente. Definir uma e esperar a outra é uma meia correção comum.

Se a regra de roteamento se baseia na marca de pacote, restaurar a marca de conexão mais adiante no caminho não faz nada para essa decisão, porque a decisão já foi tomada.

Decida qual objeto detém o sinal de roteamento e depois defina-o no ponto em que a decisão de roteamento é tomada.

Verificação 3: quem mais escreve essa marca

As próprias ferramentas do WireGuard marcam os seus pacotes UDP para que o transporte cifrado não seja encaminhado de volta para o túnel a que pertence. Se o seu conjunto de regras atribuir um valor não relacionado ao mesmo campo, essa exclusão desaparece e o tráfego externo do túnel tenta entrar em si mesmo. O sintoma é um túnel que se estabelece e depois deixa de passar tráfego.

As marcas também são usadas por outras ferramentas de firewall, pela rede de contentores e pelo roteamento por políticas para outros fins, por isso dois subsistemas a escrever todo o campo é um conflito mesmo quando cada um está correto isoladamente.

Enumere os escritores antes de acrescentar mais um.

Verificação 4: a máscara decide o que conserva

Uma marca é um campo de 32 bits, e as máscaras são a forma como vários proprietários o partilham. Definir um valor com máscara preserva os bits que não possui; definir todo o campo destrói os de todos os outros. Leia a máscara em cada regra que toque no campo, incluindo as que não escreveu.

Documente a atribuição de bits ao lado do conjunto de regras.

Caso contrário, a pessoa seguinte reutilizará um valor que já tem proprietário, e um conflito aqui parece um erro de roteamento quando na verdade é um erro de endereçamento. A documentação do nftables sobre metadados de pacotes descreve as próprias operações de marca.

Verificação 5: verifique com um fluxo real, não com uma procura

Uma procura de rota simples não transporta marca, por isso pode mostrar um caminho diferente do pacote real. Gere o tráfego que lhe interessa e observe os contadores, o registo de seguimento de conexões e a interface por onde ele sai realmente. Teste tanto a classe incluída como a classe excluída, porque uma marca demasiado ampla quebra a exclusão ao mesmo tempo que parece bem-sucedida. Se a classe incluída funcionar e a classe excluída também entrar no túnel, a marca é demasiado ampla e não demasiado estreita.

Evite limpar o estado das conexões para forçar uma atualização durante uma sessão ativa, dado que os fluxos novos e existentes podem legalmente seguir caminhos diferentes.

Registe a marca, a máscara e a tabela num só lugar, e a próxima edição torna-se verificável.