Cuándo el NAT dentro de una VPN de sitio a sitio se gana su lugar

Dos sedes usan el mismo rango privado y el túnel se levanta mientras nada útil lo cruza. La traducción es la respuesta habitual, y es una respuesta real: presentar un rango distinto al lado remoto puede resolver una superposición o una ruta de retorno que la otra red no puede enrutar. La parte que se omite es que la traducción cambia las direcciones que ve cada decisión posterior. Trátelo como una decisión de diseño documentada con un mapeo escrito, no como una regla que se añade hasta que un ping tiene éxito.

Decida qué dirección se reescribe

La traducción de origen cambia lo que el servicio remoto y sus registros ven como cliente, así que un host de sucursal se convierte en una dirección de puerta de enlace al llegar. La traducción de destino o de prefijo presenta en cambio una dirección alternativa para un recurso remoto. Algunos despliegues necesitan traducción coordinada en ambos lados para separar dos redes por lo demás idénticas, y la combinación es donde empieza la mayor parte de la confusión.

Anote el origen antes de la traducción, el destino tal como lo nombra la aplicación y el par de direcciones con el que coincide cada puerta de enlace. Tres columnas bastan, y la tercera columna es la que la gente omite.

El orden de los selectores también importa. La selección y la traducción de políticas IPsec ocurren en etapas definidas, así que un selector escrito para direcciones previas a la traducción puede no coincidir nunca con el paquete en la etapa que supuso. Compruebe la política instalada en lugar de la que pensaba instalar, porque las dos divergen justo cuando una regla es aceptada por un componente e ignorada por otro:

ip xfrm policy show
ip xfrm state show
nft list ruleset | grep -A4 nat

Siga la carga útil y la ruta de retorno

Un servidor que registra el origen traducido en lugar del host de sucursal individual romperá cualquier regla o informe vinculado a la dirección original. Antes de cambiar el mapeo, averigüe si algo aguas abajo toma una decisión a partir de ese campo: listas de acceso, informes de auditoría, límites de velocidad, comprobaciones de licencia. Cada uno de ellos es un lugar donde la traducción aparece más tarde como un fallo inexplicado.

Los protocolos que llevan direcciones dentro de su carga útil necesitan una planificación aparte, porque reescribir la cabecera externa no toca la referencia interna. FTP activo, SIP y algunos productos de acceso remoto son los casos clásicos, y un diseño que los ignore funcionará para el tráfico web y fallará para la aplicación que importaba.

El tráfico de retorno depende de mapeos con estado. La conmutación por error de la puerta de enlace puede perder ese estado, el enrutamiento asimétrico puede evitarlo y un reinicio puede borrarlo mientras las sesiones siguen abiertas en el lado remoto. Por eso una solicitud que llega al destino y una sesión que se completa son dos resultados de aceptación distintos.

Péselo frente a renumerar una sede

Renumerar una sede en conflicto elimina el mapeo por completo y deja un plan de direcciones que se puede leer sin tablas de traducción. Es caro operativamente: los registros DNS, las asignaciones estáticas, las reglas del cortafuegos y cada dirección documentada tienen que cambiar a la vez. El coste llega una vez, en una ventana planificada, con un estado final claro. Lo que compra es la capacidad de leer una captura de paquetes años después sin una tabla de consulta.

La traducción evita la mayoría de los cambios locales y crea un mapeo que hay que mantener en DNS, documentación y resolución de problemas para siempre. El coste llega de forma continua, en forma de cada futuro ingeniero que tiene que aprender que un prefijo significa otra cosa dentro del túnel.

Para una conexión temporal o una red de socio que no controla, el coste continuo suele valer la pena. Para dos sedes que posee y poseerá durante años, renumerar suele ser la decisión más barata una vez que la migración se cuenta con honestidad.

Demuestre ambos sentidos con una sesión real

Pruebe una sesión de aplicación en lugar de una sonda única. Una solicitud de eco correcta demuestra que un sentido de un protocolo funciona, y es del todo compatible con una ruta de retorno que falla para cualquier cosa con estado. Use el servicio que motivó el diseño y lea su registro en el extremo remoto para ver qué dirección de origen registró.

tcpdump -ni any host 10.40.9.20 and port 443
conntrack -L | grep 10.40.9.20
ip route get 10.40.9.20

Luego confirme que solo los servicios previstos son accesibles a través del mapeo. La traducción cambia el direccionamiento y no hace nada por la autorización, así que la política del cortafuegos sigue decidiendo qué se permite. Un diseño que se apoya en un prefijo traducido oscuro como su control de acceso no tiene ningún control de acceso.

Registre el mapeo, la sesión probada y las direcciones que observó cada lado. La próxima persona que depure este túnel necesita esos tres hechos más que el archivo de configuración.