Tengo dos redes y enrutadores (ambos en Advanced Tomato de Shibby) diseñados de la siguiente manera:
- Red de enrutador de respaldo (192.168.1.1/24)
- WAN-Xfinity
- LAN: pequeño número de clientes. Es importante destacar que el enrutador de la red principal es un cliente en esta red.
- Interfaces de red
- br0-local. El enrutador tiene IP 192.168.1.1
- eth0-Xfinity
- eth2 - Red inalámbrica: esta es la red a la que está conectada la red de respaldo como cliente inalámbrico
- Red del enrutador principal (192.168.2.1/24)
- WAN - Fibra
- LAN: conectado a puntos de acceso de red en malla. Casi todos los dispositivos de la casa están conectados a través de estos puntos de acceso de red Mesh a la red principal. Especialmente importantes son mi NAS local y los hosts de servicios, por ejemplo, Plex, impresoras y escritorio para juegos.
- Equilibrio de carga: este enrutador es un "cliente inalámbrico" en el enrutador de la red de respaldo y tiene Multi-WAN con equilibrio de carga habilitado.
- Interfaces de red
- br0-local. El enrutador tiene IP 192.168.2.1
- eth0 - Fibra
- eth2 - cliente en la red de respaldo con IP 192.168.1.81
como esta funcionando: Mientras el cliente esté en la red principal, el sistema funciona bien. Pueden acceder al NAS, la impresora, etc. También pueden acceder y hacer ping a cualquier cliente en la red de respaldo.
Problema:
El problema ocurre cuando el cliente está en la red de respaldo. Los clientes de la red de respaldo no pueden comunicarse con el NAS, la impresora, etc. en la red principal.
Lo que he intentado: he intentado permitir que el enrutador de respaldo permita a sus clientes acceder a la red del enrutador principal. Encontré algunos artículos que mencionan cómo hacer esto y realicé los siguientes pasos:
- Intenté agregar el siguiente reenvío de iptables a la red de respaldo
iptables -I INPUT -i br0 -j ACCEPT
iptables -I FORWARD -i eth2 -d 192.168.2.0/24 -j ACCEPT
iptables -I FORWARD -i br0 -d 10.9.8.0/24 -j ACCEPT
Habilitar el reenvío de paquetes IP tanto en la red principal como en la de respaldo ejecutando
echo 1 > /proc/sys/net/ipv4/ip_forwardAgregar ruta ip
ip route add 192.168.2.0/24 via 192.168.1.81
Asuntos
Lamentablemente, esto no funciona. Cuando intento hacer ping a 192.168.2.1 desde mi enrutador de red de respaldo, aparece el error - Unable to ping From 192.168.1.1 icmp_seq=1 Redirect Host (New nexthop 192.168.1.81).
Supongo que me estoy equivocando con la parte de iptables. No entiendo del todo lo que estoy haciendo allí. Si alguien puede ayudarme, se lo agradecería profundamente.
Respuesta1
Intenté agregar el siguiente reenvío de iptables a la red de respaldo
Las reglas FORWARD no parecen coincidir con la descripción de su red:
Los paquetes que llegan al eth2 del enrutador de respaldo (es decir, provenientes del enrutador principal) tendrían 192.168.2.0/24 como sufuente,no destino; y de la misma manera, los paquetes enviados a 192.168.2.0/24 saldrían de eth2, no ingresarían (es decir, si ese es el
-d, entonces debería ser-o eth2).Si visualizas los paquetes, en ambas direcciones, deberías tener algo como esto:
Dirección de la fuente dirección de destino Interfaz de entrada Interfaz de salida 192.168.1.0/24 192.168.2.0/24 →br0 eth2→ 192.168.2.0/24 192.168.1.0/24 →eth2 br0→ Puedes agregar reglas con solo
-sy-d, o con interfaces, etc. Sugeriría mirar los contadores de paquetes en la lista de reglas de iptables para verificar si las reglas se están cumpliendo.emparejadopor cualquier paquete.La red 10.9.8.0/24 no parece estar involucrada en ninguna parte.
La regla INPUT no es relevante, ya que ninguno de sus paquetes es "entrada" al enrutador; ese solo sería el caso si estuviera haciendo ping al enrutador.propioDIRECCIÓN.
Por ejemplo, si estuviera haciendo ping al enrutador principal, sería "adelante" para el enrutador de respaldo y "entrada" para el enrutador principal. Pero si estás haciendo ping a un cliente desde otro, eso se clasifica como "reenvío" para todos los enrutadores involucrados (y "entrada" solo para el cliente).
Si bien esto es necesario, generalmente debería ser un paso después de haber agregado rutas, no antes. Tenga siempre en cuenta que IPtables sólo controla si los paquetes sonpermitidoser reenviado en una dirección particular, pero no controladóndedeben reenviarse: la tabla de enrutamiento decide eso primero y luego usted adapta las reglas FORWARD de iptables a eso.
Habilitar el reenvío de paquetes IP en AMBAS redes de respaldo y principales ejecutando echo 1 > /proc/sys/net/ipv4/ip_forward
Son enrutadores: el firmware de Tomato ya tendrá el reenvío de paquetes habilitado de fábrica, ya que ese es básicamente el propósito de un enrutador, y es la forma en que obtienes acceso a Internet en este momento.
Cuando intento hacer ping a 192.168.2.1 desde mi enrutador de red de respaldo, aparece el error: No se puede hacer ping desde 192.168.1.1 icmp_seq=1 Redirigir host (nuevo nexthop 192.168.1.81).
Eso no es un error. Se trata de un mensaje opcional en el que el enrutador de respaldo indica que hay una ruta más directa disponible (sin pasar por el enrutador); normalmente lo veríasademása las respuestas habituales.
El error real es la ausencia de respuestas, lo que probablemente se debe a la falla del enrutador "de respaldo".oLas reglas del firewall del enrutador "principal" bloquean los paquetes en esa dirección.
Utilice tcpdump ( tcpdump -n -i ... "icmp") para comprobar dónde llegan y salen los paquetes:
- ¿Llegan alprincipal¿La interfaz eth2 del enrutador?
- Si no lo hacen, entonces el enrutador de respaldo no los está reenviando (es posible que iptables o la tabla de enrutamiento estén incorrectos).
- Si lo hacen: ¿Llegan también a la interfaz br0 del enrutador principal?
- Si no lo hacen, entonces el enrutador principal no los reenvía (ya tiene rutas locales para el destino, lo que deja que sus reglas de iptables no lo permitan).
- Si llegan a br0: ¿El cliente intenta responder?
- Si no es así, es posible que el propio firewall del cliente lo esté bloqueando.