Um nome de cadeia não é um hook: iptables contra nftables

Ambos os firewalls podem filtrar o tráfego VPN encaminhado, e ligam as regras ao caminho do pacote de maneiras diferentes. O iptables tem cadeias internas dentro de uma tabela, então FORWARD existe como um ponto de hook nomeado. O nftables separa o nome de uma cadeia do seu tipo, hook e prioridade, o que significa que uma cadeia comum chamada FORWARD não filtra nada. Comparar os dois modelos explica por que uma entrada que parece correta numa ferramenta não tem efeito na outra.

Uma cadeia é um recipiente. Se o kernel a consulta depende da implementação e de como o conjunto de regras a liga.

Dois modelos, duas ligações diferentes

No iptables, a tabela filter vem com três cadeias internas, INPUT, FORWARD e OUTPUT, e -N cria uma cadeia definida pelo usuário que só tem efeito quando se salta para ela a partir de uma delas. O manual do nftables, em vez disso, define cadeias base, que declaram tipo, hook e prioridade, e cadeias comuns, que não o fazem. Uma cadeia base pode ter qualquer nome, e uma cadeia comum chamada FORWARD não ganha nenhuma propriedade do seu rótulo. É toda a diferença, e é invisível num tutorial que mostra apenas o texto das regras.

Backends de compatibilidade acrescentam uma segunda razão para não inferir comportamento a partir do nome de um comando. A documentação do iptables regista operações que diferem sob iptables-nft, por isso trate o nftables nativo, o iptables-nft e um conjunto de regras antigo como três sistemas e não como três grafias de um só.

Leia o erro no seu contexto real

Uma tabela ausente, uma falha de permissão, uma funcionalidade do kernel indisponível e uma cadeia nomeada ausente são quatro constatações diferentes, e apenas uma diz respeito à cadeia. Registe a versão da ferramenta, a família de endereços e a tabela pedidas, o espaço de nomes de rede e o primeiro erro exato. Depois verifique qual componente é dono do conjunto de regras: um serviço de firewall ou um gateway gerido por produto pode gerar as suas próprias cadeias e ordenação. Acrescentar uma cadeia nativa ao lado delas deixa a política gerida intacta e o inventário mais confuso.

O espaço de nomes de um contentor pode conter um conjunto de regras diferente do anfitrião, por isso um comando executado no contexto errado não consegue mostrar qual cadeia viu um pacote encaminhado. Elevar privilégios porque uma cadeia esperada não estava visível não é um diagnóstico.

Contadores provam alcance, não veredicto

Os contadores de regras dizem-lhe que uma regra foi atingida. Não dizem que uma regra posterior permitiu a operação, e não provam que todos os caminhos alternativos foram negados. Leia-os durante um único fluxo autorizado e inofensivo, juntamente com a ordem das regras e a ligação da cadeia, e trate-os como uma observação e não como um veredicto. Um contador diferente de zero numa regra de drop significa que o tráfego a atingiu; não diz nada sobre o tráfego que não a atingiu.

O encaminhamento IP do kernel é uma definição totalmente separada. A existência de uma cadeia não ativa o encaminhamento, e a ausência de um rótulo familiar não significa que o encaminhamento parou.

Descreva o fluxo que pretende proteger

Escreva um pedido de cliente após a desencapsulação: a origem, o destino, a família de endereços e se termina no gateway ou passa por ele. A entrada de um serviço local e o tráfego encaminhado são observados em pontos diferentes, por isso exigem regras e testes diferentes. Para uma VPN em ponte, verifique também o caminho da ponte, porque uma cadeia ao nível de IP não controla automaticamente as tramas Ethernet.

Preserve um acesso de recuperação independente antes de alterar um gateway remoto. Depois confirme o fluxo pretendido e as negações necessárias sob o mesmo conjunto de regras. Uma nova cadeia vazia com um nome familiar não é uma reparação.

A comparação termina numa pergunta: que hook chama o kernel realmente para este pacote? Responda a isso, e o nome da cadeia deixa de importar.