☰

Preciso migrar do iptables para o nftables?

tag-icon • tag-icon linux iptables firewall nftables
Preciso migrar do iptables para o nftables?

Eu tenho as seguintes regras de iptables.

Encaminhamento de pacotes de 1.2.3.4 e 5.6.7.8 (fontes) que chegam à porta 10000 para um servidor Socks5 externo em 10.10.10.10:1080. O IP do servidor é 50.50.50.50

Este esquema funciona bem se o valor da fonte não for alto e, ao mesmo tempo, o valor do Socks5 externo também não for alto. Quando eu tiver 50 fontes e 30 mil meias externas - o iptables está travado e nenhum encaminhamento de pacotes, então suspeito que haja um limite no desempenho do iptables. Alguém pode me dizer se o Nftables é mais poderoso e, em caso afirmativo, como traduzir minhas regras para o Nftables?

*nat
:PREROUTING ACCEPT [1:40]
:INPUT ACCEPT [1:40]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]

-A PREROUTING -s 1.2.3.4,5.6.7.8 -p tcp -m tcp --dport 10000 -j DNAT --to-destination 10.10.10.10:1080
-A POSTROUTING -d 10.10.10.10/32 -p tcp -m tcp --dport 1080 -j SNAT --to-source 50.50.50.50

COMMIT

*filter
:INPUT ACCEPT [15:1012]
:FORWARD ACCEPT [26:1348]
:OUTPUT ACCEPT [9:932]
COMMIT

Responder1

Aqui está uma explicação aproximada do que pode dar errado.

  • Antes de otabelas de ipregras:

    X (X = 2 no exemplo inicial do OP) endereços IP de origem com 2 ^ 16 portas de origem possíveis e 1 endereço e porta de destino:

    X * 2 ^ 16 conexões possíveis.

  • Depois detabelas de ipregras: fontes X foram comprimidas em uma fonte

    1 * 2 ^ 16 conexões possíveis.

Conexões X * 2 ^ 16 não podem ser feitas para caber em apenas 2 ^ 16 conexões. A colisão da porta de origem começará a acontecer cada vez com mais frequência e será resolvida alterando a porta de origem, mas encontrar uma porta de origem livre que não entre em conflito com outro fluxo se tornará cada vez mais difícil: a degradação do desempenho começa a aumentar, pacotes descartados podem até começar a acontecer.

Isso aconteceria de forma diferente setabelas de ipforam substituídos pornftáveis? Não. Em ambos os casos, não são eles que resolvem a colisão. Esta resolução é feita no mesmo backend comum do Netfilter:o nf_natmódulo do kernel, possivelmente iterando várias vezes se necessário e até mesmo desistindo (ou seja: descartando o novoconexãoentrada e o pacote acionou sua criação provisória).

A causa é o NAT de origem feito quando há um único destino possível (o servidor): deve ser evitado.

Possíveis soluções alternativas:

  • não use NAT de origem. Um roteamento adequado (mesmo que exija multi-homing ou um túnel) implementado para que 10.10.10.10 não precise ver uma única fonte 50.50.50.50 deve ser feito. A questão não explica por que este SNAT é necessário, portanto não é possível detalhar mais.

  • ter vários endereços de origem para balancear a carga e distribuir a pressão da porta de origem. Isto pode ser conseguido comtabelas de ipusando ostatisticmódulo para balanceamento de carga para vários SNATdestinos.

Mudando paranftáveisgeralmente é uma melhoria, mas, neste caso, esta não parece ser a solução.

informação relacionada