¡Los problemas de enrutamiento asimétrico me están volviendo loco!
Estoy intentando construir un servidor multitarjeta con 3 NIC. Cada NIC está conectada a 3 subredes diferentes:
eth0: LAN conectada, 10.99.72.38; función: Gestión de tráfico
eth1: LAN conectada, 10.99.70.150; función: Tráfico de usuario
eth2: WAN conectado, 10.99.74.85; función: tráfico de usuarios
Estoy usando una imagen de Amazon Linux (Linux 3.14.20-20.44.amzn1.x86_64 x86_64) pero puedo cambiar a CentOS si realmente hace una diferencia.
La funcionalidad que estoy intentando implementar:
eth0: tráfico de gestión
- dirección: 10.99.72.38
- Quiero que esta sea una interfaz 'aislada', que solo acepte y responda direcciones en 10.0.0.0/8
- Piense en esto como una NIC 'ssh solo desde LAN local'.
- SÓLO puedo responder a través de eth0
- Todos los demás destinos están bloqueados, es decir, no se puede llegar a otros destinos a través de esta interfaz.
- NO utilizará eth1 o eth2 para el tráfico de respuesta para el tráfico que llega a eth0.
eth1: tráfico de usuarios hacia/desde LAN
- Dirección: 10.99.70.150
- Acepta cualquier tráfico de usuario desde la LAN a cualquier destino.
- enruta paquetes a través de eth1 para el tráfico destinado a 10.xxx
- enruta los paquetes a través de eth2 para cualquier otro destino (ruta predeterminada)
- NO enrutará los paquetes entrantes a través de eth0
eth2: tráfico de usuarios hacia/desde WAN
- dirección: 10.99.74.85
- acepta cualquier tráfico de usuario de eth1 y enviará paquetes desde eth2 para cualquier destino que no esté en 10.xxx
- acepta paquetes de respuesta en eth2 y enruta a través de eth1 cualquier tráfico destinado a 10.xxx
- NO enrutará los paquetes entrantes a través de eth0
Creé una tabla iproute2 en rt_tables llamada 'mgmt' y agregué reglas de enrutamiento basadas en políticas con alta prioridad para intentar aislar esta interfaz, pero no importa lo que intente, la tabla de enrutamiento principal todavía parece llamarse ya que eth0 es la ruta predeterminada. . Los problemas incluyen:
- Los paquetes entrantes de eth1 se enrutan a través de eth0 (¡no quiero esto!)
- Los paquetes entrantes de eth2 destinados a 10.xxx se enrutan a través de eth0 (¡no quiero esto!)
- Cuando elimino la ruta eth0 predeterminada de main, pierdo la funcionalidad eth0 por completo, incluso con una ruta en la tabla mgmt, pero eth1 responde correctamente.
Comenzando desde el principio, la tabla de rutas sin modificar (ruta -n):
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.99.72.1 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 10.99.70.1 0.0.0.0 UG 10001 0 0 eth1
0.0.0.0 10.99.74.1 0.0.0.0 UG 10002 0 0 eth2
10.99.70.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
10.99.72.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.99.74.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
Las reglas de IP no modificadas son:
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
¡Cualquier ayuda para formular correctamente las reglas, tablas y rutas de enrutamiento específicas, y para mostrarme cómo se verían las tablas y reglas de enrutamiento finales, sería muy apreciada!
Respuesta1
Deberías deshacerte de la configuración de puerta de enlace predeterminada para eth0y eth1. Cómo se hace eso depende de su distribución.
Probablemente no necesite enrutamiento de políticas. Supongo que lo que quieres se logra mejor con Netfilter/ iptables.
iptables -I INPUT 1 -i eth0 ! -s 10.99.72.0/24 -j DROP
iptables -I FORWARD 1 -i eth0 -j DROP
iptables -I FORWARD 2 -o eth0 -j DROP
iptables -I INPUT 2 -i eth1 ! -s 10.0.0.0/8 -j DROP
iptables -I FORWARD 3 -i eth1 -j ACCEPT
iptables -I INPUT 3 -i eth2 -m conntrack --ctstate NEW -j DROP
iptables -I FORWARD 4 -i eth2 -j ACCEPT
Probablemente esto se pueda hacer sin Netfilter, pero con enrutamiento de políticas.