Regras de firewall só para NEW não fecham todos os caminhos WAN
Rejeitar as conexões NEW deixa intactos os fluxos estabelecidos e as respostas. Leia o estado do conntrack, a ordem das regras e as exceções antes de declarar uma política fechada.
Rejeitar as novas conexões de saída na WAN parece uma política de falha fechada, mas é uma promessa mais estreita do que aparenta. Os pacotes que pertencem a fluxos que já existem não correspondem a ela, e muitas respostas também não. Esta lacuna é fácil de perder porque a regra se lê como se cobrisse a interface e não um estado de conexão sobre ela. E ler a correspondência de estado como um veredicto é o que produz uma falsa sensação de fecho.
O estado é uma condição de correspondência, não um veredicto
O rastreamento de conexões classifica os pacotes pelo que a firewall já viu, não pelo que a aplicação acredita. Um fluxo observado nos dois sentidos está estabelecido, e os seus pacotes posteriores continuam estabelecidos mesmo quando a rota por baixo muda de um túnel para o uplink comum. Uma resposta a uma conexão de entrada também pode ser tráfego estabelecido. Esses pacotes nunca voltam a ser novos.
Por isso uma regra limitada às conexões novas não pode provar que todos os pacotes protegidos estão bloqueados. Deixa os outros estados ao que o resto do conjunto de regras faz com eles, o que pode ser uma aceitação colocada antes na cadeia.
Leia a regra no seu entorno
Uma aceitação ampla para o tráfego estabelecido e relacionado colocada antes do bloqueio deixa passar um pacote antes de o bloqueio ser avaliado. Retirar a condição de estado de uma regra posterior não mudará isso, porque a avaliação nunca lá chega. A ordem decide o resultado, e a correspondência de estado decide quais pacotes chegam a essa ordem.
Inspecione o conjunto de regras efetivo e não o ficheiro que editou, incluindo saltos para outras cadeias e tudo o que a plataforma gera. Num router gerido com iptables, listar a cadeia mostra as definições das regras, e as cadeias a que se refere também têm de ser seguidas. Um sistema nativo com nftables exige examinar o seu próprio conjunto de regras e as prioridades dos hooks, porque o firmware raramente gera cadeias idênticas.
Os contadores dizem qual regra correspondeu de facto, e costumam ser mais informativos do que uma captura de pacotes feita depois da decisão. Uma regra com contador a zero não foi alcançada, diga o que disser a sua posição.
Exponha a proibição independentemente do estado
Se um grupo de clientes nunca deve alcançar a internet fora do túnel, diga-o diretamente em vez de o aproximar com um só estado. A regra tem de selecionar por origem, saída e destino sem depender do estado da conexão, e tem de estar onde nenhuma aceitação anterior a possa contornar. Assim o acesso de gestão e as exceções da rede local recebem as suas próprias regras explícitas, de modo que a intenção fica visível na política.
Escolher reject em vez de drop muda a forma como o tráfego correspondente falha, e não amplia o conjunto de pacotes que a regra seleciona. Uma conexão recusada e um tempo limite silencioso são sintomas diferentes que apontam para a mesma seleção.
Uma política que permite deliberadamente respostas a um acesso iniciado remotamente pela WAN é defensável. Só tem de ser descrita assim em vez de apresentada como isolamento total apenas pelo túnel.
Verifique quem está realmente no grupo
O exemplo cobre o tráfego IPv4 encaminhado de um prefixo por uma interface. Não diz nada sobre IPv6, uma segunda ligação ascendente nem o tráfego que o próprio router origina. Um router que atua como resolução DNS envia as suas próprias consultas ascendentes, e essas nunca passam pela cadeia forward.
Confirme que os clientes protegidos ainda têm endereços dentro do prefixo escolhido, porque um dispositivo que se moveu para fora dele está direto por acidente e não por política. Alargar o bloqueio a toda a LAN sem rever o desenho das exceções também tende a eliminar o seu próprio caminho administrativo.
iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED
Depois teste um fluxo antigo ao lado de um novo. Uma tentativa de conexão nova e uma transferência bidirecional já ativa comportam-se de forma diferente sob esta regra, e só testar ambas mostra que política tem na realidade.