Minhas regras DNAT do iptables não funcionam até a reinicialização. Se eu reiniciar meu servidor, todas as regras funcionarão.
Descrição da arquitetura:
Dezenas de hosts (remetentes) enviam alguns pacotes UDP (unidirecional em uma porta específica 9999) para meu roteador Linux. Este roteador Linux usa iptables para encaminhar esses pacotes para vários hosts (receptores).
senderX 10.0.0.X ====> Roteador Linux com iptables ====> receiverY 10.0.1.Y
O roteador Linux possui 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:
- ip_forwarding está ativado
- todas as políticas padrão estão definidas como ACEITAR
- existe uma regra 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 regras não funcionam. E 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 feita:
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 os vejo no tcpdump, mas eles não estão registrados. Também com a -vopção no iptables, não vejo contadores aumentando para esta regra.
Se eu aplicar a mesma regra antes de parar de funcionar, terei alguns logs.
Pergunta :
- Existe algum limite para o encaminhamento UDP no iptables?
- Como posso solucionar esse problema?
Responder1
Os sintomas que você descreve correspondem aos observados 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 poderá entrar em conflito com uma entrada de rastreamento de conexão existente.
Se você instalar o conntrackutilitário, poderá digitar conntrack -Lpara 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 modo que você sempre obtenha a entrada de rastreamento de conexão desejada, mesmo que o primeiro pacote seja enviado na direção oposta do que normalmente acontece.