Por que algumas regras DNAT do iptables não funcionam até a reinicialização?

Question

As regras DNAT do iptables não funcionam até a reinicialização. Se eu reiniciar meu servidor, todas as regras funcionam.

Descrição da arquitetura:

Dezenas de hosts (remetentes) enviam alguns pacotes UDP (unidirecionais em uma porta específica 9999) para o meu roteador Linux. Este roteador Linux usa o iptables para encaminhar esses pacotes para vários hosts (receptores).

senderX 10.0.0.X ==== > Roteador Linux com iptables ==== > receptorY 10.0.1.Y

O roteador linux tem duas placas de rede eth1 10.0.0.1/24 (lado dos remetentes) e eth0 10.0.1.1/24 (lado dos receptores).

Configuração do Iptables:

• o ip_forwarding está ativado
• todas as políticas padrão estão definidas como ACCEPT
• existem regras de iptables por remetente, aqui está um exemplo:

iptables -t nat -A PREROUTING -s 10.0.0.2 -i eth1 -j DNAT --to-destination 10.0.1.123

Configuração de rede:

ip addr show :

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 54:9f:35:0a:16:38 brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.1/24 brd 10.0.1.255 scope global eth0
    inet6 fe80::569f:35ff:fe0a:1638/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 54:9f:35:0a:16:3a brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.1/24 brd 10.0.0.255 scope global eth1
    inet6 fe80::569f:35ff:fe0a:163a/64 scope link
       valid_lft forever preferred_lft forever

Sintoma:

Depois de adicionar um conjunto de regras, algumas das regras não funcionam. E eu posso ver com o tcpdump que os pacotes UDP não são mais roteados e os pacotes são rejeitados.

tcpdump -n -i eth1 host 10.0.0.2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
16:12:58.241225 IP 10.0.0.2.56859 > 10.0.0.1.9999: UDP, length 1464
16:12:58.241285 IP 10.0.0.1 > 10.0.0.2: ICMP 10.0.0.1 udp port 9999 unreachable, length 556

• Se eu liberar todas as regras e reinjetá-las no iptables, as regras que não estavam funcionando ainda não funcionarão.
• Se eu reiniciar meu servidor, todas as regras funcionarão bem.

Análise concluída:

Eu adicionei uma regra para registrar um remetente específico que não está funcionando:

iptables -t nat -A PREROUTING -s 10.0.0.2 -i eth1 -j LOG --log-prefix='PREROUTING LOG :'

Mas esta regra não registra nada. Os pacotes estão chegando porque vejo os que estão no tcpdump, mas eles não estão conectados. Também com a opção -v no iptables, não vejo aumento de contadores para esta regra.

Se eu aplicar a mesma regra antes de deixar de funcionar, tenho alguns registros.

Pergunta:

• Existe algum limite no encaminhamento de UDP no iptables?
• Como posso solucionar esse problema?

Answer 1

Os sintomas que você descreve correspondem aos vistos quando há um conflito entre uma regra NAT e uma entrada de rastreamento de conexão.

Por exemplo, quando um pacote é correspondido por

-A PREROUTING -s 10.0.0.2 -i eth1 -j DNAT --to-destination 10.0.1.123

uma nova entrada de rastreamento de conexão precisa ser criada. Isso mapeará uma tupla de IP e porta de origem e destino no lado de entrada para uma tupla semelhante no lado de saída.

Não pode haver uma entrada de rastreamento de conexão existente que corresponda ao lado de entrada, porque, se houvesse, ela teria sido usada em vez da regra. No entanto, uma vez que o IP de destino da tupla tenha sido substituído para construir a tupla para o lado de saída, a tupla pode entrar em conflito com uma entrada de rastreamento de conexão existente.

Se você instalar o utilitário conntrack , poderá digitar conntrack -L para ver uma lista de entradas de rastreamento de conexão existentes. Esse utilitário também possui recursos para listar apenas entradas de rastreamento de conexão que correspondam a critérios específicos, bem como remover entradas selecionadas.

Se esse for realmente o problema que você está enfrentando, remover a entrada de rastreamento de conexão incorreta fará com que o problema desapareça. Uma correção permanente geralmente envolve a configuração de regras NAT relevantes para pacotes em ambas as direções, de forma que você sempre obtenha a entrada de rastreamento de conexão desejada, mesmo se o primeiro pacote for enviado na direção oposta do que normalmente é o caso.