NAT sobre VPN para redes solapadas: cómo conectarlas sin arrepentimientos

Cuándo NAT sobre VPN es la herramienta adecuada (y cuándo no lo es)

NAT sobre VPN existe por una razón central: espacio de direcciones solapado. Si Sitio A y Sitio B tienen ambos 10.0.0.0/16, no puedes enrutar entre ellos porque “10.0.5.10” no significa un solo host—significa dos. El enrutamiento necesita unicidad. NAT la crea reescribiendo direcciones mientras el tráfico cruza la frontera.

Usa NAT sobre VPN cuando

• No puedes renumerar uno de los lados a tiempo (adquisiciones, redes de proveedores, laboratorios “temporales” que se convirtieron en producción).
• Necesitas una integración estrecha: unos pocos servicios a través del túnel, no conectividad total.
• Necesitas aislamiento fuerte: quieres límites de traducción explícitos y alcance controlado.
• Estás integrando VPCs en la nube que se crearon con los mismos CIDR predeterminados por distintos equipos.

No uses NAT sobre VPN cuando

• Puedes renumerar con un radio de impacto sensato. Renumerar duele una vez. NAT duele para siempre.
• Necesitas identidad de extremo a extremo basada en direcciones IP (algunas ACL legadas, licencias frágiles, reglas geográficas). NAT convertirá el “quién” en “algún gateway”.
• Necesitas conexiones entrantes desde ambos lados hacia hosts arbitrarios. NAT puede hacerlo, pero la carga operativa crece rápido.
• Requieres transparencia perfecta (p. ej., protocolos de enrutamiento, ciertas herramientas de seguridad, algunos protocolos que incrustan IPs). NAT rompe la “transparencia” por diseño.

NAT no es maligno. Es un trade-off. Tómalo cuando debas, y después ingeniería como si fuera a ser auditado por una versión futura de ti irritada.

Un modelo mental que no te engañará a las 2 a.m.

Estás construyendo un límite de traducción a través de un túnel. El túnel es solo transporte—WireGuard, IPsec, OpenVPN, GRE sobre IPsec—no importa. Lo importante es esto:
las direcciones usadas dentro de cada LAN no tienen que ser globalmente únicas, pero las direcciones usadas a través del límite deben ser únicas en ese límite.

Piensa en tres espacios de direcciones:

• Local-real: las direcciones reales en Sitio A (p. ej., 10.0.0.0/16).
• Remoto-real: las direcciones reales en Sitio B (también 10.0.0.0/16, porque la vida duele).
• Traducido (virtual): las direcciones que pretendes que tiene el otro lado cuando se ve a través de la VPN (p. ej., “Sitio B se convierte en 172.20.0.0/16 cuando se ve desde Sitio A”).

Luego decides la direccionalidad:

• SNAT (source NAT): “Cuando mis hosts hablen por el túnel, reescribe su dirección origen.”
• DNAT (destination NAT): “Cuando el tráfico llegue por el túnel a una dirección traducida, reescríbelo al destino real.”
• Ambos, a menudo: SNAT en una dirección, DNAT en la otra, para que cada lado vea al otro como un CIDR virtual único.

El “dispositivo NAT” suele ser el gateway de la VPN. Eso es bueno: control central, menos piezas móviles, depuración más sencilla. Pero también significa que ese gateway se convierte en tu punto único de verdad de traducción—y por tanto en tu punto único de fallo si configuras mal conntrack, enrutamiento o estado de firewall.

Broma #1: NAT es como cinta adhesiva. Si la usas con cuidado, llegas a casa; si la usas por todas partes, terminas siendo la cinta adhesiva.

Patrones de diseño: qué traducir, dónde traducir y por qué

Patrón A: “Un lado traduce al otro” (traducción unidireccional)

Sitio A puede alcanzar Sitio B traduciendo a Site B en un rango no solapado visto desde A. Sitio B puede no necesitar iniciar conexiones de vuelta, o puede hacerlo usando reglas separadas.

Bueno para: “A habla con proveedor”, “A obtiene métricas de B”, “llamadas API unidireccionales”.

Riesgo: asimetría. Olvidarás que es asimétrico hasta que un incidente requiera conectividad inversa (administración remota, callbacks, TLS mutuo con listas de permitidos basadas en IP, etc.).

Patrón B: “Ambos lados se traducen mutuamente” (CIDR virtual bidireccional)

Cada lado obtiene una vista virtual del otro lado. Ejemplo:

• Sitio A real: 10.0.0.0/16; Sitio A virtual (tal como lo ve B): 172.21.0.0/16
• Sitio B real: 10.0.0.0/16; Sitio B virtual (tal como lo ve A): 172.22.0.0/16

Eso significa:

• Desde A, alcanzas hosts de B a través de 172.22.x.y.
• Desde B, alcanzas hosts de A a través de 172.21.x.y.

Bueno para: integraciones bidireccionales, acceso administrativo, service meshes que no son conscientes de que cruzan fronteras organizativas.

Riesgo: más reglas NAT, más complejidad, más momentos de “espera, ¿qué dirección probaste?”.

Patrón C: NAT solo para “zonas compartidas de colisión”

A veces solo parte del CIDR se solapa. Ejemplo: ambos sitios usan 10.10.0.0/16, pero Sitio A también tiene 10.20.0.0/16 que no se solapa.
Puedes enrutar la porción única directamente y NATear la porción solapada.

Bueno para: reducir el alcance de la traducción y preservar IPs de origen reales cuando sea posible.

Riesgo: matices operativos. Depurar se vuelve “este servicio se enruta, ese servicio se NATea”, que es una forma elegante de decir que es una trampa para los nuevos on-call.

Dónde NATear: gateway vs. host vs. middlebox dedicado

• NAT en el gateway VPN: mejor por defecto. Un único lugar para gestionar estado, firewall y registros.
• NAT en hosts individuales: evita esto a menos que te gusten los copos de nieve. Rompe la política uniforme y convierte migraciones en proyectos artísticos.
• Middlebox NAT dedicado: bueno cuando la VPN termina en hardware gestionado que no puedes personalizar, o cuando necesitas pares HA y separación limpia.

Elige tus CIDR traducidos como eliges contraseñas: que no sean obvios

No traduzcas un lado a 192.168.0.0/16 a menos que disfrutes las colisiones con redes domésticas, VPNs de cafetería y ese ejecutivo que insiste en tethering durante fallos.
Elige algo como 172.20.0.0/14 o un bloque tallado de 100.64.0.0/10 (espacio CGNAT) si tu entorno lo tolera. Sé consistente y documenta.

Estado, conntrack y por qué “hace ping” no es una revisión de diseño

La mayoría de implementaciones de NAT dependen del seguimiento de conexiones. Eso significa:

• El tráfico de retorno debe atravesar el mismo gateway (simetría).
• El failover sin sincronización de estado puede romper flujos en vivo.
• El alto churn de conexiones puede agotar las tablas conntrack.

Si tu app usa conexiones de larga duración (bases de datos, brokers de mensajería), planea para eso. Si usa ráfagas cortas (HTTP sin keepalive, ciertos patrones RPC), planifica más.

Qué se rompe cuando lo haces mal

NAT sobre VPN falla de formas predecibles y aburridas. El problema es que normalmente las descubres en el momento menos aburrido posible.

1) Bucle de enrutamiento y agujeros negros

Si traduces tráfico a un CIDR que alguno de los lados ya enruta hacia otro lugar, creas un bucle o un sumidero. Tu monitorización puede mostrar “VPN arriba” mientras los paquetes hacen danza interpretativa entre routers.

2) Rutas de retorno asimétricas (el asesino silencioso)

NAT es con estado. Si la salida va por Gateway A pero el retorno llega por Gateway B, Gateway B no tiene entrada conntrack, así que descarta o traduce mal. Los síntomas parecen “funciona en un sentido” o “SYN-SYN/ACK-y-luego-nada.”

3) DNS y confusión nombre→dirección

Si Sitio A resuelve db.siteb.internal a la dirección real (10.0.5.10) pero debe alcanzarla vía la dirección traducida (172.22.5.10), tus apps fallan aunque la ruta de red esté bien.
Arreglar la red no basta; debes arreglar el nombrado.

4) Listas de permitidos basadas en IP y colapso de identidad

Cuando haces SNAT, el lado remoto puede ver todo el tráfico como procedente de la IP traducida del gateway. Tu política “permitir esta subred” se convierte en “permitir el gateway.”
Eso no es intrínsecamente incorrecto—pero cambia tu modelo de amenaza y tu historia de auditoría.

5) Protocolos que incrustan direcciones IP

Algunos protocolos llevan literales de IP dentro de la carga útil. Ejemplos clásicos incluyen ciertos modos FTP, SIP/VoIP, rara-vez VPN dentro de VPN, chequeos de licencia legados y apps que se auto-anuncian endpoints.
NAT reescribe cabeceras, no cargas, a menos que añadas un gateway a nivel de aplicación (lo que probablemente no debas).

6) Logging y forense son menos veraces

NAT cambia direcciones origen. A menos que registres tuplas pre- y post-NAT, tu respuesta a incidentes empeora.
NAT no es excusa para dejar de preocuparte por la atribución; es razón para registrar como adulto.

7) MTU y fragmentación se ponen raras

La encapsulación VPN reduce el MTU efectivo. NAT no causa eso, pero los despliegues NAT-sobre-VPN a menudo coinciden con “agregamos un túnel y ahora algunas llamadas HTTPS se quedan colgadas.”
Verás problemas PMTUD, ICMP bloqueado y “los paquetes pequeños funcionan”.

Broma #2: La VPN estuvo “arriba” todo el tiempo. El Titanic también.

Hechos interesantes y contexto histórico

• NAT no formaba parte del plan original de Internet. Se popularizó a mediados de los 90 cuando el agotamiento de IPv4 se volvió real y las organizaciones quisieron redes privadas.
• RFC 1918 (rangos privados IPv4) es de 1996. Formalizó 10/8, 172.16/12 y 192.168/16, habilitando la era del “todos usan 10.0.0.0/8”.
• IPsec originalmente no adoraba a NAT. El ESP protegía cabeceras de formas que no jugaban bien con dispositivos NAT; surgió NAT-T para lidiar con ello.
• Carrier-grade NAT (CGNAT) normalizó la traducción a gran escala. Ese es el espacio 100.64.0.0/10—creado porque incluso NAT en el borde no fue suficiente.
• NAT rompe el principio end-to-end estricto. Ese principio de diseño precede al “zero trust” moderno, pero la tensión sigue siendo visible: la traducción añade estado intermedio.
• Las tablas conntrack de Linux han sido un límite en producción durante décadas. Altas tasas de conexiones pueden agotar el estado mucho antes de que la CPU llegue al tope, provocando caídas “aleatorias”.
• Muchas empresas accidentalmente estandarizaron en los mismos subnets. Plantillas VPC/VNet por defecto y “copia el plan VLAN del sitio anterior” crearon solapamiento como resultado normal de negocio.
• El enrutamiento basado en políticas precede a muchos servicios VPN en la nube. Los ingenieros de red de la vieja escuela lo usaban para dirigir tráfico por NAT y túneles mucho antes de que “Transit Gateway” fuera una categoría de producto.

Una cita que vale la pena tener en un post-it:
Todo falla, todo el tiempo. — Werner Vogels

Tres mini-historias corporativas desde las minas de NAT

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa mediana adquirió a una más pequeña. Ambos lados usaban 10.0.0.0/16 internamente, porque claro que sí. El plan de integración fue “túnel IPsec rápido, NATear el lado adquirido a 172.20.0.0/16, listo.”
Funcionó en laboratorio. Incluso funcionó una semana en producción.

Luego falló el procesamiento de nóminas. No por completo—lo suficiente para ser un incidente con atención ejecutiva. El SRE de guardia vio pings exitosos y conexiones TCP desde los servidores de aplicación hacia la API de nóminas. Aun así, la API devolvía 403s.
Ese es el tipo de problema que hace que la gente culpe a la VPN, al firewall o a la luna.

Causa raíz: la API de nóminas tenía una lista de permitidos basada en IP. Durante las pruebas, las IPs de origen eran hosts individuales de las apps. En producción, una nueva regla de “limpieza” SNATeó todo el tráfico saliente a una única IP traducida del gateway para simplificar la política.
La lista de permitidos no incluía la IP del gateway. Nadie pensó que NAT cambiaría la identidad, porque “solo estamos haciendo que el enrutamiento funcione”.

Solución: actualizar las listas de permitidos, añadir pools SNAT por subred para que distintos niveles de app preservaran identidad aproximada y—lo más importante—anotar que NAT cambia la atribución y debe revisarse con controles de seguridad.
El túnel estaba bien. La suposición no lo estaba.

Mini-historia 2: La optimización que salió mal

Otra organización tenía una configuración estable de NAT sobre VPN, pero la CPU del gateway era más alta de lo esperado en horas pico. Un ingeniero de red decidió “optimizar” apagando el seguimiento de conexiones donde fuera posible y usando reglas stateless más algunos trucos de enrutamiento.
Para algunos protocolos, parecía rendimiento gratis.

Dos semanas después, llamadas de clientes aleatorias empezaron a fallar—de forma intermitente. Algunas solicitudes tenían éxito; otras se quedaban colgadas. La línea temporal del incidente fue un desastre porque la VPN se mantenía arriba y la pérdida de paquetes no era obvia.
Se manifestó principalmente como timeouts a nivel de aplicación, lo que provocó reintentos, que provocaron más carga y más timeouts. Clásico.

La falla real fue sutil: algunos flujos tomaron un camino de retorno ligeramente diferente tras un cambio de enrutamiento en el lado remoto. Con conntrack deshabilitado para esa clase de tráfico, las asociaciones NAT no fueron consistentes para sesiones de larga duración, y el estado del firewall dejó de coincidir con lo que la aplicación esperaba.
El sistema derivó a un estado medio roto difícil de reproducir a demanda.

Solución: volver a poner conntrack, hacer el enrutamiento simétrico con policy routing explícito y escalar el gateway correctamente (instancia más grande, mejores offloads de NIC y dimensionamiento sensato de conntrack).
La “optimización” ahorró CPU y gastó fiabilidad. No es buen negocio.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una compañía global ejecutaba NAT sobre VPN entre la red de una fábrica y un entorno ERP central. Nada sofisticado: un par de CIDR traducidos, reglas de firewall estrictas y un proceso de control de cambios que exigía tres cosas:
un diagrama, un plan de pruebas y un plan de reversión.

Una noche, un evento del carrier provocó flapping y failover a un headend VPN de respaldo. El backup estaba correctamente configurado, pero no sincronizaba estado conntrack (porque la mayoría de configuraciones no lo hacen).
Varias sesiones de larga duración cayeron, saltaron alarmas y el on-call comenzó a sudar.

Aquí va lo aburrido: su runbook incluía un procedimiento conocido y bueno de “drenado de sesiones”. Temporalmente redujeron los intervalos de keepalive en la capa de aplicación, forzaron reconexiones durante una ventana controlada y validaron la recuperación usando una lista de comprobación de transacciones sintéticas.
No fue elegante. Fue predecible.

El resultado fue un incidente contenido, mínima inconsistencia de datos y un postmortem que no incluía la frase “no estábamos seguros de qué hacían las reglas NAT.”
Lo aburrido gana. Lo aburrido escala.

Tareas prácticas: comandos, salida esperada, decisiones

El objetivo de la depuración NAT-sobre-VPN es dejar de adivinar. Abajo hay tareas que puedes ejecutar en gateways Linux y hosts de prueba. Cada una incluye:
el comando, qué significa la salida y qué decisión tomar a continuación.

Tarea 1: Confirma el solapamiento y encuentra la colisión

cr0x@server:~$ ip -brief addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             10.0.1.1/24
wg0              UP             10.200.0.1/24

Significado: Este gateway está en 10.0.1.0/24 localmente y tiene una interfaz de túnel wg0.
Si el lado remoto también está en 10.0.1.0/24 (o cualquier cosa que se solape), el enrutamiento puro colisionará.
Decisión: Elige un CIDR traducido que no exista en ninguno de los lados (y que no aparezca después).

Tarea 2: Inspecciona la tabla de enrutamiento en busca de rutas ambiguas

cr0x@server:~$ ip route show
default via 10.0.1.254 dev eth0
10.0.1.0/24 dev eth0 proto kernel scope link src 10.0.1.1
10.200.0.0/24 dev wg0 proto kernel scope link src 10.200.0.1

Significado: No hay una ruta explícita para el CIDR remoto traducido todavía.
Decisión: Añade una ruta para el CIDR remoto traducido vía la interfaz del túnel (o mediante una tabla de policy routing si es necesario).

Tarea 3: Verifica que el handshake de la VPN esté realmente establecido (ejemplo WireGuard)

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 3xQk...redacted
  listening port: 51820

peer: c0z9...redacted
  endpoint: 198.51.100.20:51820
  allowed ips: 10.200.0.2/32
  latest handshake: 31 seconds ago
  transfer: 48.22 MiB received, 51.10 MiB sent

Significado: El túnel está arriba y pasa tráfico.
Decisión: Si el handshake está obsoleto, detente aquí y arregla conectividad/llaves/alcance UDP antes de tocar NAT.

Tarea 4: Confirma que el reenvío IP está habilitado en el gateway

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Significado: El kernel reenviará paquetes entre interfaces.
Decisión: Si es 0, habilítalo y persístelo vía /etc/sysctl.d/. Sin esto, culparás al NAT por un problema de enrutamiento.

Tarea 5: Comprueba si rp_filter descartará tus paquetes enrutados asimétricamente

cr0x@server:~$ sysctl net.ipv4.conf.all.rp_filter
net.ipv4.conf.all.rp_filter = 1

Significado: El filtrado de ruta inversa estricto está habilitado globalmente. Con policy routing o múltiples uplinks, rp_filter puede descartar tráfico válido.
Decisión: Para gateways NAT en VPN, considera poner a 2 (loose) en interfaces relevantes si usas enrutamiento asimétrico por diseño.

Tarea 6: Observa paquetes pre-NAT y post-NAT con tcpdump

cr0x@server:~$ sudo tcpdump -ni eth0 host 10.0.1.50 and port 443 -c 3
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:00:01.100000 IP 10.0.1.50.51544 > 172.22.5.10.443: Flags [S], seq 1000, win 64240, options [mss 1460], length 0

cr0x@server:~$ sudo tcpdump -ni wg0 host 172.22.5.10 and port 443 -c 3
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:00:01.100500 IP 172.21.1.50.51544 > 172.22.5.10.443: Flags [S], seq 1000, win 64240, options [mss 1360], length 0

Significado: En LAN, el origen es 10.0.1.50; sobre el túnel, el origen se volvió 172.21.1.50 (aplicado SNAT). El MSS también cambió (efecto de encapsulación).
Decisión: Si no ves la fuente traducida en el túnel, tu regla NAT no está coincidiendo o está en la cadena/hook incorrecto.

Tarea 7: Inspecciona reglas NAT (ejemplo iptables legacy)

cr0x@server:~$ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -s 10.0.1.0/24 -d 172.22.0.0/16 -o wg0 -j SNAT --to-source 172.21.0.1
-A PREROUTING -i wg0 -d 172.21.0.0/16 -j DNAT --to-destination 10.0.1.0/24

Significado: Hay SNAT para tráfico saliente hacia el CIDR remoto traducido. También hay una regla DNAT que parece incorrecta: DNAT a un CIDR entero no es válido en esa forma y sugiere confusión.
Decisión: Usa reglas mapeadas 1:1 deterministas (NETMAP) o DNAT explícito por host/servicio, no “DNAT a una red” a menos que sepas exactamente qué soporta tu herramienta.

Tarea 8: Inspecciona reglas NAT (ejemplo nftables moderno)

cr0x@server:~$ sudo nft list ruleset
table ip nat {
  chain prerouting {
    type nat hook prerouting priority dstnat; policy accept;
    iifname "wg0" ip daddr 172.21.0.0/16 dnat to 10.0.1.0/24
  }
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oifname "wg0" ip saddr 10.0.1.0/24 ip daddr 172.22.0.0/16 snat to 172.21.0.1
  }
}

Significado: Problema similar: el intento de DNAT es conceptualmente incorrecto. DNAT necesita un destino específico (o un constructo de mapeo), no “todos estos van a esa red”.
Decisión: Rediseña usando mapeo NETMAP 1:1 o usa un par de CIDR virtuales no solapados con traducción determinista.

Tarea 9: Valida que conntrack vea el flujo NATeado

cr0x@server:~$ sudo conntrack -L -p tcp --dport 443 | head -n 3
tcp      6 431999 ESTABLISHED src=10.0.1.50 dst=172.22.5.10 sport=51544 dport=443 src=172.22.5.10 dst=172.21.0.1 sport=443 dport=51544 [ASSURED] mark=0 use=1

Significado: Conntrack muestra la tupla original y la tupla traducida. Eso es bueno.
Decisión: Si la tabla está vacía mientras el tráfico fluye, conntrack podría estar omitido o roto—espera fallos intermitentes bajo carga.

Tarea 10: Comprueba la capacidad de conntrack antes de que sea un incidente de “caídas aleatorias”

cr0x@server:~$ sudo sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
net.netfilter.nf_conntrack_count = 24891
net.netfilter.nf_conntrack_max = 262144

Significado: Estás en ~9.5% de utilización. Bien.
Decisión: Si el contador se acerca al máximo durante picos, aumenta el máximo (con conciencia de memoria) y ajusta timeouts para tu perfil de tráfico.

Tarea 11: Detecta problemas MTU con ping DF (dolor clásico de VPN)

cr0x@server:~$ ping -M do -s 1472 172.22.5.10 -c 2
PING 172.22.5.10 (172.22.5.10) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420

--- 172.22.5.10 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1030ms

Significado: El MTU efectivo es 1420; intentar enviar tramas de 1500 bytes con DF falla.
Decisión: Ajusta MSS en el túnel/firewall o configura el MTU de la interfaz apropiadamente. Asegura también que ICMP “frag needed” no esté bloqueado.

Tarea 12: Confirma que el remoto ve la fuente correcta (verificación de impacto en la aplicación)

cr0x@server:~$ curl -sS --connect-timeout 3 https://172.22.5.10/whoami
{"remote_addr":"172.21.0.1","x_forwarded_for":null}

Significado: La app remota ve la IP SNAT del gateway, no el host original.
Decisión: Si la app remota necesita identidad por cliente, no SNATees todo a una IP. Usa mapeo 1:1 o un pool SNAT y actualiza listas de permitidos en consecuencia.

Tarea 13: Valida policy routing cuando debes mantener simetría en el tráfico NATeado

cr0x@server:~$ ip rule show
0:      from all lookup local
100:    from 10.0.1.0/24 to 172.22.0.0/16 lookup 100
32766:  from all lookup main
32767:  from all lookup default

cr0x@server:~$ ip route show table 100
172.22.0.0/16 dev wg0 scope link

Significado: El tráfico desde la subred local al CIDR remoto traducido se fuerza a la tabla 100, que lo enruta por el túnel.
Decisión: Si tienes múltiples WANs o múltiples túneles, así es como mantienes caminos de retorno consistentes y evitas pérdida de estado NAT.

Tarea 14: Revisa contadores de firewall para probar qué está descartando

cr0x@server:~$ sudo iptables -vnL FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in  out source        destination
 812K  92M ACCEPT     all  --  eth0 wg0 10.0.1.0/24  172.22.0.0/16
 221K  21M ACCEPT     all  --  wg0 eth0 172.22.0.0/16 10.0.1.0/24
  512  42K DROP       all  --  *   *   0.0.0.0/0     0.0.0.0/0

Significado: El reenvío está permitido en ambas direcciones para esos CIDR, y los contadores incrementan. También hay un drop por defecto.
Decisión: Si los contadores de las reglas ACCEPT se quedan en cero mientras pruebas, tu tráfico no llega a esta caja o no coincide con los CIDR que crees (mismatch de traducción, interfaz equivocada, ruta equivocada).

Tarea 15: Confirma que el remoto tiene una ruta de vuelta a tu espacio traducido

cr0x@server:~$ ip route get 172.21.1.50
172.21.1.50 dev wg0 src 10.200.0.2 uid 0
    cache

Significado: El remoto sabe devolver a 172.21.0.0/16 vía la interfaz del túnel.
Decisión: Si el remoto intenta enviar 172.21.0.0/16 a su gateway por defecto en su lugar, tendrás tráfico unidireccional y culparás al NAT. Añade la ruta.

Guion de diagnóstico rápido

Este es el orden que te lleva al cuello de botella más rápido, sin realizar interpretación NAT en un bridge de incidente en vivo.

Primero: prueba que el túnel y el enrutamiento son reales

1. Salud VPN: handshake/SA establecido, bytes incrementando. Si no, detente.
2. Rutas: cada lado tiene una ruta al CIDR traducido vía el túnel. Sin ruta, sin camino de retorno, sin alegría.
3. Reenvío y firewall: ip_forward=1; la cadena de forwarding permite tráfico; los contadores se mueven.

Segundo: prueba que la traducción está ocurriendo realmente

1. tcpdump en ambas interfaces: ver la tupla original en LAN y la tupla traducida en el túnel.
2. entrada conntrack existe: confirma el estado NAT para el flujo.
3. El remoto ve la fuente esperada: valida con un endpoint simple o logs del servidor.

Tercero: encuentra los problemas de “hace ping pero no funcionan las apps”

1. MTU/MSS: haz pings DF; vigila bloqueos en TLS/HTTP POST.
2. DNS: confirma que los nombres resuelven a las direcciones traducidas (o proporciona split-horizon).
3. Listas de permitidos/autenticación: verifica si el lado remoto espera IPs reales de clientes; NAT puede colapsarlas.

Cuarto: busca problemas de escala y envejecimiento

1. capacidad y timeouts de conntrack bajo carga.
2. CPU softirq / caídas en NIC en gateways (saturación de interrupciones parece pérdida de paquetes).
3. Comportamiento HA en failover: pérdida de estado y rutas asimétricas tras un failover.

Errores comunes: síntomas → causa raíz → solución

1) “Puedo hacer ping, pero TCP hace timeout”

Síntomas: ICMP funciona, peticiones pequeñas funcionan, subidas o handshakes TLS se quedan colgados.

Causa raíz: problemas MTU/PMTUD por encapsulación; ICMP “frag needed” bloqueado; falta de clamp MSS.

Solución: clampa MSS en tráfico sobre el túnel, establece MTU correcto en la interfaz de túnel, permite ICMP necesario.

2) “Funciona desde el gateway, no desde hosts detrás”

Síntomas: El gateway alcanza el servicio remoto, los hosts internos no.

Causa raíz: reglas FORWARD faltantes, SNAT faltante para tráfico reenviado o ruta de retorno faltante para la subred cliente traducida.

Solución: habilitar forwarding, añadir reglas de forward, implementar SNAT y añadir ruta remota de vuelta al rango cliente traducido.

3) “Un sentido funciona; el inverso falla”

Síntomas: A→B funciona, B→A falla (o viceversa). O los SYN salen, SYN/ACK nunca completa.

Causa raíz: enrutamiento asimétrico entre gateways HA o múltiples WANs; el estado conntrack existe solo en un nodo.

Solución: hacer enrutamiento simétrico con policy routing; usar active/standby; considerar sincronización de estado conntrack si realmente necesitas active/active.

4) “La app remota devuelve 403/no autorizado tras cambio NAT”

Síntomas: La conectividad de red está bien; la aplicación niega acceso.

Causa raíz: las listas de permitidos basadas en IP ahora ven la IP del gateway NAT, no los clientes originales.

Solución: actualizar listas de permitidos; usar traducción 1:1 o pools SNAT; mover la verificación de identidad arriba en la pila cuando sea posible.

5) “Algunos hosts son alcanzables, otros no”

Síntomas: Un subconjunto de hosts remotos funciona; otros son agujeros negros.

Causa raíz: solapamiento parcial; netmapping incorrecto o incompleto; existen rutas para algunos rangos traducidos pero no para otros.

Solución: mapear determinísticamente y cubrir todo el rango previsto; auditar rutas en ambos lados; evita mezclar segmentos enrutados y NATeados sin documentación sólida.

6) “Tras un failover, todo rompe hasta que reiniciamos cosas”

Síntomas: Evento HA causa timeouts generalizados; eventualmente se recupera tras expirar sesiones o reiniciar servicios.

Causa raíz: estado conntrack/NAT perdido durante el failover; sesiones de larga duración no se reestablecen limpiamente.

Solución: prefiere active/standby con enrutamiento estable; acorta keepalives; acepta que algunas sesiones caerán y diseña reintentos; añade procedimientos de drenado controlado.

7) “DNS resuelve, pero las conexiones van al lugar incorrecto”

Síntomas: El cliente resuelve un nombre remoto, pero alcanza un host local con la misma IP o servicio equivocado.

Causa raíz: DNS devuelve la dirección real (solapada); el enrutamiento local prefiere la subred local.

Solución: DNS split-horizon o reenvío condicional que devuelva direcciones traducidas; no filtres IPs solapadas a través de la frontera.

8) “Antes funcionaba; ahora cae bajo carga”

Síntomas: Fallos intermitentes en picos; logs muestran fallos de inserción en conntrack o descartes.

Causa raíz: agotamiento de la tabla conntrack; capacidad NAT insuficiente; saturación de softirq CPU.

Solución: aumenta nf_conntrack_max, ajusta timeouts, escala recursos del gateway y mide descartes en NIC y capa kernel.

Listas de verificación / plan paso a paso

Paso a paso: un despliegue sensato de NAT sobre VPN

1. Inventario del espacio de direcciones en ambos lados: CIDR reales, rangos DHCP, bloques estáticos y redes “misteriosas” de laboratorio.
2. Elige CIDR traducidos que no colisionen con ninguno de los lados, con espacio para crecer. Escríbelos en un lugar compartido.
3. Decide la dirección de traducción: unidireccional o bidireccional. Por defecto, opta por bidireccional solo si realmente lo necesitas.
4. Decide la granularidad de la traducción:
   • Mapeo 1:1 para preservar identidad por host
   • many-to-one SNAT para simplicidad (acepta pérdida de identidad)
5. Implementa rutas a los CIDR traducidos en ambos lados (estáticas, o vía tu sistema de enrutamiento si procede).
6. Implementa reglas NAT con coincidencia explícita: CIDR origen, CIDR destino, interfaces de entrada/salida.
7. Implementa reglas de firewall como si NAT no existiera: permite solo puertos/servicios requeridos a través de CIDR traducidos.
8. Arregla DNS: split-horizon, reenvío condicional u overrides explícitos por host para nombres traducidos. Si el DNS está mal, todo parece estar mal.
9. Maneja MTU: configura MTU del túnel y clampa MSS si hace falta. Prueba con pings DF y flujos reales de aplicaciones.
10. Registra la traducción: conserva logs NAT/firewall (con limitación de tasa) y mantén visibilidad de tuplas pre y post-NAT.
11. Prueba la carga de conntrack: confirma margen bajo pico esperado con factor de ráfaga.
12. Escribe y ensaya una reversión: eliminar NAT rara vez es instantáneo; planea “deshabilitar NAT, mantener túnel” y “deshabilitar túnel”.

Checklist pre-cambio (qué verificar antes de activarlo)

• Los CIDR traducidos no aparecen en ip route en ninguno de los lados excepto las rutas VPN previstas.
• Respuestas DNS condicionales devuelven direcciones traducidas al sitio opuesto.
• La política por defecto del firewall es explícita y probada.
• MTU/MSS probados con tamaños de carga reales (no solo ping).
• Dimensionamiento de conntrack verificado; existe monitorización de nf_conntrack_count y contadores de drop.

Checklist post-cambio (qué comprobar inmediatamente después)

• tcpdump confirma direcciones pre/post NAT en las interfaces correctas.
• Los logs remotos muestran las direcciones origen esperadas (y los controles de seguridad aún coinciden).
• Resolución DNS desde ambos lados devuelve la vista correcta.
• Las sesiones de larga duración (BD, brokers) se mantienen al menos una hora sin caídas.
• El on-call tiene un runbook de una página con CIDR traducidos y comandos de prueba.

Preguntas frecuentes

1) ¿Puedo evitar NAT añadiendo rutas más específicas?

No cuando el solapamiento es exacto o ambiguo. Si ambos lados tienen 10.0.1.0/24, una ruta no te dice cuál 10.0.1.50 querías. Necesitas unicidad—o renumerar o traducir.

2) ¿NAT sobre VPN es lo mismo que NAT-T?

No. NAT-T (NAT Traversal) es una técnica para permitir que IPsec funcione a través de dispositivos NAT encapsulando en UDP. NAT-sobre-VPN es cuando intencionalmente traduces direcciones a través de un túnel para resolver solapamientos.

3) ¿Debo usar SNAT, DNAT o mapeo 1:1?

Si necesitas que el lado remoto distinga hosts (listas de permitidos, registros, políticas por host), usa mapeo determinista 1:1. Si solo necesitas “clientes pueden alcanzar servicio”, SNAT a una IP es más simple pero oculta identidad.

4) ¿Dónde debe vivir el NAT?

En el gateway VPN, salvo que tengas una razón contundente para no hacerlo. Centralizar NAT reduce la deriva de configuración y hace coherentes las capturas de paquetes y la política de firewall.

5) ¿Cómo manejo DNS con direcciones traducidas?

Usa DNS split-horizon: cada sitio obtiene respuestas que tienen sentido para su vista. Si Sitio A debe alcanzar Sitio B vía 172.22.0.0/16, el DNS de Sitio A debe devolver 172.22.x.y para nombres de Sitio B.

6) ¿NAT romperá mutual TLS o la validación de certificados?

No directamente—TLS no se preocupa por la IP origen. Pero si tus políticas de autorización (fuera de TLS) usan listas de permitidos por IP, NAT cambia la identidad que el remoto ve.

7) ¿Puedo ejecutar gateways NAT active/active para alta disponibilidad?

Puedes, pero con cuidado. Sin sincronización de estado y enrutamiento simétrico, romperás flujos. Active/standby es operativamente más simple para NAT con estado, y “más simple” es una característica.

8) ¿Por qué funciona para algunas apps y no para otras?

Normalmente por una de tres razones: problemas MTU, DNS que devuelve IPs reales (solapadas) o una aplicación que incrusta IPs / espera la IP cliente para autorización.

9) ¿IPv6 es la solución real?

IPv6 reduce la escasez de direcciones y la presión de solapamiento, pero no arregla mágicamente dispositivos IPv4-only existentes, appliances de proveedores o tu cronograma de M&A. Es una estrategia, no la mitigación de hoy.

10) ¿Cuál es la mejor forma de documentar NAT sobre VPN para que la gente deje de romperlo?

Un diagrama que muestre CIDR reales y traducidos, una tabla de reglas NAT en lenguaje llano y un pequeño conjunto de pruebas con resultados esperados. Además: pon los rangos traducidos en IPAM si tienes uno.

Conclusión: próximos pasos que realmente reducen el riesgo

NAT sobre VPN es una solución perfectamente respetable para redes solapadas—si la tratas como un diseño de primera clase y no como un parche temporal que mágicamente se mantiene temporal.
El trabajo no es solo reglas NAT. Es simetría de enrutamiento, corrección de DNS, manejo de MTU, logging y planificación de capacidad para el estado.

Pasos prácticos siguientes:

1. Anota los CIDR traducidos y resérvalos como espacio de direcciones real.
2. Elige un modelo de traducción (1:1 vs many:1) según necesidades de identidad, no por conveniencia.
3. Construye una suite de pruebas mínima: ping con DF, conexión TCP, una petición HTTP real y una prueba de sesión de larga duración.
4. Añade monitorización para utilización de conntrack, descartes de paquetes y contadores de bytes de la VPN.
5. Realiza un drill de failover si tienes HA. Si no, admítelo y planifica expectativas de downtime en consecuencia.

Si puedes renumerar después, hazlo. Pero si no puedes, haz que NAT-sobre-VPN sea aburrido, predecible y bien iluminado. Tus futuros incidentes seguirán ocurriendo—solo con menos misterios y menos gente gritando a las capturas de paquetes.