Enruta entre LAN privadas antes de añadir otro NAT

Dos cortafuegos internos, un segmento de tránsito privado y una petición para que unos cuantos equipos de cada LAN hablen con los de la otra. El reflejo es levantar una VPN o añadir una segunda capa de NAT, y ambos reflejos cuestan más de lo que el problema merece. El enrutamiento ordinario basta cuando se cumplen tres condiciones: los rangos de direcciones no se solapan, ambos lados pueden devolver tráfico a la otra LAN y el segmento de tránsito ya es lo bastante confiable para los datos. Comprueba esas tres antes de diseñar nada, porque cada una cambia la respuesta.

Tres condiciones que deciden el diseño

La primera condición es el espacio de direcciones. Si ambas LAN usan el mismo bloque RFC 1918, el enrutamiento no puede distinguirlas y la traducción pasa a ser inevitable en lugar de opcional. La segunda es una ruta de vuelta: una ruta de A a B es inútil si B tampoco sabe cómo llegar a la LAN de A, y el conocimiento asimétrico es la razón más común de que un diseño enrutado descarte respuestas en silencio.

La tercera es la confianza. El enrutamiento mueve paquetes; no los protege. Un segmento de tránsito privado dentro de un edificio es algo distinto de una entrega a un proveedor o de un enlace que cruza una columna vertebral compartida de campus. Si el segmento no es confiable, la respuesta es un túnel entre los dos cortafuegos, y el plan de enrutamiento de abajo sigue aplicándose dentro de él.

Solo cuando las tres apuntan en la misma dirección gana el diseño simple. Cuando una falla, corrige esa condición de forma explícita en lugar de taparla con traducción, porque el NAT oculta el fallo en vez de resolverlo.

Construye el plan de rutas sobre la red de tránsito

Da a cada cortafuegos una dirección en el segmento compartido y añade una ruta concreta por cada LAN remota. Nada más de la configuración existente tiene que moverse, y en particular la ruta por defecto a internet debe quedarse exactamente donde está. Sustituir una ruta por defecto por el cortafuegos par enviaría cada destino no relacionado a través del tránsito, lo que es un cambio mucho mayor que el que se pide. La documentación de pfSense sobre enrutamiento estático describe el mismo modelo de ruta más puerta de enlace para esa plataforma, y el control equivalente existe en cualquier cortafuegos que ejecutes.

El cortafuegos A sirve 10.30.0.0/24 y el cortafuegos B sirve 10.40.0.0/24, con las dos direcciones de tránsito en 192.0.2.0/24. Cada equipo de la LAN mantiene su cortafuegos local como puerta de enlace, así que el único estado nuevo es una ruta en cada lado. En un cortafuegos basado en Linux el mismo plan se ve así, y el reenvío debe estar activado o la ruta se resolverá mientras el paquete se descarta.

sysctl -w net.ipv4.ip_forward=1
ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1
ip route get 10.40.0.15
traceroute -n 10.40.0.15

Mantén el filtrado separado de la traducción

El enrutamiento y la política son controles distintos, y es en el segundo donde fallan de verdad la mayoría de los diseños enrutados. Permite las fuentes, destinos y servicios concretos en la frontera de entrada que los paquetes cruzan realmente, y recuerda que una etiqueta de interfaz como WAN es un nombre, no una afirmación sobre la confianza. Un puerto de tránsito que lleva tráfico privado puede seguir teniendo el bloqueo de direcciones privadas activado por defecto.

Luego mira la traducción de salida antes de concluir que no hay NAT. Las reglas automáticas de salida pueden reescribir tráfico que nunca debía traducirse, lo que destruye las direcciones de origen que el otro lado necesita para su propia política y sus registros. Confirma que los flujos seleccionados conservan sus direcciones originales y deja en paz las reglas de traducción de internet para el tráfico que todavía las necesita.

iptables -t nat -S POSTROUTING
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni eth1 -c 5 host 10.40.0.15

Cuando el NAT es la respuesta honesta

La traducción se gana su sitio cuando los rangos de direcciones se solapan de verdad y la renumeración no está disponible, o cuando una política exige que un lado vea una sola dirección en lugar de una subred. En esos casos, un mapeo deliberado uno a uno o restringido por puertos es una decisión de diseño con consecuencias conocidas, no un apaño.

La consecuencia que hay que decir en voz alta es que el otro lado ya no puede ver ni filtrar fuentes individuales. Los registros se colapsan en la dirección que traduce, la política por equipo deja de funcionar y la resolución de problemas se convierte en una cacería de qué equipo interno tenía un flujo en un momento dado. Si nada de eso importa para el tráfico en cuestión, el NAT está bien.

Cuando el propio tránsito es la suposición equivocada

Si el segmento compartido cruza un proveedor, una matriz de conmutación compartida o cualquier camino donde otra parte pudiera leer el tráfico, el enrutamiento por sí solo no es una respuesta completa. Un túnel entre los dos cortafuegos te da confidencialidad y autenticación del par, y la tabla de rutas dentro de él es la misma tabla que habrías escrito en el tránsito.

Decide eso a partir de la pregunta de confianza de la primera sección, no de una costumbre de que las VPN son más seguras. Un túnel sobre un segmento que ya es privado añade coste operativo y otro modo de fallo sin ganancia, mientras que enrutar sobre un segmento no confiable cambia confidencialidad por una simplicidad que no puedes permitirte. Anota cuál de las tres condiciones impulsó la elección y el siguiente ingeniero no tendrá que volver a discutirlo.