7 votos

CentOS de reenvío de puertos no funciona

Estoy usando CentOS 6.5 y he añadido los siguientes comandos para mi iptables para reenviar todo el tráfico entrante en el puerto 8088 a 4569:

iptables -A PREROUTING -t nat -p udp --dport 8088 -i eth0 -j DNAT --to-destination 127.0.0.1:4569
iptables -I FORWARD 1 -d 127.0.0.1 -p udp --dport 4569 -j ACCEPT

iptables --list muestra el siguiente resultado:

iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  anywhere             localhost.localdomain udp dpt:iax

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Pero cuando me tome un paquete de seguimiento en el puerto udp 4569 no veo ninguna paquetes en ese puerto. Luego he añadido esto:

iptables -A PREROUTING -t nat -p udp --dport 8088 -i eth0 -j REDIRECT --to-ports 4569

Y mi iptable se parece a esto:

Table: nat
Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    DNAT       udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:8088 to:127.0.0.1:4569
2    REDIRECT   udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:8088 redir ports 4569

Pero no ha habido suerte. ¿Qué estoy haciendo mal?

7voto

Xavier Lucas Puntos 5349

Para redirigir los paquetes a la interfaz de loopback que usted necesita para utilizar la REDIRECT de destino.

iptables -A PREROUTING -t nat -p udp --dport 8088 -i eth0 -j REDIRECT --to-ports 4569

De lo contrario, puede cambiar la dirección de destino antes de la decisión de enrutamiento es llevado a 127.0.0.1. Esto significa que se considera como un marciano paquete por el núcleo y se dejó caer por el camino inverso de políticas de filtrado.

Los dos parámetros del kernel responsable de este comportamiento son :

  • net.ipv4.conf.eth0.route_localnet

route_localnet - BOOLEAN

No considere las direcciones de loopback como marciano de origen o de destino mientras que el enrutamiento. Esto permite el uso de 127/8 locales fines de enrutamiento.

por defecto es FALSE

  • net.ipv4.conf.eth0.rp_filter

rp_filter ENTERO

0 - Ninguna fuente de validación.
1 - el modo Estricto como se define en RFC3704 Estricta Camino Inverso Cada paquete entrante es a prueba en contra de la FIB y si la interfaz no es el mejor camino inverso el paquete de verificación fallará. Por defecto, error de paquetes se descartan.
2 - Suelta el modo como se define en RFC3704 Suelto Camino Inverso Cada paquete entrante de la dirección de origen es también prueba en contra de la FIB y si la dirección de origen no es accesible a través de cualquier interfaz el paquete de verificación fallará.

Actual de la práctica recomendada en RFC3704 es para habilitar el modo estricto a evitar la suplantación de IP de ataques DDos. Si se utiliza el enrutamiento asimétrico o otros complicado de enrutamiento, a continuación, suelta de modo que se recomienda.

El valor máximo de conf/{todos,interfaz}/rp_filter se utiliza cuando se hace fuente de validación en el {interfaz}.

El valor predeterminado es 0. Tenga en cuenta que algunas distribuciones permiten en los scripts de inicio.

Como usted totalmente quieren mantener este comportamiento legítimo, el REDIRECT de la cadena debe ser utilizado para superar esta condición de una regla determinada.

-1voto

dmourati Puntos 9454

Puede que sea necesario activar el reenvío ip en el kernel de Linux.

En primer lugar, comprobar el valor actual.

sysctl net.ipv4.ip_forward

Un cero significa que el reenvío de ip está deshabilitado. Este es el valor predeterminado.

Habilitar el reenvío ip.

sysctl-w net.ipv4.ip_forward=1

Ahora, repita la prueba.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: