Espero que alguien pueda arrojar algo de luz sobre esto. Mis conocimientos de networking son, en el mejor de los casos, básicos.
Tengo un servidor CentOS en dos redes:
- La NIC1 está en una IP pública con una puerta de enlace configurada en el conmutador 1. (Internet ADSL)
- NIC2 está configurada en 10.10.10.2 sin ninguna puerta de enlace configurada en el Switch 2. (Internet por cable)
- La puerta de enlace/enrutador del Switch 2 es 10.10.10.1. (enrutador ASUS)
Dentro de la LAN, otras PC de la LAN pueden acceder a 10.10.10.2 en puertos abiertos. Cuando se establece una regla de reenvío de puerto desde la puerta de enlace/enrutador 10.10.10.1 --> 10.10.10.2, esto no funciona. El reenvío de puertos en la puerta de enlace/enrutador 10.10.10.1 --> a 10.10.10.3 funciona (máquina Windows con la puerta de enlace configurada en 10.10.10.1).
¿Es posible llegar a 10.10.10.2 desde Internet público a través del enrutador ASUS 10.10.10.1?
Respuesta1
Enrutamiento de políticas de IP.
Encontré dos artículos de los mismos que usé para actualizar mi servidor CentOS para permitir que la segunda NIC reciba y envíe paquetes. También se logró actualizar otro servidor similar con NIC/puertas de enlace duales.
http://jensd.be/468/linux/two-network-cards-rp_filter<-- Seguí configurando políticas de IP en la sección 'mejor solución' y no cambié el valor de rp_filter. Este artículo también tiene bonitos diagramas.
http://www.microhowto.info/howto/ensure_metric_routing_on_a_server_with_multiple_default_gateways.html <--ejemplo adicional de lo anterior que me lo dejó más claro.
Si desea que los cambios sean permanentes, siga las instrucciones en el primer enlace de arriba.
Mi ejemplo:
- ip route add 99.88.77.66/24 dev eth0 tabla 1 (ejemplo de IP pública n.° 1)
- ruta ip agregar valor predeterminado a través de 99.88.77.1 tabla 1 (ejemplo de puerta de enlace de IP pública n.° 1)
- ip route add 10.10.10.0/24 dev eth1 tabla 2 (segunda NIC en una red diferente)
- ruta ip agregar valor predeterminado a través de 10.10.10.1 tabla 2 (puerta de enlace del enrutador ASUS)
- regla ip agregar desde 99.88.77.66/32 tabla 1 prioridad 100
- regla ip agregada desde 10.10.10.4/32 tabla 2 prioridad 110
- caché de vaciado de ruta IP
El /24 para usted puede cambiar dependiendo de la máscara de subred de su IP.
Respuesta2
Primero debemos entender por qué su configuración no funciona. Para hacer esto necesitamos considerar lo que sucede.
- Llega un intento de conexión desde la conexión a Internet "por cable".
- El enrutador NAT modifica la dirección de destino y configura una entrada en la tabla de mapeo.
- El paquete llega a su servidor y se genera una respuesta.
- Su servidor busca el destino de la respuesta en su tabla de enrutamiento y envía el paquete a la puerta de enlace predeterminada (por ejemplo, hacia la conexión a Internet "ADSL").
- Lo más probable es que el paquete se elimine por tener una dirección de origen falsa. Incluso si regresa al cliente, su dirección de origen no coincidirá con la que el cliente espera, por lo que el cliente la descartará como falsa.
Ahora que entendemos qué va mal, podemos hacer algo al respecto. Hay algunas opciones.
La opción 1 es utilizar "enrutamiento de políticas" en el servidor para enrutar el tráfico según la IP de origen. Esta es la mejor opción si el servidor la admite (las versiones recientes de Linux sí lo hacen).La respuesta de estiloCubre cómo configurar el enrutamiento de políticas en un servidor Linux para enrutar según la dirección de origen.
La opción 2 es apuntar la puerta de enlace predeterminada del servidor a un cuadro que pueda realizar enrutamiento de políticas. Entonces ese cuadro puede enrutar el tráfico correctamente dependiendo de su IP de origen. Esta puede ser una solución útil si el sistema operativo del servidor no admite el enrutamiento de políticas.
La opción 3 es hacer que la caja NAT se enmascare para el tráfico que reenvía el puerto. Consideraría que esta es una opción de último recurso, ya que oculta la dirección de origen real del tráfico.