Acabo de configurar un servidor Ubuntu como enrutador con NAT/PAT y estoy intentando hacer lo siguiente:
Trabajo para una escuela que ha dividido su red en redes más pequeñas conectadas por enrutadores. Necesito crear una dirección IP visible en la red interna de una sala que reenvíe todo el tráfico a una dirección IP externa.
Para explicarlo, esta es la configuración:
NAT exterior: eth1 - 192.168.1.254/24
NAT interior: br0 - 192.168.2.10, enmascaramiento habilitado
Necesito crear una dirección como 192.168.2.1, también para br0, que reenviaría todo su tráfico a la IP 192.168.1.1 y parecería como si esa IP estuviera conectada directamente a la red, pero NO tendría habilitado el enmascaramiento. .
La idea básica es que la dirección del enrutador br0 se establezca en 192.168.2.10, y también que br0 tenga otra dirección que no se enmascare y reenvíe todo el tráfico a 192.168.1.1, que es la dirección del enrutador principal. La razón de esto es que br0 es un puente entre la red física y una VPN a la que se accedería desde detrás de un enrutador con la misma dirección que la dirección IP NAT de destino: 192.168.1.1. Como no puedo asegurar que los clientes siempre puedan emitir un comando "agregar ruta", necesito una manera de evitar esto.
Descubrí cómo configurar direcciones IP secundarias para br0 y configuré br0:1 como 192.168.2.1, pero parece que no puedo reenviar todo el tráfico a 192.168.1.1.
Te agradezco de antemano por tu ayuda.
Respuesta1
Lo que está intentando hacer, si le entiendo correctamente, es efectivamente una forma de enrutamiento de políticas con algo de NAT involucrado. Parece que solo está buscando crear un alias para algún host fuera de una subred enrutada en particular que se encuentra en esa subred.
Puede crear reglas DNAT sin el SNAT correspondiente (o enmascaramiento). La razón por la que esto no se hace es simplemente que la mayoría de las NAT están diseñadas para solucionar un problema de conectividad por el cual las direcciones en el "interior" de la NAT no serían enrutables desde el "exterior". Si de hecho el host 192.168.1.1 tiene una ruta de regreso a 192.168.2.0/24 o lo que sea, puedes configurar una regla DNAT si no recuerdo mal:
iptables -t nat -A PREROUTING -s 192.168.2.0/24 -d 192.168.2.1 -j DNAT --to 192.168.1.1
Ahora, detente por un momento y no hagas eso todavía.
Esto funciona cuando 192.168.2.1 es una dirección de destino (y crea una peculiaridad extraña por la cual la dirección que responde al tráfico es diferente del destino original). No creo que eso sea lo que quieras hacer, según tu descripción, aunque honestamente no estoy seguro. Hacer DNAT no ayudará en absoluto si se supone que el host 192.168.2.1 actúa como enrutador y no como destino. Si se supone que debe actuar como enrutador, NAT (o PAT) no ayudará en absoluto.
Parece que está entrando tráfico VPN que termina conectado a esta subred 192.168.2.0/24 si lo estoy leyendo correctamente y completando los espacios en blanco tal como están, y necesita llegar al resto del mundo o a algún subconjunto de a través de esta puerta de enlace 192.168.1.1. En ese caso, lo que hay que hacer essimplemente asigne 192.168.2.1/24 (que supongo que ha configurado como puerta de enlace predeterminada en los clientes VPN) a su enrutador, asegúrese de que el reenvío esté habilitado y estará listo: los clientes VPN nunca tendrán que preocuparse de que el siguiente salto sea 192.168.1.1, al igual que su puerta de enlace no VPN predeterminada original (¿puerta de enlace doméstica?); no se dan cuenta por completo mientras el paquete transita. Los ISP utilizan este tipo de esquema con direcciones RFC1918 todo el tiempo para evitar desperdiciar direcciones enrutables accidentalmente escasas; No es un requisito que todos los enrutadores a lo largo de la ruta tengan direcciones únicas (aunque cuando las tienen, la resolución de problemas es mucho más fácil). El truco aquí es que los puntos finales de una conexión TCP no necesitan saber nada más que la dirección IP del siguiente salto.
Si ya estás haciendo esto y tienes problemas, verifica la ruta de regreso. Lo más probable es que su puerta de enlace en 192.168.1.1 no esté haciendo NAT para esas direcciones cuando envía su tráfico fuera de su NAT (que todavía verá como 192.168.2.0/24), las esté cortando con un firewall o no tenga una ruta de regreso adecuada. a 192.168.2.0/24.
Si he entendido mal tu intención en ambos aspectos, hay una tercera cosa que podría ayudarte. La única manera de especificar una puerta de enlace en iptables es con el objetivo TEE, que clona el paquete y enruta el clon sin cambios a algún host arbitrario. Sin embargo, tendrías que lidiar con el paquete no clonado de alguna manera. Ese objetivo se puede agregar en la cadena Mangle PREROUTING:
iptables -t mangle -A PREROUTING -s 192.168.2.0/24 -j TEE --gateway 192.168.1.1
Eso es algo extraño de hacer; esto está diseñado para registrar el tráfico, no para enrutarlo. Supongo que podrías deshacerte del paquete original en alguna etapa posterior de iptables, aunque esto es un desastre y realmente no lo recomiendo.
Como punto aleatorio, puede agregar direcciones IP adicionales a las interfaces usando el ip addr addcomando. No utilice herramientas de red (ifconfig); es antiguo y le faltan muchas características y sólo le dará dolores de cabeza a largo plazo.