Ubuntu Linux: múltiples NIC, misma LAN ... Las respuestas ARP siempre salen a una sola NIC

Tenemos el servicio de Internet AT&T U-Verse, que tiene una puerta de enlace DSL extremadamente descabellada.

Tenemos 5 IP (máscara de red 248), pero la puerta de enlace es incapaz de hacer otra cosa que una sola IP -> mapeo de una sola dirección MAC.

Tenemos una única máquina de firewall y redirigimos diferentes combinaciones de IP / puerto a diferentes lugares dentro de una DMZ.

Nuestra solución hasta ahora es tener una máquina virtual VMWare en el firewall con 4 NIC adicionales, para obtener las otras 4 direcciones IP ... sin embargo, tenemos un problema.

La puerta de enlace básicamente está haciendo un ping ARP para ver si la IP responde en el MAC esperado. Con 4 NIC en la misma LAN, Linux está respondiendo a las solicitudes ARP para TODAS las IP utilizando una única interfaz. Eso no es lo que espera la puerta de enlace, y está arruinando las otras 3 NIC. La puerta de enlace se niega a enrutar el tráfico entrante para IP donde los resultados de ping ARP no son el MAC esperado.

¿Cómo podemos obtener las respuestas ARP para que la IP de eth0 salga eth0, la IP de eth1 salga eth1, etc.?

EDITAR

La respuesta de Christopher Cashell no funciona en esta situación. Tenía grandes esperanzas al leerlo, pero ... no.

EDITAR 2

Resuelto! Vea mi respuesta a continuación.

Su solución elegida funciona, pero hay alternativas que no involucran arptables. (Christopher Cashell estaba en el camino correcto, originalmente, pero estaba fuera de combate).

En resumen, desea establecer estos parámetros:

net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2

Deben estar disponibles cuando se ejecuta un núcleo Linux moderno de la serie 2.6. Verifique y asegúrese de que '/ proc / sys / net / ipv4 / conf / / arp_announce' y / proc / sys / net / ipv4 / conf / / arp_ignore 'existan en su sistema.

El parámetro 'arp_filter' solo funciona cuando sus diversas direcciones IP comparten un segmento LAN pero usan una subred IP diferente. Si también comparten la subred IP, debe usar 'arp_ignore' y 'arp_announce', como se indicó anteriormente.

(Creo que también es posible que deba configurar 'arp_filter' de nuevo a '0').

De acuerdo, aquí está la solución. Primero, un resumen:

Aquí está mi plan básico de red:

 eth0 10.10.10.2 netmask 255.255.255.248
 eth1 10.10.10.3 netmask 255.255.255.248
 eth2 10.10.10.4 netmask 255.255.255.248
 eth3 10.10.10.5 netmask 255.255.255.248

Todas las interfaces se superponen. Esto es técnicamente incorrecto, y la fuente de todos mis problemas ... pero tengo que hacerlo debido a esta estúpida puerta de entrada residencial.

Primero, las solicitudes de ARP transmitidas van a todos estos. Dado que las 4 IP son direcciones locales válidas, las 4 interfaces intentarán responder.

1) instalar arptables . Agregue esto en algún lugar durante el arranque ( /etc/rc.local aquí):

arptables -F INPUT
arptables -A INPUT -i eth0 --destination-ip ! 10.10.10.2 -j DROP
arptables -A INPUT -i eth1 --destination-ip ! 10.10.10.3 -j DROP
arptables -A INPUT -i eth2 --destination-ip ! 10.10.10.4 -j DROP
arptables -A INPUT -i eth3 --destination-ip ! 10.10.10.5 -j DROP

Esto evitará que las transmisiones entren en la interfaz incorrecta. Por lo tanto, la interfaz correcta ahora será el único respondedor.

Eso por sí solo no es suficiente. El siguiente bit es un problema de tabla ARP. La PC solicitante probablemente ya tenga una entrada en la tabla ARP, por lo que Linux usará la interfaz asociada con eso. Hasta que caduque la entrada de la tabla ARP, se intentará enviar respuestas ARP utilizando la interfaz de esa entrada, no la asociada con la solicitud ARP.

La opción sysctl rp_filter parece estar rechazando los paquetes de respuesta ARP salientes si están en la interfaz incorrecta. Entonces...

2) Desactivar rp_filter .

En Debian / Ubuntu, esto significa comentar las dos líneas rp_filter en /etc/sysctl.d/10-network-security.conf .

Esta opción fue habilitada por una razón ... es decir, para ayudar a prevenir ataques de suplantación de interfaz cruzada. Leí que verifica que el paquete es legal para la interfaz en la que entra o sale (intercambiando MAC e IP y viendo si todavía se enruta por la misma interfaz). Entonces, normalmente sería una mala idea apagarlo. En mi caso, todas las interfaces están en la misma red ... por lo que la verificación no importa en absoluto.

Si agrego otra interfaz y necesito la protección de suplantación de identidad, quizás pueda crear algunas entradas arptables / iptables para hacer lo mismo.

Esto tiene que ver con la forma en que Linux maneja las IP y las NIC. Básicamente, trata una dirección IP como si perteneciera al cuadro, y no solo la NIC específica. El resultado es que puede obtener respuestas ARP de direcciones IP en interfaces que no esperaría.

La solución es una opción sysctl. Como recuerdo, lo que estás buscando es:

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

Eso solucionará el problema por ti. Simplemente agréguelos a /etc/sysctl.conf y ejecute ' sysctl -p' (o ejecute cada línea como argumento para ' sysctl -w'.

Esto hará que Linux solo responda a las solicitudes ARP en la interfaz a la que realmente se asigna una dirección IP.

La respuesta aceptada en combinación con esto: http://www.linuxquestions.org/questions/linux-networking-3/multiple-interfaces-all-traffic-flows-through-just-one-538701/

donde las rutas estáticas se usan para comunicarse solo con las IP deseadas a través de ciertas interfaces, creé una solución poderosa y simple para un problema similar que tuve.

¿Puedes cerrar la puerta de enlace y hacer que el firewall maneje las IP?