¿Dos interfaces, dos direcciones, dos puertas de enlace?

15

Tengo un sistema que tiene dos interfaces de red con diferentes direcciones IP, las cuales están en el rango de direcciones públicas (aunque a través de NAT en el caso de la primera) y las dos tienen diferentes puertas de enlace. (Larga historia, es para fines de prueba)

El problema es que en este momento, si trato de hacer ping a la dirección en la segunda interfaz, la ruta predeterminada señala a través de la primera interfaz, y nunca llega correctamente.

¿Es posible asegurarse de que las respuestas siempre se envían a través de la misma interfaz de red (y con la misma IP de origen) en el momento en que entraron? Y si es así, ¿cómo?

debian networking ipv4

— Shadur
fuente

1

Posiblemente alguna variante sobre esto: unix.stackexchange.com/questions/4420/…

— Shawn J. Goff

17

Estás malinterpretando el problema. No todos los paquetes son una respuesta y no todos los paquetes se pueden combinar con algún otro paquete de modo que tenga sentido "la misma interfaz de red en la que entraron". Lo que desea hacer es seleccionar la puerta de enlace para un paquete en función de su dirección IP de origen.

Esto se denomina enrutamiento basado en el origen o enrutamiento de políticas. Puede hacerlo con una regla simpleiptables , pero la mejor manera es configurar dos tablas de enrutamiento, una para cada dirección de origen público:

Primero, cree dos tablas (Reemplace <NAME1> y <NAME2> con nombres sensibles para sus dos proveedores, lo mismo con IP1, DEV1, etc.):

echo 200 <NAME1> >> /etc/iproute2/rt_tables
echo 201 <NAME2> >> /etc/iproute2/rt_tables

Agregue una puerta de enlace a cada tabla de enrutamiento (si es necesario):

ip route add <NET1> dev <DEV1> src <SRC1> table <NAME1>
ip route add <NET2> dev <DEV2> src <SRC2> table <NAME2>

Luego una ruta predeterminada:

ip route add default via <IP1> table <NAME1>
ip route add default via <IP2> table <NAME2>

Luego, las reglas para seleccionar la tabla de ruta en función de la dirección de origen:

ip rule add from <IP1> table <NAME1>
ip rule add from <IP2> table <NAME2>

Consulte Enrutamiento para múltiples enlaces ascendentes / proveedores para obtener más detalles.

— David Schwartz
fuente

Usted escribió: 'No todos los paquetes son una respuesta y no todos los paquetes se pueden combinar con algún otro paquete de modo que tenga sentido "la misma interfaz de red en la que aparecieron". ' ¿Puedes explicarlo mas a fondo? Entiendo que no todos los paquetes son una respuesta y que no todos los paquetes se pueden combinar con otro paquete "fuente". Si excluimos estos paquetes de la consideración, ya que no causan ningún problema y, por lo tanto, no nos conciernen, ¿por qué los paquetes restantes no se pueden enrutar a la "misma interfaz de red en la que entraron"?

— Andrew Savinykh

@AndrewSavinykh Eso no resolvería todo el problema. En particular, se interrumpiría cada vez que un paquete saliente originado localmente (como una solicitud de ping saliente) saliera por la interfaz incorrecta para su dirección IP de origen y la puerta de enlace lo descartara. El problema es, como expliqué, en realidad, asegurarse de que los paquetes salgan de la puerta de enlace correspondiente a su dirección IP de origen.

— David Schwartz

David, quiero lograr lo mismo que OP pero no puedo. He publicado una pregunta aquí: serverfault.com/questions/992624/… , sería genial si pudieras echar un vistazo

— Housemd

6

La respuesta de David Schwartz es excelente, pero puede simplificar un poco las reglas de enrutamiento al tener solo una tabla adicional y usar su ruta predeterminada para la otra. Tengo un servidor que está detrás de dos puertas de enlace NAT, y recientemente pasé por el proceso de recrear ese escenario entre un montón de máquinas virtuales. Mi /etc/network/interfacesaspecto es este:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 192.168.13.13
    netmask 255.255.255.0
    up ip route add table optus default via 192.168.13.10
    up ip rule add from 192.168.13.213 table optus
    up ip route add default via 192.168.13.11

auto eth0:0
iface eth0:0 inet static
    address 192.168.13.213
    netmask 255.255.255.0

(esto es para una configuración donde los dos ISP son Optus y iiNet, de ahí el nombre de la tabla de 'optus')

Esto, más la línea para /etc/iproute2/rt_tablescrear la tabla, debería ser todo lo que necesita. Tendrás dos direcciones IP; el tráfico de 192.168.13.13 saldrá a través de 192.168.13.11, y el tráfico de 192.168.13.213 saldrá a través de 192.168.13.10. Configure esas dos puertas de enlace para hacer su reenvío de puertos de manera adecuada (192.168.13.11 reenvía cosas a 192.168.13.13 y 192.168.13.10 reenvía cosas a 192.168.13.213), y el resto debe hacerse cargo de sí mismo.

Es posible que necesite modificar un poco las cosas para su situación, ya que está utilizando IP públicas directamente, pero algo como esto debería funcionar. Además, es mucho más fácil hacer estas cosas /etc/network/interfacesy luego administrar git ese archivo, en lugar de tratar de recordar cómo lo configuró, ¡dos años después, cuando el sistema debe reiniciarse!

— rosuav
fuente

1

Ejemplo de red dual

Este ejemplo muestra cómo un adicional eth1con 10.130.0.2máscara de red 255.255.255.255y la puerta de enlace 10.130.0.1pueden estar disponibles para los servicios que se unen a ella comoping -I eth1 8.8.8.8

Técnicamente somos:

Agregar otra puerta de enlace con una métrica mayor
Agregar / usar la tabla 100 y configurarla
Agregar una regla para enrutar el tráfico hacia / desde eth1 a través de él

ip addr add 10.130.0.2/32 broadcast 10.130.0.2 dev eth1
ip link set eth1 up
ip route add 10.130.0.1 src 10.130.0.2 dev eth1
ip route add 10.130.0.1 src 10.130.0.2 dev eth1 table 100
ip route add default via 10.130.0.1 dev eth1 metric 10
ip route add default via 10.130.0.1 dev eth1 table 100
ip rule add from 10.130.0.2/32 table 100
ip rule add to 10.130.0.2/32 table 100
curl --interface eth1 ifconfig.co
curl --interface eth0 ifconfig.co
ping -I eth1 8.8.8.8

— intika
fuente