Muitas vezes vejo que existem algumas regras de correspondência de estado em uma cadeia de iptables, como INPUT.
Eu sei o que eles estão fazendo, e estou interessado nisso
Devo fazer o mesmo para as chains da tabela NAT?
Por exemplo, no meu roteador doméstico, quero que ele aceite ssh e também atue como um roteador NAT.
Se tiver-mos:
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
devo fazer segue para um melhor desempenho?
-t nat -A POSTROUTING -m state --state RELATED,ESTABLISHED -j MASQUERADE
-t nat -A POSTROUTING -s 192.168.1.0/24 -o wan0 -m state --state NEW -j MASQUERADE
Acho que NÃO devo fazer o mesmo para a cadeia POSTROUTING, mas sim para o FORWARD.
Obrigado!
Não, você não precisa disso.
As regras de NAT dinâmicas sempre usam tabelas conntrack. Então isso é inútil (e errado). A
nat
tabela é atravessada apenas pelo primeiro pacote da conexão, então ela verá apenas os--ctstate NEW
pacotes. Ele nunca vê--ctstate ESTABLISHED
os pacotes, porque eles não atravessam as regras. Se o pacote for encontrado na tabela nat do rastreador de conexão, ele terá a tradução gravada aplicada e prosseguirá com a próxima tabela.A consideração do estado de conexão parece ser útil na
FORWARD
cadeia, não noPREROUTING
ouPOSTROUTING
, portanto, use-a nas tabelasFORWARD filter
ou .FORWARD mangle
Nota adicional:
state
o módulo match é obsoleto e removido do kernel. A correspondência real é implementada com oconntrack
módulo. Na minha opinião, é melhor usá-lo explicitamente, então é melhor sempre usar-m conntrack --ctstate ...
o-m state
.