Por que o nftables não vê o tráfego entre clientes do OpenVPN

Dois clientes no mesmo servidor trocam ficheiros, a transferência tem sucesso e cada regra de encaminhamento que aponta para o túnel relata zero pacotes. As regras não estão quebradas e a cadeia não está no lugar errado. Com o encaminhamento entre pares ativado, o pacote é entregue dentro do processo do servidor e a pilha do anfitrião nunca se torna o encaminhador, pelo que a firewall do kernel não tem nada para contar. Compreender essa separação decide se mantém o atalho ou reconstrói o caminho através do kernel.

Siga um pacote através do servidor

Num túnel encaminhado, o daemon entrega o pacote desencriptado de cada cliente ao dispositivo de túnel. A partir daí o anfitrião encaminha-o, o gancho de encaminhamento corre e uma regra que corresponda ao dispositivo de túnel pode contar ou descartar o tráfego. Esse é o caminho que a maioria dos exemplos de firewall assume.

O atalho retira o anfitrião do meio. O pacote desencriptado de uma sessão é entregue a outra sessão dentro do daemon, e o pacote interno nunca é emitido no dispositivo de túnel nem encaminhado pelo anfitrião. O tráfego encapsulado continua a atravessar a interface física, por isso uma captura externa parece ocupada enquanto as regras internas ficam em silêncio. Uma captura feita no dispositivo de túnel não mostra absolutamente nada, o que surpreende quem espera ver ali a transferência. Essa assimetria é a forma mais rápida de reconhecer o atalho fora do daemon.

O teste do contador que decide qual caminho foi usado

Anexe um contador à regra que deveria aplicar-se, execute uma transferência entre dois clientes que essa regra deveria bloquear e leia o contador depois.

sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forward

Se a transferência tiver sucesso e o contador ficar em zero, o kernel nunca tratou esses pacotes, e nenhuma edição de regras o mudará. Repita o mesmo teste contra um serviço no próprio servidor, porque esse fluxo atravessa mesmo a pilha do anfitrião e o seu contador mexe-se. É a comparação dos dois resultados que produz a resposta.

Dois detalhes evitam uma leitura falsa. Um nome de interface escrito numa etiqueta de cadeia não filtra nada por si só, porque a correspondência acontece nos campos de interface dentro das regras. E um desenho em ponte de camada 2 comporta-se de forma diferente: ali os clientes partilham um domínio de difusão, pelo que a descoberta de pares é esperada e não uma falha de encaminhamento.

Um comutador não é uma lista de acesso

Esta é a parte que custa uma tarde. O encaminhamento entre pares é um único ajuste ligado ou desligado, e enquanto está ligado o daemon é o único ponto de encaminhamento. A firewall do anfitrião não consegue exprimir quem pode chegar a quem, e ficheiros por cliente não transformam o comutador numa matriz de políticas.

Se precisa de regras por par, a escolha é entre abdicar do atalho e abdicar da firewall do anfitrião como controlo. Desligá-lo restaura o encaminhamento do kernel, o que exige encaminhamento IP no servidor e regras explícitas para os fluxos desejados. Mantê-lo ligado significa que a política vive na configuração do daemon, o que na prática é todos os pares ou nenhum.

Processos de servidor separados com os seus próprios intervalos de endereços e portas são o meio-termo viável. Cada processo leva exatamente uma decisão de acesso, pelo que dois grupos podem ter regras diferentes sem uma matriz de políticas. O anfitrião pode encaminhar entre os intervalos quando é isso que se pretende, e então a firewall vê esses fluxos porque atravessam o anfitrião. O custo são portas extra, certificados extra e um perfil por grupo.

Escolher o ponto de encaminhamento

Escolha o encaminhamento do kernel quando a firewall é o motor de políticas, quando precisa de registo por fluxo ou quando a contabilidade importa. O custo é o débito através da pilha do anfitrião e mais regras para manter. O benefício é que todas as ferramentas existentes, dos contadores aos exportadores de fluxos, voltam a descrever o tráfego. Num servidor pequeno esse custo é invisível; num repetidor ocupado não é.

Escolha o encaminhamento dentro do processo quando o tráfego entre pares está todo permitido ou todo negado e o servidor está dimensionado para isso. O custo é que contadores, disciplinas de fila e rastreio de ligações já não descrevem os fluxos internos; isso só é aceitável se depois ninguém depender deles.

Escolha o que escolher, escreva-o ao lado das regras da firewall. Um conjunto de regras que parece permitir o tráfego entre pares enquanto o daemon decide de qualquer forma engana a próxima pessoa que depurar uma transferência falhada. Quem ler apenas as regras vai assumir que o kernel é a porta.

O que verificar antes de mudar regras

Leia a configuração que o servidor realmente carregou, não o ficheiro que recorda ter editado, e confirme se a opção de pares está presente. Se a alterou, garanta que o serviço recarregou e não apenas reescreveu um ficheiro no disco.

Depois repita o teste com um fluxo de cliente para servidor para provar que a regra corresponde sequer, e verifique as rotas enviadas, porque uma rota em falta parece exatamente um bloqueio da firewall do lado do cliente. Mude a ordem das regras só quando souber qual ponto de encaminhamento detém a decisão.