¿Responder en la misma interfaz que el entrante?

51

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?

Shawn J. Goff
fuente

Respuestas:

61
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.

Peter
fuente
77
Wow, esto es exactamente lo que estaba buscando. En caso de que alguien esté buscando, para distribuciones basadas en RH, puede poner la regla relevante y los comandos de ruta en archivos llamados 'rule-eth0' o 'route-eth0' (por ejemplo) que se agregarán o eliminarán en ifup / ifdown. Coloque estos archivos junto con el archivo ifcfg-eth0. Para IPv6, hay una funcionalidad 'route6-eth0' incorporada, pero no hay una 'rule6-eth0' incorporada (todavía).
Kyle Brantley
18
Para mí, funcionó solo cuando dejé el devparámetro en el ip rulecomando, así que ejecutándoseip rule add from <interface_IP> table isp2
cdauth
2
Puede hacer que se creen cuando la interfaz sube agregando up ip rule add from <interface_IP> table isp2y up ip route add default via <gateway_IP> dev ppp0 table isp2a su / etc / network / interfaces debajo de la interfaz relevante.
g.rocket
44
Tuve que eliminar dev <interface>de ip rulepara que funcione en mi caja. Si entiendo bien, dev <interface>estaba filtrando los paquetes que de alguna manera se configuraron en la interfaz incorrecta, que debían ser transferidos a la interfaz correcta por la ruta anulada, pero el filtrado de reglas por interfaz impedía que eso sucediera.
binki
2
Como la mayoría de las personas, tuve que eliminar dev <interface>del ip rulecomando para que esto funcione. Por favor actualice la respuesta! Excepto por ese detalle, funcionó a las mil maravillas. Muchas gracias, @Peter!
MoonSweep
6

Los siguientes comandos crean una tabla de enrutamiento alternativa eth1para los paquetes que tienen la marca 1 (excepto los paquetes a localhost). El ipcomando es de la suite iproute2 (Ubuntu: iproute Install iproute http://bit.ly/software-small , iproute-doc Install 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 1en 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.

Gilles 'SO- deja de ser malvado'
fuente
Agradable. Olvidé todo sobre marcar. Eso debería llevarme allí.
Shawn J. Goff, el
5

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 4to comando puede ser esta ahora:

ip rule add iif <interface> table isp2 priority 1000
Héctor Sánchez
fuente
Intenté mucho pero nada funcionó en mi situación, excepto esto ... muchas gracias.
agaggi
3

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 use el servicio 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
zaTricky
fuente