it-swarm-es.tech

¿Responder en la misma interfaz que el entrante?

Tengo un sistema con dos interfaces. Ambas interfaces están conectadas a internet. Uno de ellos está configurado como la ruta predeterminada; Un efecto secundario de esto es que si un paquete entra en la interfaz de ruta no predeterminada, la respuesta se envía de vuelta a través de la interfaz de ruta predeterminada. ¿Hay alguna manera de usar iptables (u otra cosa) para rastrear la conexión y enviar la respuesta a través de la interfaz de la que proviene?

54
Shawn J. Goff
echo 200 isp2 >> /etc/iproute2/rt_tables
ip rule add from <interface_IP> dev <interface> table isp2
ip route add default via <gateway_IP> dev <interface> table isp2

Lo anterior no requiere ninguna marca de paquete con ipfilter. Funciona porque los paquetes salientes (de respuesta) tendrán la dirección IP que se utilizó originalmente para conectarse a la segunda interfaz como la dirección de origen (de) en el paquete saliente.

64
Peter

Los siguientes comandos crean una tabla de enrutamiento alternativa a través de eth1 para paquetes que tienen la marca 1 (excepto paquetes para localhost). El comando ip es de iproute2 suite (Ubuntu: iprouteInstalar iproute http://bit.ly/software-small =, iproute-docInstalar iproute-doc http://bit.ly/software-small ).

ip rule add fwmark 1 table 1
ip route add 127.0.0.0/0 table 1 dev lo
ip route add 0.0.0.0/0 table 1 dev eth1

La otra mitad del trabajo es reconocer los paquetes que deben obtener la marca 1; luego use iptables -t mangle -A OUTPUT … -j MARK --set-mark 1 en estos paquetes para enrutarlos a través de la tabla de enrutamiento 1. Creo que lo siguiente debería hacerlo (reemplace 1.2.3.4 por la dirección de la interfaz de ruta no predeterminada):

iptables -t mangle -A OUTPUT -m conntrack --ctorigdst 1.2.3.4 -j MARK --set-mark 1

No estoy seguro de si eso es suficiente, tal vez se necesite otra regla en los paquetes entrantes para indicarle al módulo conntrack que los rastree.

Tuve problemas con los paquetes generados localmente con la solución sugerida por Peter, descubrí que lo siguiente corrige eso:

echo 200 isp2 >> /etc/iproute2/rt_tables
ip rule add from <interface_IP> table isp2 priority 900
ip rule add from dev <interface> table isp2 priority 1000
ip route add default via <gateway_IP> dev <interface> table isp2
ip route add <interface_prefix> dev <interface> proto static scope link src <interface_IP> table isp2

NOTA: Puede encontrar problemas de sintaxis con la cuarta línea anterior. En tales casos, la sintaxis para el cuarto comando puede ser esta ahora:

ip rule add iif <interface> table isp2 priority 1000
5
Héctor Sánchez

Supongo que está ejecutando Linux y, además, que está utilizando una distribución basada en RedHat/CentOS. Otros Unix y distribuciones requerirán pasos similares, pero los detalles serán diferentes.


Comience probando (tenga en cuenta que esto es muy similar a la respuesta de @ Peter. Asumo lo siguiente:

  • eno0 es isp0 y tiene la puerta de enlace predeterminada general
  • eno1 es isp1 y tiene el IP/rango 192.168.1.2/24 con la puerta de enlace 192.168.1.1

Los comandos son los siguientes:

$ echo 200 isp1 >> /etc/iproute2/rt_tables
$ ip rule add from eno1 table isp1
$ ip route add default via 192.168.1.1 dev eno1 table isp1

El firewall no está involucrado de ninguna manera. Los paquetes de respuesta siempre se habrían enviado desde la IP correcta, pero anteriormente se enviaban a través de la interfaz incorrecta. Ahora estos paquetes de la IP correcta se enviarán a través de la interfaz correcta.


Suponiendo que lo anterior funcionó, ahora puede hacer que la regla y los cambios de ruta sean permanentes. Esto depende de la versión de Unix que esté utilizando. Como antes, estoy asumiendo una distribución de Linux basada en RH/CentOS.

$ echo "from eno1 table isp1" > /etc/sysconfig/network-scripts/rule-eno1
$ echo "default via 192.168.1.1 dev eno1 table isp1" > /etc/sysconfig/network-scripts/route-eno1

Probar que el cambio de red es permanente:

$ ifdown eno1 ; ifup eno1

Si eso no funcionó, en las versiones posteriores de RH/CentOS también debe ir con una de dos opciones:

  • No utilice el predeterminado NetworkManager.service; Utilice network.service en su lugar. No he explorado los pasos exactos necesarios para esto. Me imagino que involucra los comandos estándar chkconfig o systemctl para habilitar/deshabilitar servicios.
  • Instale el paquete NetworkManager-dispatcher-routing-rules

Personalmente, prefiero instalar el paquete de reglas, ya que es el enfoque más simple y compatible:

$ yum install NetworkManager-dispatcher-routing-rules

Otra recomendación importante es habilitar el filtrado de arp, ya que esto evita otros problemas relacionados con las configuraciones de red dual. Con RH/CentOS, agregue el siguiente contenido al archivo /etc/sysctl.conf:

net.ipv4.conf.default.arp_filter=1
net.ipv4.conf.all.arp_filter=1
3
zaTricky