Nova regra UFW, conexão antiga: o estado estabelecido vence

Adicionar uma regra de negação e ver um download aberto continuar não é um bug do UFW. A regra que você adicionou fica depois de regras que já aceitaram o fluxo, e uma conexão estabelecida antes continua correspondendo a elas. Corrigir isso significa inserir na posição certa e entender o que as regras anteriores prometem. A versão estreita dessa mudança é a que segue.

A ordem decide, não a existência da regra

O UFW é uma interface que escreve regras do netfilter por etapas: uma seção de estrutura que roda antes das regras do usuário, depois as próprias regras do usuário e então uma seção que roda depois delas. As regras anteriores padrão aceitam tráfego de conexões estabelecidas e relacionadas, e essas regras são avaliadas antes de qualquer coisa que você adicione com um allow ou deny comum. A referência de comandos do UFW documenta a sintaxe de inserção e a visão numerada de estado da qual essa mudança depende.

Essa ordem explica a surpresa. Sua nova regra é real e está na tabela certa, mas não é a primeira decisão que o pacote encontra. Uma conexão já rastreada como estabelecida nunca chega até ela.

Use regras route para esta tarefa, porque o pacote é encaminhado pelo gateway em vez de endereçado aos serviços do próprio gateway. Uma regra de entrada filtraria o tráfego errado e pareceria não fazer nada.

Insira acima da permissão ampla

Pré-visualize a inserção antes de aplicá-la e confirme que a regra não existe em outro ponto da lista. Duplicar uma política idêntica torna a remoção posterior ambígua, e quem remover a cópia errada não vai perceber por semanas.

sudo ufw --dry-run route insert 1 deny in on tun0 proto tcp from 10.88.0.55/32 to 192.0.2.88/32

Se a pré-visualização mostrar exatamente uma regra na posição esperada, aplique o mesmo comando sem a opção dry-run. A posição 1 a coloca acima das permissões de usuário mais amplas, não acima das regras de estrutura vistas antes. Confirme que o nome da interface corresponde ao dispositivo de túnel deste gateway, porque uma regra vinculada a uma interface que não existe mais ficará na lista parecendo correta enquanto não corresponde a nada. Renomeie a referência do dispositivo antes de aplicar, não depois que o teste falhar.

Não há porta de destino nessa regra, então ela nega todas as portas TCP naquele endereço, não apenas HTTPS. Se a intenção é um único serviço, nomeie a porta; uma regra mais ampla que a política é um incidente futuro à espera do primeiro leitor.

Restrinja a origem a um único endereço apenas se esse endereço estiver vinculado à identidade pretendida. Um pool de VPN com atribuição dinâmica pode entregar o mesmo endereço a outro cliente amanhã, e a negação seguiria o endereço em vez da pessoa.

Fluxos estabelecidos sobrevivem à nova regra

O rastreamento de conexões é o motivo de a sessão existente continuar. Assim que um fluxo é registrado como estabelecido, as regras anteriores aceitam seus pacotes antes de sua negação ser consultada, e a transferência termina como se nada tivesse mudado. Por isso, testar com um navegador que reutiliza uma conexão aberta não diz nada sobre a nova política. Uma negação pode parecer inútil minutos após a implantação e ser totalmente eficaz para o próximo usuário que se conectar.

Se o requisito inclui cortar tráfego ao vivo, essa mudança de regra de usuário não consegue entregá-lo. Revogar o estado rastreado é uma ação separada com seu próprio raio de impacto, e pertence ao dono do firewall e não a quem adicionou a regra. Esvaziar todas as conexões de um gateway para que uma sessão desapareça é o tipo de correção que gera um segundo incidente.

Lembre-se também dos limites. Esta regra não diz nada sobre ICMP, UDP ou IPv6, então um ping bem-sucedido não é prova de que a negação falhou. Um endereço IPv4 também não é um site: um nome pode resolver para vários endereços, e só o que você nomeou está coberto.

Teste com um fluxo novo

Leia as regras de usuário numeradas e a visão bruta eficaz, depois abra uma nova conexão a partir do cliente escolhido:

sudo ufw status numbered
sudo ufw show raw
# from 10.88.0.55, a new TCP connection to 192.0.2.88 should fail

A visão bruta importa porque status omite regras de estrutura escritas à mão, então ela pode fazer a ordem parecer diferente da que o kernel aplica. Compare as duas antes de concluir que uma regra está no lugar errado.

Depois verifique os dois controles que provam que a regra é restrita e não ampla: um destino permitido a partir do mesmo cliente ainda funciona, e um segundo cliente ainda alcança o destino negado se sua política permitir. Uma negação que quebra os dois testes é uma mudança de política, não uma medida direcionada.

Quando o teste terminar, remova apenas a regra que você adicionou, repetindo-a exatamente. Se a política for permanente, entregue-a ao dono do firewall com a identidade do cliente, o dono do destino e uma data de revisão, para que um endereço de túnel reatribuído não deixe para trás uma negação obsoleta.