nftables: insira a regra de permissão VPN antes do handle de descarte

Coloque uma regra de permissão no lugar errado e ela se comporta como se não houvesse regra alguma. No nftables, a escolha entre insert e add decide de que lado de uma regra referenciada a nova instrução fica, e um handle nomeia a regra no conjunto de regras ativo, não o seu número de linha. Se o posicionamento estiver errado, o pacote chega primeiro ao descarte.

A comparação abaixo usa um par fixo e uma troca de ouvinte externo. É deliberadamente estreita; substituir uma cadeia inteira é outra mudança, com outro perfil de risco.

Dois posicionamentos, dois resultados diferentes

insert coloca uma regra antes da regra referenciada. add coloca-a depois. Se a regra referenciada for o descarte terminal do fluxo, esses dois comandos produzem resultados opostos mesmo quando o texto da regra é idêntico.

Omitir uma localização tem o seu próprio comportamento padrão, outra razão para não copiar um comando de um fórum sem ler a que ele está ancorado. A âncora é toda a decisão. Anote o lado pretendido antes de digitar o comando. insert e add diferem numa palavra no arquivo.

O posicionamento é relativo a uma regra numa cadeia específica. Mover a mesma instrução para outra cadeia ou outra prioridade de hook muda quais pacotes ela vê, mesmo quando a sintaxe da regra parece correta.

Um handle identifica uma regra, não um número de linha

Um handle como 42 é um identificador no estado atual do conjunto de regras. Não é a quadragésima segunda regra e não é estável entre hosts, reconstruções ou um gestor que recarrega a sua configuração.

Localize a cadeia e o descarte terminal real antes de escolher a âncora. Depois confirme o handle nessa regra na mesma listagem que mostra o descarte, para que o número e a regra sejam lidos juntos. Um handle lido de uma listagem antiga pode já pertencer a outra regra. Leia-o novamente na sessão que aplicará a mudança.

iptables --version
nft -a list ruleset

A versão do iptables informa qual backend está em uso. Um conjunto de regras iptables-nft e uma tabela nativa gerida de forma independente podem coexistir, portanto uma listagem de um único frontend não é automaticamente a imagem completa da filtragem. Verifique ambas as vistas antes de escolher uma cadeia.

Encontre a cadeia e a regra que realmente descarta

Leia o hook de entrada, a prioridade da cadeia e a regra que rejeita este fluxo de ouvinte. Uma tabela inet pode transportar ambas as famílias de endereços, mas uma regra individual ainda pode corresponder apenas a IPv4.

Escolha um par aprovado, usando 198.51.100.25 do intervalo de documentação como exemplo. Um arquivo nativo revisto poderia colocar uma permissão externa antes do handle 42:

insert rule inet filter input handle 42 iifname "eth0" ip saddr 198.51.100.25 udp dport { 500, 4500 } counter accept

Substitua a família, a tabela, a cadeia, o handle, a interface de entrada e o par após a inspeção. O exemplo usa a forma de posicionamento por handle documentada para nft 1.0.9, e ela pertence a um arquivo de entrada; o uso de aspas nas chaves é uma questão separada quando o comando é escrito interativamente.

Mantenha claro o proprietário da configuração. Um gestor que reconstrua as suas regras pode substituir uma edição em tempo de execução, e um script de arranque que codifique um handle obsoleto falhará ou ligar-se-á à regra errada.

A permissão é delimitada, o descarte é terminal

Um veredicto de permissão termina a avaliação no seu caminho atual, mas uma cadeia base aplicável mais tarde ainda pode descartar o pacote. Um veredicto de descarte é terminal. Por isso um contador de permissões crescente não é prova de que o fluxo teve sucesso.

Inspecione todas as prioridades de hook relevantes em vez de uma cadeia isolada. Um pacote pode passar um filtro de entrada e ainda ser rejeitado pelo hook de outra tabela numa prioridade diferente. Enumere cada cadeia base que possa ver o fluxo.

Essa regra cobre apenas a troca de ouvinte externo. ESP encapsulado no transporte, ESP nativo, pares IPv6 e o tráfego decifrado dentro do túnel precisam todos de políticas próprias. Não é uma firewall VPN de site completa.

Verifique o arquivo e depois valide o resultado ativo

Execute uma verificação de sintaxe e de transação no arquivo revisto antes de o aplicar. O modo de verificação informa se o nft consegue analisar e preparar a mudança; não a aplica e não prova que outro hook permitirá o pacote. O arquivo permanece uma proposta até o proprietário o aplicar:

nft -c -f reviewed-vpn-rule.nft

Aplique-o através do processo controlado do proprietário e preserve o acesso de recuperação. Se a regra estiver errada, o descarte que tentava anteceder também pode cortar o caminho que usa para a corrigir.

Após a mudança, observe uma nova tentativa de par permitido e confirme que as origens fora do par aprovado continuam a ser rejeitadas. Mova a regra duradoura para o gestor que possui o conjunto de regras, porque os handles em tempo de execução localizam objetos atuais em vez de os identificar entre arranques.