☰

¿Por qué algunas reglas DNAT de iptables no funcionan hasta que se reinicia?

tag-icon • tag-icon linux networking iptables udp dnat
¿Por qué algunas reglas DNAT de iptables no funcionan hasta que se reinicia?

Mis reglas DNAT de iptables no funcionan hasta que se reinicia. Si reinicio mi servidor, todas las reglas funcionan.

Descripción de la arquitectura:

Decenas de hosts (remitentes) envían algunos paquetes UDP (unidireccionales en un puerto específico 9999) a mi enrutador Linux. Este enrutador Linux usa iptables para reenviar esos paquetes a varios hosts (receptores).

remitenteX 10.0.0.X ====> enrutador Linux con iptables ====> receptorY 10.0.1.Y

El enrutador Linux tiene dos tarjetas de red eth1 10.0.0.1/24 (lado del remitente) y eth0 10.0.1.1/24 (lado del receptor).

Configuración de iptables:

  • ip_forwarding está activado
  • todas las políticas predeterminadas están configuradas en ACEPTAR
  • Existe una regla de iptables por remitente, aquí hay un ejemplo:
iptables -t nat -A PREROUTING -s 10.0.0.2 -i eth1 -j DNAT --to-destino 10.0.1.123

Configuración de la red :

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

Síntoma:

Después de agregar un conjunto de reglas, algunas de ellas no funcionan. Y puedo ver con tcpdump que los paquetes UDP ya no se enrutan y los paquetes se rechazan.

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
  • Si elimino todas las reglas y las reinyecto en iptables, las reglas que no funcionaban seguirán sin funcionar.
  • Si reinicio mi servidor, todas las reglas funcionan bien.

Análisis realizado:

Agregué una regla para registrar un remitente específico que no funciona:

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

Pero esta regla no registra nada. Los paquetes llegan porque los veo en tcpdump pero no están registrados. Además con la -vopción en iptables, no veo que los contadores aumenten para esta regla.

Si aplico la misma regla antes de que deje de funcionar, tengo algunos registros.

Pregunta :

  • ¿Existe algún límite en el reenvío UDP en iptables?
  • ¿Cómo puedo solucionar este problema?

Respuesta1

Los síntomas que describe coinciden con los que se observan cuando hay un conflicto entre una regla NAT y una entrada de seguimiento de conexión.

Por ejemplo, cuando un paquete coincide con

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

Es necesario crear una nueva entrada de seguimiento de conexión. Esto asignará una tupla de IP y puerto de origen y destino en el lado entrante a una tupla similar en el lado saliente.

No puede haber una entrada de seguimiento de conexión existente que coincida con el lado entrante, porque si la hubiera, se habría utilizado en lugar de la regla. Sin embargo, una vez que se ha reemplazado la IP de destino de la tupla para construir la tupla para el lado saliente, la tupla puede entrar en conflicto con una entrada de seguimiento de conexión existente.

Si instala la conntrackutilidad, puede escribir conntrack -Lpara ver una lista de entradas de seguimiento de conexiones existentes. Esa utilidad también tiene funciones para enumerar solo las entradas de seguimiento de conexiones que coinciden con criterios específicos, así como para eliminar entradas seleccionadas.

Si este es realmente el problema al que se enfrenta, eliminar la entrada de seguimiento de conexión infractor hará que el problema desaparezca. Una solución permanente generalmente implica configurar reglas NAT relevantes para paquetes en ambas direcciones, de modo que siempre obtenga la entrada de seguimiento de conexión deseada, incluso si el primer paquete se envía en la dirección opuesta a la que suele ser el caso.

información relacionada