Subredes superpuestas entre oficinas: 3 soluciones efectivas sin renumerar

Qué rompe realmente “subredes superpuestas” (y por qué)

Las subredes superpuestas no son «un problema de enrutamiento» en abstracto. Son un problema de colisión de nombres con consecuencias reales. Si ambas oficinas tienen 10.10.0.0/16 y tratas de enrutar entre ellas, un host en el Sitio A no puede distinguir «10.10.1.20 en Sitio A» de «10.10.1.20 en Sitio B». Tus routers tampoco pueden: al menos no con la semántica clásica de enrutamiento IP.

Qué verás en producción

• Alcance asimétrico: A puede alcanzar a un servidor de B a veces; las respuestas desaparecen porque la ruta de retorno resuelve al gemelo local.
• Mentiras de ARP y cachés de vecinos: En extensiones L2 (por favor, no lo hagas), aparecen flaps de MAC y registros de «IP duplicada» porque la misma IP existe dos veces.
• Ambigüedad en políticas NAT/Firewall: «Permitir 10.10.1.0/24» se vuelve una moneda al aire a menos que seas explícito sobre qué 10.10.1.0/24 quieres.
• DNS lo empeora: Si ambos sitios publican nombres internos en la misma zona, obtienes respuestas «correctas» apuntando al gemelo equivocado.
• La monitorización se vuelve ficción: Tu NMS hace ping a 10.10.1.20 y piensa que el sistema remoto está arriba —porque hizo ping al local.

La respuesta humana habitual es la negación. La red está «arriba» porque el túnel muestra verde. Pero la superposición no mata el túnel; mata el significado. Y los sistemas funcionan con significado.

Consejo con opinión: No intentes «hacer que el enrutamiento prefiera el sitio remoto». No puedes salir de una colisión de espacios de nombres únicamente con enrutamiento sin añadir un nuevo espacio de nombres (NAT, VRF u overlay).

Guía de diagnóstico rápido (chequeos primero/segundo/tercero)

Este es el camino más rápido para identificar el cuello de botella y elegir el arreglo menos malo. Si haces esto en orden, dejarás de discutir en base a sensaciones.

1) Confirma que la superposición es real (no solo un bloqueo de firewall)

Elige una «IP problemática» y verifica si existe en ambos lugares. Revisa tablas ARP, concesiones DHCP o el comportamiento local de ping.

• Si un host hace ping a «remoto» 10.x.x.x incluso cuando la VPN está abajo, no estás alcanzando nada remoto. Estás golpeando al gemelo local.
• Si traceroute nunca entra al túnel y se queda dentro del sitio, estás enroutando localmente hacia la red gemela.

2) Identifica qué debe comunicarse entre sitios (y qué puede ignorarse)

Inventaría los flujos: AD, DNS, servicios de archivos, ERP, VoIP, subredes de impresoras, RDP/SSH, monitorización, replicación de backups. Luego ordénalos por impacto de negocio y bidireccionalidad requerida.

• Protocolos bidireccionales (SMB, AD, Kerberos, VoIP) toleran menos los apaños.
• Accesos unidireccionales (usuarios a una app web) a menudo se resuelven antes con NAT.

3) Revisa dónde se puede aplicar política: firewall de borde, router core o hosts

Tu mejor solución depende de dónde puedas controlar el espacio de nombres y la selección de rutas.

• Si controlas ambos bordes: NAT o VRF suelen ser lo más rápido.
• Si controlas solo un lado (socio, proveedor, sitio adquirido aún “independiente”): NAT es tu palanca.
• Si necesitas escalar multi-sitio a futuro: el overlay es caro pero limpio.

Una vez sepas (a) el alcance de la superposición, (b) los flujos requeridos y (c) tus puntos de control, puedes elegir una solución sin convertir tu VPN en una casa encantada.

Tres soluciones funcionales (sin rehacer)

Las tres soluciones añaden un nuevo límite de espacio de nombres para que las direcciones idénticas dejen de colisionar. Diferencian en dónde vive ese límite y cuánta deuda operativa aceptas.

Matriz de decisión (qué elegir y cuándo)

• Elige NAT cuando necesitas resultados rápidos, toleras la traducción de direcciones y tu objetivo principal es «usuarios aquí alcanzan servidores allá».
• Elige VRFs cuando necesitas separación limpia, tienes buen equipo de enrutamiento y deseas mínima rareza por traducción.
• Elige un overlay cuando necesitas conectar muchos sitios o integrar nube/on-prem de forma limpia y estás harto de parches.

También puedes combinarlas. En la vida real a menudo lo harás. Solo no apiles abstracciones sin pensar. Cada capa añadida es un lugar más donde las mentiras de las 3 a.m. pueden esconderse.

Solución 1: NAT (o hacer que el otro sitio parezca distinto)

NAT es la herramienta tosca que funciona porque cambia el espacio de nombres. Si el Sitio B tiene 10.10.0.0/16 en conflicto con Sitio A, puedes mapear Sitio B a un rango «virtual» —por ejemplo 172.20.10.0/24 o 100.64.10.0/24— solo a través del túnel. Para Sitio A, Sitio B ya no es 10.10.0.0/16. Problema resuelto, al menos para el enrutamiento IP.

Dos patrones de NAT que realmente funcionan

• NAT estático bidireccional (1:1 o muchos:muchos): Lo mejor cuando los servidores deben ser alcanzables desde ambos lados con direcciones estables.
• Source NAT (SNAT) en una dirección: Lo mejor cuando solo un lado inicia conexiones y puedes mantener al lado remoto mayormente sin enterarse.

Dónde debe ir NAT: en el dispositivo límite que también participa en la VPN (firewall/router). No disperses reglas NAT en saltos internos al azar a menos que disfrutes depurar tablas de estado en múltiples cajas.

Qué rompe NAT (planifica esto)

• ACLs basadas en IP y allowlists: Los sistemas remotos verán direcciones traducidas. Actualiza políticas o usa mapeos consistentes.
• Protocolos que incrustan IPs: Algunas apps legadas, SIP sin helpers adecuados, ciertos modos FTP. Los stacks modernos son mejores, pero no supongas.
• Casos límite de Kerberos/AD: AD puede funcionar a través de NAT, pero debes tener cuidado con resolución de nombres, SPNs y topología de sitio. Si puedes evitar NAT en el medio de replicación DC a DC, hazlo.

Broma #1: NAT es como poner etiquetas a gemelos idénticos—útil hasta que alguien decide cambiarse las camisetas por diversión.

Cuándo NAT es la mejor respuesta

Si estás en una fusión y necesitas «acceso a un puñado de sistemas» más que «una red empresarial perfectamente integrada», NAT es tu amiga. Compra tiempo. El tiempo es lo que gastas después en renumerar, segmentación o un overlay apropiado.

Qué evitar: «NAT temporal» que se vuelve permanente sin documentación. Si haces NAT, trátalo como un producto: mapas de traducción claros, subredes consistentes, registro y un plan de reversión.

Solución 2: VRFs / segmentación (mantener ambas verdades separadas)

Las VRF (instancias de enrutamiento virtual) te dan múltiples tablas de enrutamiento en el mismo hardware. Eso significa que puedes tener 10.10.0.0/16 en VRF-A y 10.10.0.0/16 en VRF-B, y no colisionarán porque viven en universos de enrutamiento distintos.

Las VRF son la solución «de adultos» cuando tienes control de enrutamiento y quieres preservar direcciones IP originales de extremo a extremo. También son la solución correcta cuando necesitas múltiples tenants superpuestos (común en MSSP, grandes empresas o fusiones transitorias).

Dos patrones de despliegue VRF

• VRF en el borde (recomendado): Coloca el sitio remoto en su propia VRF en el router/firewall de VPN. Importa/exporta solo las rutas necesarias.
• VRF en el core (cambio mayor): Si la superposición existe dentro de núcleos de campus, puede que necesites VRF más cerca de distribución para prevenir fugas.

Las VRF no lo solucionan todo mágicamente

Las VRF aíslan enrutamiento, no identidad. Si aún necesitas que apps en VRF-A hablen con hosts de misma dirección en VRF-B, necesitas un mecanismo de puente: route leaking con NAT, un proxy o cambios a nivel de aplicación. VRF es primero estrategia de contención, segundo de conectividad.

Consejo con opinión: Si tu objetivo es «conectar dos sitios superpuestos», VRF sola no lo hará a menos que también introduzcas alguna traducción o proxies de aplicación. Si tu objetivo es «conectar ambos sitios a servicios compartidos sin fusionarlos», VRF es perfecto. En la realidad corporativa, ese segundo objetivo aparece más a menudo de lo que la gente admite.

Modos de fallo a anticipar

• Errores al filtrar rutas: Una ruta por defecto filtrada y has creado un backhaul sorpresa.
• Deriva en políticas de seguridad: Los firewalls necesitan políticas conscientes de VRF. Si tu herramienta no lo es, los auditores aprenderán nuevas palabras.
• Huecos en herramientas operativas: NMS, logs de flujo y capturas de paquete deben estar acotados por VRF o depurarás fantasmas.

Solución 3: Redes overlay (enrutar por encima del lío)

Las overlays dan a los endpoints un nuevo espacio de direcciones (o una nueva identidad) independiente del underlay. Piensa en VXLAN/EVPN, direccionamiento de fabric SD-WAN, malla basada en WireGuard con «IPs overlay» asignadas, o incluso redes de aplicación L3. La idea es identidad consistente entre sitios sin importar qué hacen las subredes de underlay.

Si NAT es un destornillador y VRF es un cajón de herramientas, un overlay es todo un banco de trabajo nuevo. No es el arreglo más rápido, pero escala cuando añades más sitios, más nubes y más excepciones «temporales».

Patrones de overlay realistas sin rehacer todo

• Subnet overlay dedicada para servicios inter-sitio: No sobrepones todo—solo los servidores que deben ser accesibles entre sitios. Cada servidor recibe una IP adicional (o un loopback) en el rango overlay.
• Gateways de servicio: En lugar de tocar cada endpoint, despliegas gateways por sitio que anuncian rutas overlay y hacen proxy/enrutamiento hacia servicios locales.
• SD-WAN con segmentación: Muchos productos SD-WAN soportan LANs underlay superpuestas mapeándolas a segmentos VPN/VRF y anunciando rutas «virtuales» no superpuestas.

Qué te cuestan las overlays

• Complejidad operativa: Plano de control, cifrado, MTU, overhead de encapsulación y telemetría. Añades piezas móviles.
• Fragilidad de MTU: La encapsulación reduce la MTU efectiva. Si no pruebas PMTUD, romperás algo «al azar».
• Requisitos de habilidad: Tu equipo debe saber leer tablas de rutas, anuncios EVPN o estado de pares de malla, no solo «si el túnel está arriba».

Broma #2: Las overlays son geniales hasta que alguien dice «es solo networking» y luego cambia la MTU en un sitio.

Por qué las overlays suelen ser la mejor respuesta a largo plazo

Porque desacoplan la integración de negocio de la higiene IP. Puedes fusionar empresas, mover cargas y sobrevivir LANs heredadas imperfectas mientras sigues proporcionando conectividad consistente para lo importante. Si construyes una plataforma multi-sitio (no solo una fusión puntual), las overlays reducen la cantidad de «casos especiales» que haces por sitio.

Tres mini-historias corporativas desde el campo

1) El incidente causado por una suposición equivocada: «10.50.0.0/16 es único. Seguro.»

El equipo de integración conectó dos oficinas vía IPsec. Ambos lados tenían hojas de cálculo ordenadas. Ambos juraban que sus rangos internos eran «únicos». El túnel se levantó; la monitorización mostró verde. Todos se fueron a casa temprano, lo cual siempre es sospechoso.

Lunes por la mañana, el help desk recibió informes de que finanzas no podía alcanzar un servidor de reportes. El servidor estaba «arriba», los logs del firewall mostraban aceptaciones y el equipo de la app aseguraba que el servicio no había cambiado. El equipo de red hizo un traceroute desde una estación de trabajo. Nunca tocó la VPN. Se quedó local y terminó en un SVI de switch. Señal clásica: la ruta a 10.50.12.40 era interna, no remota.

Resultó que ambos sitios usaban 10.50.0.0/16. El servidor de reportes estaba en Sitio B, pero Sitio A tenía una impresora con la misma IP en una VLAN olvidada. La impresora ni siquiera estaba rota; simplemente respondía a ICMP como una mentirosa alegre. La prueba de «esto hace ping» fue inútil.

El arreglo no fue heroico. Añadieron un mapeo NAT para el puñado de servidores críticos en Sitio B hacia un rango de traducción 172.20.50.0/24, actualizaron DNS para esos servicios y dejaron de intentar enrutar la superposición directamente. La lección: las suposiciones sobre unicidad de IP envejecen mal, especialmente tras adquisiciones.

2) La optimización que salió mal: comprimir rutas y «simplificar» políticas

Otra compañía intentó ser lista. Tenían superposición en 192.168.1.0/24 y 192.168.2.0/24 en varias sucursales. En lugar de traducciones cuidadosas por subred, resumieron políticas y rutas para «simplemente permitir 192.168.0.0/16 a través del túnel». El rendimiento de la VPN mejoró ligeramente. Su cambio fue aprobado en tiempo récord, que debería haber sido una segunda pista.

En horas, rarezas: sesiones RDP se conectaban a máquinas equivocadas. Escáneres de activos «encontraron» dispositivos que no existían. Peor aún, una sucursal ahora podía alcanzar interfaces de administración de otra sucursal porque la regla gruesa lo permitía. Nada explotó de inmediato, que es como los problemas de seguridad se introducen a menudo—de forma silenciosa.

El fallo no fue que la summarización sea siempre mala. Fue que resumir espacios superpuestos elimina los últimos bits de especificidad que tenías. Habían cambiado corrección por conveniencia. Cuando existe superposición, la especificidad es tu cinturón de seguridad.

Revirtieron, luego reconstruyeron con pools NAT explícitos por sucursal y objetos de firewall por subred traducida. Tomó más tiempo. También detuvo el fenómeno de «RDP teletransportado», que no es una característica.

3) La práctica aburrida pero correcta que salvó el día: traducción determinista + arnés de pruebas

En una empresa grande, el plan de fusión fue realista: «No renumeraremos ninguna de las dos compañías por al menos 18 meses». Implementaron un esquema NAT determinista: cada sitio recibió un /16 traducido del rango 100.64.0.0/10 (espacio CGNAT), derivado de un ID de sitio. Lo documentaron como un producto: tablas de mapeo, reglas DNS, convenciones de nombres en objetos de firewall y un pequeño job de CI que validaba que ningún par de sitios se asignara rangos traducidos superpuestos.

Luego hicieron lo poco glamoroso: un arnés de pruebas. Un par de hosts Linux en cada sitio ejecutaban pings programados, handshakes TCP y consultas DNS a una lista de IPs de servicios traducidos. Los resultados iban a un dashboard con latencia, pérdida de paquetes y «tiempo de primera falla». Nada mágico. Solo instrumentación.

Seis meses después, un cambio de ISP introdujo una regresión de MTU que solo rompió SMB sobre el túnel (ICMP seguía funcionando, claro que sí). El arnés lo detectó en minutos. El equipo ajustó el MSS en el borde de la VPN y evitaron una caída de un día para servicios de archivos.

Nadie recibió un trofeo por ello. Pero tampoco pasaron el fin de semana en una sala de guerra, que es el mejor premio.

Tareas prácticas: comandos, salidas y decisiones

No puedes arreglar lo que no puedes demostrar. A continuación hay tareas reales que puedes ejecutar desde hosts Linux y sistemas típicos de red. Cada una incluye: el comando, qué significa la salida y la decisión que tomas a partir de ello.

Tarea 1: Demuestra que la “IP remota” es en realidad local (chequeo ARP)

cr0x@server:~$ ip neigh show 10.10.1.20
10.10.1.20 dev eth0 lladdr 3c:52:82:aa:bb:cc REACHABLE

Significado: Tu host cree que 10.10.1.20 está en el segmento L2 local (tiene una MAC en eth0). Eso no puede ser un host enrutado remoto a través de una VPN.

Decisión: Deja de depurar el túnel. Tienes superposición (o una misconfiguración de proxy ARP). Planea NAT/VRF/overlay.

Tarea 2: Confirma qué ruta gana para el destino superpuesto

cr0x@server:~$ ip route get 10.10.1.20
10.10.1.20 dev eth0 src 10.10.1.100 uid 1000
    cache

Significado: El kernel enruta 10.10.1.20 por eth0 localmente.

Decisión: Si esperabas la VPN, necesitas un nuevo límite de espacio de nombres; no puedes «hacer política de rutas» si el destino existe localmente.

Tarea 3: Traceroute para ver si el tráfico entra alguna vez en el camino VPN

cr0x@server:~$ traceroute -n 10.10.1.20
traceroute to 10.10.1.20 (10.10.1.20), 30 hops max, 60 byte packets
 1  10.10.1.1  0.412 ms  0.381 ms  0.372 ms
 2  10.10.1.20  0.663 ms  0.631 ms  0.612 ms

Significado: Dos saltos, completamente local. No cruza un túnel.

Decisión: No cambies selectores de VPN aún. Primero resuelve la superposición.

Tarea 4: Verifica que la interfaz VPN exista y esté UP (chequeo de sanidad, no victoria)

cr0x@server:~$ ip link show dev wg0
6: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Significado: La interfaz está arriba. Esto no dice nada sobre el enrutamiento correcto para destinos superpuestos.

Decisión: Procede a verificación de enrutamiento/NAT/VRF; no declares éxito.

Tarea 5: Revisa salud de peers de WireGuard (ejemplo overlay/malla)

cr0x@server:~$ sudo wg show
interface: wg0
  public key: qXn2mB3lP9z2gJw8v7m9Zk1a2b3c4d5e6f7g8h9i=
  listening port: 51820

peer: lH8k1m2n3b4v5c6x7z8a9s0d1f2g3h4j5k6l7p8o9=
  endpoint: 203.0.113.10:51820
  allowed ips: 100.64.10.0/24
  latest handshake: 32 seconds ago
  transfer: 1.24 MiB received, 2.88 MiB sent

Significado: El peer está vivo, allowed IPs define el rango de rutas overlay.

Decisión: Si la superposición persiste, asegúrate de enrutar a IPs overlay, no a los duplicados del underlay.

Tarea 6: Valida que DNS apunte a direcciones traducidas/overlay, no al underlay en conflicto

cr0x@server:~$ dig +short reports.internal.example A
172.20.50.40

Significado: El nombre resuelve a una dirección traducida no superpuesta (buen indicio para integración basada en NAT).

Decisión: Si devuelve 10.50.12.40 y eso está en superposición, arregla DNS split-horizon o crea registros específicos para la integración.

Tarea 7: Verifica que NAT esté ocurriendo (vista conntrack)

cr0x@server:~$ sudo conntrack -L -p tcp --dport 443 | head
tcp      6 431999 ESTABLISHED src=10.10.1.100 dst=172.20.50.40 sport=51922 dport=443 src=10.10.1.100 dst=10.50.12.40 sport=51922 dport=443 [ASSURED] mark=0 use=1

Significado: El destino original es 172.20.50.40, pero está siendo DNATeado a 10.50.12.40 en el lado lejano (o viceversa según la colocación). La tupla muestra la traducción.

Decisión: Si no aparecen entradas conntrack durante una prueba, la regla NAT no está haciendo match o el tráfico no llega al traductor.

Tarea 8: Confirma que las reglas iptables NAT coinciden con lo que crees

cr0x@server:~$ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A PREROUTING -i wg0 -d 172.20.50.40/32 -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.50.12.40:443
-A POSTROUTING -o wg0 -s 10.50.12.40/32 -p tcp -m tcp --sport 443 -j SNAT --to-source 172.20.50.40

Significado: NAT bidireccional determinista para un servicio (443). DNAT entrante, SNAT saliente.

Decisión: Mantén NAT simétrico para protocolos con estado. Si solo DNATeas en una vía, el tráfico de retorno puede enrutar al gemelo local y morir.

Tarea 9: Revisa problemas MTU/MSS que se hacen pasar por “problemas de superposición”

cr0x@server:~$ ping -M do -s 1372 172.20.50.40 -c 3
PING 172.20.50.40 (172.20.50.40) 1372(1400) bytes of data.
1372 bytes from 172.20.50.40: icmp_seq=1 ttl=61 time=18.4 ms
1372 bytes from 172.20.50.40: icmp_seq=2 ttl=61 time=18.1 ms
1372 bytes from 172.20.50.40: icmp_seq=3 ttl=61 time=18.3 ms

--- 172.20.50.40 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Significado: Paquetes de 1400 bytes pasan sin fragmentación. Bueno para muchas configuraciones VPN/overlay.

Decisión: Si esto falla pero pings pequeños funcionan, aplica MSS clamping en el borde y configura la MTU del túnel antes de culpar a NAT/VRF.

Tarea 10: Confirma por qué interfaz sale un paquete (útil con policy routing/VRFs)

cr0x@server:~$ ip rule show
0:      from all lookup local
1000:   from 10.10.1.0/24 lookup 100
32766:  from all lookup main
32767:  from all lookup default

Significado: Entra en juego el enrutamiento basado en fuente para 10.10.1.0/24 vía la tabla 100.

Decisión: Si la superposición te fuerza a trucos de policy routing, verifica que las redes origen sean únicas. El policy routing no soluciona destinos idénticos en el mismo segmento host.

Tarea 11: Inspecciona la tabla de enrutamiento alternativa para el dominio VRF/política

cr0x@server:~$ ip route show table 100
default via 100.64.10.1 dev wg0
100.64.10.0/24 dev wg0 proto kernel scope link src 100.64.10.2

Significado: La tabla 100 envía tráfico al overlay vía wg0.

Decisión: Si los servicios deberían usar IPs overlay, asegura que las fuentes correctas terminen en la tabla correcta; si no, filtrarán a main y golpearán gemelos locales.

Tarea 12: Detecta IPs duplicadas desde logs (cuando los usuarios juran que es “aleatorio”)

cr0x@server:~$ sudo journalctl -k | grep -i duplicate | tail -n 5
Dec 28 09:11:02 edge kernel: IPv4: martian source 10.10.1.20 from 10.10.1.1, on dev eth0
Dec 28 09:12:44 edge kernel: arp: 10.10.1.20 moved from 3c:52:82:aa:bb:cc to 00:11:22:33:44:55 on eth0

Significado: La misma IP se ve con MACs distintas. Eso es migración legítima (VM) o—más probable en este contexto—IPs duplicadas/superposición/fuga L2.

Decisión: Si ves movimientos de MAC entre sitios, detente. Puede que hayas puenteado L2 accidentalmente sobre WAN o extendido VLANs. Eso es otra emergencia.

Tarea 13: Verifica selección de camino del firewall con captura de paquetes (demuestra adónde va el tráfico)

cr0x@server:~$ sudo tcpdump -ni wg0 host 172.20.50.40 and tcp port 443 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
09:21:11.102334 IP 10.10.1.100.51922 > 172.20.50.40.443: Flags [S], seq 39184422, win 64240, options [mss 1360,sackOK,TS val 123 ecr 0], length 0
09:21:11.120118 IP 172.20.50.40.443 > 10.10.1.100.51922: Flags [S.], seq 91233110, ack 39184423, win 65160, options [mss 1360,sackOK,TS val 456 ecr 123], length 0

Significado: SYN/SYN-ACK visibles en la interfaz del túnel; el tráfico entra correctamente al overlay/VPN para la IP traducida.

Decisión: Si ves SYN saliendo pero ningún SYN-ACK regresando, sospecha NAT/política en el lado remoto, ruta de retorno o MTU. Si no ves nada en wg0, el enrutamiento está mal aguas arriba.

Tarea 14: Valida que «subredes de integración» no se solapen con nada más

cr0x@server:~$ ipcalc 172.20.50.0/24
Address:   172.20.50.0         10101100.00010100.00110010. 00000000
Netmask:   255.255.255.0 = 24  11111111.11111111.11111111. 00000000
Network:   172.20.50.0/24      10101100.00010100.00110010. 00000000
Broadcast: 172.20.50.255       10101100.00010100.00110010. 11111111
HostMin:   172.20.50.1         10101100.00010100.00110010. 00000001
HostMax:   172.20.50.254       10101100.00010100.00110010. 11111110
Hosts/Net: 254

Significado: Estás definiendo un segmento de traducción/overlay limpio.

Decisión: Pon estos rangos bajo control de cambios. Si otro equipo usa 172.20.50.0/24 localmente más adelante, volverás a introducir superposición—solo con números distintos.

Tarea 15: Prueba rápida a nivel de aplicación que evita las «mentiras de ping»

cr0x@server:~$ curl -skI https://172.20.50.40/ | head -n 5
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 28 Dec 2025 09:25:02 GMT
Content-Type: text/html
Connection: keep-alive

Significado: El servicio es accesible en la IP traducida/overlay. Esto es más significativo que ICMP.

Decisión: Si curl funciona pero la app falla, céntrate en DNS, certificados, SSO/identidad o políticas L7 del firewall—no en «la VPN».

Tarea 16: Confirma que la red local ya usa tu rango de traducción propuesto (chequeo «no seas listo»)

cr0x@server:~$ ip route show | egrep '172\.20\.50\.0/24|100\.64\.0\.0/10' || echo "no local routes found"
no local routes found

Significado: Tu rango de traducción/overlay elegido no aparece localmente en este host.

Decisión: Repite en routers core y fuentes DHCP/IPAM. Si el rango está en uso en algún sitio, elige otro ahora, no después del despliegue.

Errores comunes: síntomas → causa raíz → arreglo

1) «El túnel está arriba pero nada funciona»

Síntoma: VPN muestra conectada; pings a IPs “remotas” tienen éxito de forma inconsistente; traceroute se queda local.

Causa raíz: Subred superpuesta provoca que la ruta local/ARP gane; estás alcanzando gemelos locales.

Arreglo: Introduce un espacio de nombres no superpuesto (NAT/overlay) y usa DNS para dirigir clientes a direcciones traducidas.

2) «Algunas apps funcionan, SMB/VoIP no»

Síntoma: Apps web están bien; shares de archivos se cuelgan; transferencias grandes cuelgan; VoIP audio unidireccional.

Causa raíz: Problemas MTU/MSS por encapsulación VPN, frecuentemente revelados tras añadir overlays.

Arreglo: Ajusta MTU del túnel y aplica MSS clamping en bordes; verifica con pings sin fragmentar y pruebas reales de apps.

3) «Hicimos NAT y ahora el equipo remoto no nos puede whitelistear»

Síntoma: Políticas de seguridad remotas rechazan tráfico; logs muestran IPs origen inesperadas.

Causa raíz: SNAT cambia la identidad del cliente; las allowlists remotas estaban construidas para los rangos originales.

Arreglo: Usa rangos NAT deterministas por sitio, documéntalos y provee un CIDR fuente estable para whitelists.

4) «DNS es correcto pero los usuarios aún pegan al sistema equivocado»

Síntoma: El nombre resuelve a la IP traducida/overlay; aún así las conexiones caen en un host inesperado.

Causa raíz: Mismatch en DNS split-horizon, caches obsoletos o entradas hosts locales; a veces proxies PAC sortean tu plan.

Arreglo: Purga caches donde corresponda, audita DNS provisto por DHCP, elimina overrides en hosts y valida desde subredes cliente con dig/nslookup.

5) «La implementación de VRF rompió la monitorización y los logs»

Síntoma: NMS no puede alcanzar dispositivos; syslog se detiene; NetFlow falta para un segmento.

Causa raíz: Tráfico de herramientas vive en la VRF equivocada, o los colectores no son alcanzables vía route leaking.

Arreglo: Planifica explícitamente el plano de gestión: o filtras rutas para servicios de gestión o despliegas colectores por VRF/segmento.

6) «Resumimos rutas para simplificar y luego apareció acceso raro»

Síntoma: Usuarios alcanzan interfaces admin en otras sucursales; segmentación violada.

Causa raíz: Resumen excesivo de rutas y políticas a través de rangos superpuestos eliminó la especificidad necesaria.

Arreglo: Reintroduce especificidad: traducción por sitio, objetos por subred traducida y políticas least-privilege basadas en identidades traducidas/overlay.

7) «Los paquetes llegan pero las respuestas desaparecen»

Síntoma: SYN visto saliendo; no llega SYN-ACK; o la petición alcanza remoto pero la respuesta vuelve a la red gemela local.

Causa raíz: Enrutamiento asimétrico debido a NAT unidireccional, rutas de retorno faltantes o el lado remoto prefiriendo su ruta local superpuesta.

Arreglo: Asegura NAT simétrico (DNAT+SNAT) o fuerza rutas de retorno por el mismo túnel (selectores VPN basados en política o VPN basada en rutas con rutas correctas).

Listas de verificación / plan paso a paso

Checklist A: Elegir la solución en 30 minutos

1. Lista de flujos cruzados requeridos (subred origen → servicio destino → puertos → ¿bidireccional?).
2. Confirma el alcance de la superposición: prefijos exactos que colisionan (10.10.0.0/16 vs 10.10.0.0/16, etc.).
3. Identifica puntos de control: ¿gestionas ambos bordes? ¿Puedes cambiar DNS? ¿Puedes añadir gateways?
4. Elige el martillo más pequeño:
   • Necesitas acceso a servicios específicos rápidamente → NAT
   • Necesitas aislamiento y servicios compartidos sin fusión total → VRFs
   • Necesitas una tela multi-sitio escalable o integración en nube → overlay
5. Elige un espacio de integración no superpuesto y resérvalo (no «pidas prestado» un /24 al azar).

Checklist B: Plan de despliegue NAT que no termine en desastre

1. Diseña mapeos deterministas (bloques traducidos por sitio; evita soluciones únicas y desordenadas).
2. Decide direccionalidad:
   • Usuarios → servidores solo: SNAT puede ser suficiente.
   • Servicios bidireccionales: usa NAT estático simétrico.
3. Actualiza DNS para que los clientes usen IPs traducidas para nombres cross-site.
4. Actualiza políticas de firewall para permitir solo los rangos traducidos (least privilege, no «any any»).
5. Valida MTU/MSS en la ruta de túnel para los paquetes más grandes esperados.
6. Instrumenta: capturas en la interfaz VPN; probes TCP básicos; logs de hits NAT.
7. Documenta mapeos en un lugar autoritativo y somete cambios a revisión.
8. Plan de reversión: un toggle/commit revert único en el equipo de borde, más planificación de TTL de DNS.

Checklist C: Plan de despliegue VRF para contención y servicios compartidos

1. Define límites de VRF: qué VLANs/subredes pertenecen a cada VRF (local vs adquirido/remoto).
2. Adjunta WAN/VPN a la VRF para el dominio de enrutamiento del sitio remoto.
3. Planifica acceso a «servicios compartidos» (DNS, AD, logging, parcheo) vía route leaking controlado o proxies.
4. Actualiza políticas de seguridad para ser conscientes de VRF; verifica accesos del plano de gestión.
5. Prueba en laboratorio o sitio piloto con apps representativas (SMB, Kerberos, VoIP si aplica).
6. Operativiza: checks de monitorización por VRF, runbooks y procedimientos de captura de paquetes.

Checklist D: Plan de despliegue overlay cuando te canses de excepciones

1. Elige esquema de identidad overlay (per-site /24s, per-service /32s o asignaciones por host).
2. Decide estrategia de endpoints:
   • Dual-hosting de servidores críticos en overlay (más rápido para alcance limitado).
   • Desplegar gateways por sitio (menos cambios en endpoints).
3. Valida MTU extremo a extremo y configura MSS clamping donde haga falta.
4. Define enrutamiento: qué prefijos se anuncian dónde; evita anunciar superposiciones del underlay en el overlay.
5. Seguridad: trata el overlay como red de producción—logging, ACLs, rotación de claves, segmentación.
6. Migración: mueve un servicio a la vez; actualiza DNS; mide; y procede.

Una cita de fiabilidad para mantenerte honesto

La esperanza no es una estrategia. — General Gordon R. Sullivan

Hechos y contexto histórico (vale la pena conocer)

• RFC1918 (1996) creó rangos de direcciones privadas explícitamente para reducir consumo de IPv4—la superposición fue un efecto secundario aceptado, no un bug.
• NAT se popularizó a mediados de los 90 como respuesta práctica a la escasez de IPv4; también normalizó la idea de que «las direcciones pueden reescribirse» en tránsito.
• CGNAT (Carrier-Grade NAT) popularizó usar 100.64.0.0/10 como espacio compartido; las empresas ahora lo toman prestado internamente para traducción porque es menos probable que colisione con routers domésticos.
• Los conceptos VRF maduraron junto a MPLS VPNs; el mismo mecanismo que aísla clientes para carriers aísla tenants superpuestos en empresas.
• VPNs basadas en rutas (interfaces + enrutamiento) se volvieron dominantes sobre VPNs basadas en políticas porque escalan mejor, pero la superposición aún requiere un arreglo de espacio de nombres.
• EVPN/VXLAN overlays surgieron para resolver problemas de escala multi-tenant en datacenters; esos mismos patrones ahora aparecen en diseños de campus y sucursal.
• DNS split-horizon ha sido un truco estándar empresarial por décadas, pero se vuelve no opcional cuando direcciones traducidas/overlay difieren por sitio.
• Grandes empresas rutinariamente ejecutan múltiples «realidades» IP durante fusiones: espacio de direcciones original, espacio de integración traducido y espacio renumerado futuro—a menudo simultáneamente.

FAQ

1) ¿Puedo arreglar subredes superpuestas cambiando métricas de ruta o añadiendo rutas estáticas?

No de forma confiable. Si una subred existe localmente, tus hosts y routers preferirán la ruta conectada. Necesitas un límite de espacio de nombres: NAT, separación VRF u addressing overlay.

2) ¿Es NAT siempre la solución más rápida?

Por lo general, sí—especialmente para un conjunto limitado de servicios. Pero «rápido» no es «gratis». NAT añade estado de traducción, complejidad en políticas y hace la depuración más sutil. Si esperas integración profunda (AD, mucho este-oeste), considera planear VRF/overlay desde el inicio.

3) ¿Qué rango de traducción debería usar?

Elige un rango que sea improbable encontrar en cualquiera de las compañías y resérvalo centralmente. Muchos equipos usan 100.64.0.0/10 para traducción/overlay porque es menos común en LANs que 10/8. La clave es gobernanza: resérvalo, documéntalo y mantenlo fuera de ámbitos DHCP.

4) ¿Necesito NAT bidireccional?

Si ambos lados inician conexiones al mismo servicio, sí—planea DNAT/SNAT simétricos para que las rutas de retorno sean consistentes. Para acceso unidireccional «clientes a servidores», SNAT solo puede funcionar, pero aún debes asegurar que las respuestas vuelvan por el traductor.

5) ¿Las VRF solucionan la superposición sin NAT?

Las VRF previenen colisiones aislando dominios de enrutamiento, pero no permiten que dos direcciones idénticas se comuniquen directamente. Si VRF-A debe alcanzar un host en VRF-B que comparte la misma IP que algo en VRF-A, sigues necesitando traducción o un proxy.

6) ¿Cuál es el mayor riesgo con overlays?

MTU y complejidad operativa. La encapsulación reduce la MTU efectiva; si PMTUD falla, las apps fallan de formas extrañas. Además, las overlays añaden un plano de control que debe monitorizarse y entenderse.

7) ¿Cómo mantengo el DNS razonable durante esto?

Decide qué nombres deben resolverse a IPs traducidas/overlay y aplícalo con DNS split-horizon. Mantén TTLs bajos durante la migración. Y audita IPs codificadas—habrá algunas.

8) ¿Qué si solo un puñado de usuarios necesita acceso entre sitios?

Usa un jump host o proxy de aplicaciones en un segmento neutral y no superpuesto (o overlay). Limita el blast radius y reduce el número de flujos traducidos. No abras todo el espacio de direcciones «porque es más fácil».

9) ¿Esto afectará backups y replicación?

Sí, y a veces de formas sorprendentes. Herramientas de replicación pueden fijarse a IPs, imponer allowlists de origen o comportarse mal bajo NAT si incrustan direcciones. Prueba con tamaños de transferencia reales y mide throughput y errores antes de declarar victoria.

10) ¿Deberíamos planear renumerar eventualmente?

Sí, si quieres una vida más simple a largo plazo. Estas soluciones son válidas, pero introducen capas. Renumerar es doloroso; vivir con superposición permanente más NAT ad-hoc es peor.

Conclusión: próximos pasos que puedes ejecutar

Las subredes superpuestas no son raras; son el resultado por defecto de TI descentralizada más RFC1918 más tiempo. Lo que importa es cómo respondes. Si finges que es «solo un problema de enrutamiento», perderás días demostrando la misma falla de distintas formas.

Haz esto a continuación:

1. Ejecuta el diagnóstico rápido: ARP/ruta/traceroute para probar superposición e identificar qué flujos importan.
2. Elige una solución a propósito:
   • NAT para acceso rápido y enfocado en servicios.
   • VRFs para contención y servicios compartidos controlados.
   • Overlay para integración escalable y a prueba de futuro.
3. Reserva espacio de direcciones de integración (traducido/overlay), documéntalo y protégelo contra reutilización accidental.
4. Instrumenta desde el día uno: no solo «túnel arriba», sino probes de aplicación, chequeos MTU y capturas reproducibles.
5. Escribe el runbook mientras el dolor está fresco. El tú del futuro estará cansado y poco divertido.

Si debes elegir un enfoque para la mayoría de fusiones corporativas reales: empieza con NAT determinista para servicios críticos, luego pásate a VRF/overlay conforme aprendes qué significa realmente «integración» en tu entorno.