Tengo un problema. Todas mis máquinas están detrás de un enrutador que está conectado a un puerto ETH del módem. Ese puerto es demasiado limitado en descarga/carga. Entonces, intenté conectar dos cables del enrutador al módem en dos puertos. He estado trabajando mucho en cómo resolver esto, ya no sé qué intentar.
Mi enrutador tiene 4 interfaces:
enp1s0f0 172.16.0.3
enp4s0f1 10.0.0.6
enp1s0f1 192.168.0.3
enp4s0f0 192.168.0.6
Como puede ver, eth3 y eth4 están en la misma red, lo cual es extraño. Tenía que ser así si quería conectarme al módem (192.168.0.1) usando dos puertos ETH.
Entonces, esto es lo que he probado:
echo "1 myorg" >> /etc/iproute2/rt_tables #added a custom routing table myorg
sudo ip route add 192.168.0.1 scope link dev enp4s0f0 #don't know if it is really necessary
sudo ip rule add from 192.168.0.6 table myorg
sudo ip route add default via 192.168.0.1 dev enp4s0f0 table myorg #second default gateway through myorg table
Obtengo estas rutas como resultado:
$ ip -4 route show table main
default via 192.168.0.1 dev enp1s0f1 onlink
10.0.0.0/24 dev enp4s0f1 proto kernel scope link src 10.0.0.6
172.16.0.0/24 dev enp1s0f0 proto kernel scope link src 172.16.0.3
192.168.0.0/24 dev enp1s0f1 proto kernel scope link src 192.168.0.3
192.168.0.0/24 dev enp4s0f0 proto kernel scope link src 192.168.0.6
192.168.0.1 dev enp4s0f0 scope link
$ ip -4 route show table myorg
default via 192.168.0.1 dev enp4s0f0
$ sudo route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.0.1 0.0.0.0 UG 0 0 0 enp1s0f1
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp4s0f1
172.16.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp1s0f0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp1s0f1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 enp4s0f0
192.168.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 enp4s0f0
Utilizo ufw como firewall NAT. Agregué en la sección *nat:
:POSTROUTING ACCEPT - [0:0]
-A POSTROUTING -s 172.16.0.0/24 -o enp1s0f1 -j MASQUERADE
-A POSTROUTING -s 10.0.0.0/24 -o enp4s0f0 -j MASQUERADE
El problema es, alternativamente, que las máquinas de la red 10.0.0.0 reciben una respuesta de ping del módem (puerta de enlace 192.168.0.1) o las máquinas de la red 172.16.0.0. Puede ser al revés según el momento, no sé por qué.
Mi módem ve ambos clientes 192.168.0.3 y 192.168.0.6 en dos puertos ETH.
Entonces, ¿es posible tener acceso WAN en todas las máquinas y todas las redes con esta topología (enrutador con dos interfaces en la misma red)?
Respuesta1
Si bien no está escrito explícitamente, supongo que el objetivo es dividir el tráfico de manera que:
- 172.16.0.0/24 el tráfico fluye a través de enp1s0f1
- 10.0.0.0/24 el tráfico fluye a través de enp4s0f0
Como escribió OP, esto necesita enrutamiento basado en políticas/fuentes.iptablesyfiltro de redrara vez son útiles (al menos solos):
- generalmente hablandoiptablesyfiltro de redno hagas rutas y no te preocupes por las rutas. Las rutas de la pila de enrutamiento de red. Algunos deiptables' las acciones seguirán causando alteraciones en la decisión de enrutamiento (como se describe en esteesquemático)
- cualquier acción realizada enPOSTRRUTAMIENTO, como su nombre lo indica, sucededespuésSe tomaron decisiones de ruta: es demasiado tarde para alterar la ruta. Aquí mientras elnat/POSTROUTINGSe necesitan reglas, no alterarán la ruta.
Cuando seaiptablesSe puede evitar para resolver un problema de enrutamiento, es mejor evitarlo. A veces no se puede evitar (y luego normalmenteiptablesse usa para agregar una marca a los paquetes y esta marca se usa en una ip ruleentrada).
Rutas
asumiré querp_filter=1está configurado en todas las interfaces, ya que es el valor predeterminado para la mayoría de las distribuciones, para habilitarReenvío de ruta inversa estricto.
La dirección de origen se selecciona por regla, el destino por tabla de enrutamiento. Las tablas de enrutamiento adicionales deben tener suficiente información para anular (sin ambigüedad) las rutas cuando solo se debe elegir una entre varias (entonces solo se agrega esta a la tabla). A menudo también se deben copiar rutas adicionales de la tabla principal o pueden suceder cosas malas.
En mi respuesta no daré preferencia a una red u otra: cada una tendrá su propia tabla de enrutamiento. Olvidaré la tabla 1 y usaré las tablas 10 para LAN 10.0.0.0/24 y 172 para LAN 172.16.0.0/24. Mantenga las reglas NAT, elimine las reglas y tablas de enrutamiento adicionales, así como 192.168.0.1 dev enp4s0f0 scope linklas principales.
Rutas para 10.0.0.0/24 <--> 10.0.0.6 enp4s0f0 | enp4s0f1 192.168.0.6 <--> 192.168.0.1/predeterminado:
ip rule add from 10.0.0.0/24 lookup 10 ip route add table 10 10.0.0.0/24 dev enp4s0f1 ip route add table 10 192.168.0.0/24 dev enp4s0f0 src 192.168.0.6 ip route add table 10 default via 192.168.0.1
Arriba, sin también la entrada de ruta duplicada para 10.0.0.0/24, el sistema no podría acceder a esta LAN: resolvería la ruta como si tuviera que pasar por la puerta de enlace predeterminada, solo paraReenvío de ruta inversa estricto(SRPF) hacen que esto sea difícil de depurar. Ese es un ejemplo de algo malo si no se agrega. En caso de duda, simplemente duplique las rutas.
Otra opción equivalente podría haber sido, en lugar de la ruta adicional, cambiar la regla anterior a:
ip rule add from 10.0.0.0/24 iif enp4s0f1 lookup 10
por lo que no habría coincidido con el tráfico local (no enrutado) y solo se usaría la tabla principal.
Rutas para 172.16.0.0/24 <--> 172.16.0.3 enp1s0f0 | enp1s0f1 192.168.0.3 <--> 192.168.0.1/predeterminado:
ip rule add from 172.16.0.0/24 lookup 172 ip route add table 172 172.16.0.0/24 dev enp1s0f0 ip route add table 172 192.168.0.0/24 dev enp1s0f1 src 192.168.0.3 ip route add table 172 default via 192.168.0.1Para alterar también la ruta (el enlace) para el tráfico saliente iniciado localmente al cambiar la dirección IP de origen saliente en el sistema Linux. Esto debería ser opcional, pero la siguiente parte sobre el flujo ARP lo hace obligatorio:
ip rule add from 192.168.0.6 lookup 10 ip rule add from 192.168.0.3 lookup 172Cualquier caso no especial que involucre rutas anuladas de las reglas también debe duplicarse.
Aquí las únicas rutas que faltan están entre las dos LAN especiales:
en la tabla 10 para llegar a 172.16.0.0/24
en la tabla 172 para llegar a 10.0.0.0/24
debido a que cada tabla adicional aún no tiene una ruta para este otro lado, usaría la ruta predeterminada (pero SRPF la bloquearía nuevamente) impidiendo que cada una de las dos redes especiales se comunique más entre sí. Así que simplemente duplique la ruta que falta para cada tabla:
ip route add table 10 172.16.0.0/24 dev enp1s0f0
ip route add table 172 10.0.0.0/24 dev enp4s0f1
Con este modelo, si, por ejemplo, se agregaran otras dos redes internas "normales", podrían comunicarse entre sí (y usarían la ruta predeterminada de la tabla principal para salir) sin configuración adicional, pero nuevamente requerirían la duplicación de sus rutas en cada tabla de enrutamiento adicional para comunicarse con las dos LAN especiales.
Las rutas ahora están bien, pero todavía hay...
Elflujo ARPproblema
Linux sigue elmodelo de anfitrión débil. Ese es el caso del enrutamiento IP, y también de la forma en que Linux responde a las solicitudes ARP: desde cualquier interfaz para cualquier IP, pero por supuesto utilizando la propia dirección MAC de la interfaz. Como esto puede suceder en todas las interfaces simultáneamente cuando hay varias interfaces en la misma LAN, generalmente gana la más rápida. Luego, la información ARP se almacena en caché en el sistema remoto y permanecerá allí durante algún tiempo. Al final, el caché caduca, sucede lo mismo, con un posible resultado diferente. Entonces, ¿cómo causa esto un problema? He aquí un ejemplo:
- El enrutador (módem) envía una solicitud ARP para 192.168.0.6 para devolver una respuesta enrutada y NAT (por Linux) al tráfico enviado inicialmente desde 10.0.0.0/24.
- Linux responde enenp1s0f1(enp1s0f1ganó la carrera) usandoenp1s0f1La dirección MAC en respuesta para decirle que tiene 192.168.0.6.
- Durante unos segundos o unos minutos, los futuros paquetes IP de entrada del enrutador para 192.168.0.6 llegan alenp1s0f1,
- al mismo tiemposalidalos paquetes de 192.168.0.6 salen usandoenp4s0f0.
Esta ruta asimétrica es capturada porReenvío de ruta inversa estricto(rp_filter) y el tráfico fallará. Incluso puede parecer que esto funciona de forma aleatoria durante unos segundos y luego volver a fallar. Dependiendo del tráfico general, el problema podría incluso cambiar más tarde al otro enlace (y luego los problemas cambian a la otra LAN).
Afortunadamente, para evitar esto, Linux proporciona una configuración, que se usará solo junto con el enrutamiento de políticas, para que ARP siga las mismas reglas definidas por el enrutamiento:arp_filter.
arp_filter - BOOLEANO
1: le permite tener múltiples interfaces de red en la misma subred y tener los ARP para cada unainterfazser respondido en base asi el kernel enrutaría o no un paquete desde la IP ARP hacia esa interfaz(por lo tantodebes usar enrutamiento basado en fuentepara que esto funcione). En otras palabras, permite controlar qué tarjetas (normalmente 1) responderán a una solicitud arp.
sysctl -w net.ipv4.conf.enp4s0f0.arp_filter=1
sysctl -w net.ipv4.conf.enp1s0f1.arp_filter=1
Ahora el comportamiento de ARP es correcto, si se acaba de implementar la configuración, se debe forzar el vaciado del caché ARP decolegas(aquí: el módem) haciendo una detección de dirección duplicada conarping(deiutils/iputils-arping) que transmitirá a sus pares y les hará actualizar su caché:
arping -c 5 -I enp4s0f0 -D -s 192.168.0.6 192.168.0.6 &
arping -c 5 -I enp1s0f1 -D -s 192.168.0.3 192.168.0.3
Tenga en cuenta que las dos reglas del punto 3 de la parte anterior ahora son obligatorias, porque las direcciones IP 192.168.0.3 y 192.168.0.6 deben coincidir en las reglas de enrutamiento de políticas para una resolución ARP correcta con arp_filter=1.
Cómo depurar
ip route getEs muy útil para comprobar rutas y filtrar rutas inversas:
Nuevo caso de prueba para el punto 4 anterior:
# ip route get from 10.0.0.111 iif enp4s0f0 172.16.0.111
172.16.0.111 from 10.0.0.111 dev enp1s0f0 table 10
cache iif enp4s0f0
# ip route get from 172.16.0.111 iif enp1s0f0 to 10.0.0.111
10.0.0.111 from 172.16.0.111 dev enp4s0f1 table 172
cache iif enp1s0f0
al eliminar reglas o rutas:
# ip route get from 10.0.0.111 iif enp4s0f1 8.8.8.8
8.8.8.8 from 10.0.0.111 via 192.168.0.1 dev enp4s0f0 table 10
cache iif enp4s0f1
# ip rule del from 10.0.0.0/24 lookup 10
# ip route get from 10.0.0.111 iif enp4s0f1 8.8.8.8
8.8.8.8 from 10.0.0.111 via 192.168.0.1 dev enp1s0f1
cache iif enp4s0f1
# ip route get from 192.168.0.1 iif enp4s0f0 192.168.0.6
local 192.168.0.6 from 192.168.0.1 dev lo table local
cache <local> iif enp4s0f0
# ip rule delete from 192.168.0.6 lookup 10
# ip route get from 192.168.0.1 iif enp4s0f0 192.168.0.6
RTNETLINK answers: Invalid cross-device link
Esto muestra cómo los resultados se modifican dependiendo de (falta de) reglas y rutas adicionales. El último resultado es el mensaje de error que indica que la verificación de reenvío de ruta inversa falló (=> descartar).
Luego están ip neigh(más útiles enparsistemas) para comprobar las entradas ARP, tcpdumpetc.