Tres oficinas. Cada una tiene su propio circuito de internet, sus particularidades locales y su propia persona que “solo necesita acceder al otro sitio”.
Configuras un VPN sitio-a-sitio, luego otro, y de repente estás malabareando rutas, reglas de firewall, rarezas de DNS y una impresora que solo falla los martes.
Un VPN full-mesh suena como la respuesta adulta: todos hablan con todos directamente. A veces lo es. A veces es una manera cara de crear
un generador distribuido de incidentes. Decidamos en qué mundo estás y cómo operarlo sin convertirte en la tabla de enrutamiento humana.
Qué significa realmente “full-mesh” para 3 oficinas (y qué no significa)
Con tres sitios—llamémoslos NYC, DAL, SFO—un full mesh significa que construyes
tres túneles sitio-a-sitio: NYC↔DAL, DAL↔SFO, SFO↔NYC. Cada sitio tiene un camino cifrado directo hacia los demás.
No hay enrutamiento por un hub central.
Esta es la parte que a los vendedores les gusta poner en un diagrama triangular bonito. En la vida real, un “full mesh” no son solo túneles. Es:
- Política de enrutamiento: qué prefijos se anuncian a dónde y qué gana cuando existen múltiples rutas.
- Política de seguridad: qué está permitido este-oeste entre oficinas.
- Política operativa: cómo se despliegan cambios sin romper la mitad de tu WAN.
- Identidad y nombres: DNS, split-horizon, topología de sitios de AD o lo que sea que haga tu pila de autenticación.
Para tres oficinas, un full mesh no es automáticamente “complejo”. Es fácil de volver complejo. Esa es la distinción que importa.
Matemáticas rápidas: por qué crece el dolor
El número de túneles en un full mesh es n(n−1)/2. Con 3 sitios: 3 túneles. Con 6 sitios: 15. Con 10 sitios: 45.
La mayoría de los equipos puede mantener 3 túneles saludables. Muchos equipos no pueden mantener 15 túneles consistentemente sin automatización y telemetría.
Hechos interesantes y un poco de historia (porque heredarás ideas viejas)
- Hecho 1: IPsec nació en los años 90 como parte de la historia de seguridad de IPv6, pero se adoptó mucho en IPv4 por… la realidad.
- Hecho 2: “NAT traversal” (UDP 4500) existe porque IPsec ESP no se llevaba bien con NAT; no fue un extra, fue supervivencia.
- Hecho 3: Muchos productos “site-to-site VPN” aún heredan una visión del mundo de los días de líneas arrendadas: endpoints estables, rutas previsibles, menos rekeys.
- Hecho 4: BGP se volvió el estándar para enrutamiento WAN dinámico no porque sea amigable, sino porque es brutalmente explícito sobre rutas y políticas.
- Hecho 5: El lío MTU/MSS en VPNs tiene décadas; no es un problema “era cloud”—PPP, GRE e IPsec ya dieron sus golpes.
- Hecho 6: DNS split-horizon es anterior al “zero trust”; es una herramienta antigua que sigue siendo relevante cuando diferentes redes necesitan respuestas distintas.
- Hecho 7: La gran ganancia de SD-WAN no fue el cifrado (los VPNs ya lo hacían); fue el control centralizado, la observabilidad y la selección de ruta ante pérdida/jitter.
- Hecho 8: Las topologías “full mesh” eran comunes en WAN corporativas tempranas usando Frame Relay PVC—hasta que todos recordaron la facturación y volvieron a hubs.
Cuándo necesitas realmente un full-mesh
Necesitas un full mesh cuando los caminos directos son materialmente mejores para tu negocio y no puedes lograr ese resultado de forma fiable con un hub-and-spoke.
“Materialmente mejor” significa latencia, ancho de banda, dominios de disponibilidad o aislamiento de fallos. No intuiciones.
1) Tu tráfico es genuinamente sitio-a-sitio, no sitio-a-datacenter
Si los usuarios en NYC constantemente acceden a servidores de archivos en DAL, y DAL constantemente a runners de build en SFO, enviar todo eso por un hub es
como enviar correo local por otro estado “para visibilidad”. Tu hub se convierte en un impuesto.
2) Necesitas aislamiento de fallos entre sitios
En un hub-and-spoke, el hub es un dominio de fallo compartido: DDoS en el circuito del hub, actualización del firewall del hub, mala política—todos lo sienten.
Una malla puede mantener NYC↔DAL vivo cuando SFO está teniendo un día emocionante.
3) Tienes múltiples circuitos de internet y quieres mejores opciones de ruta
Si cada oficina tiene su propio internet sólido, una malla permite que cada par use la mejor ruta entre ellos. Aún puedes hacer esto con un hub si
haces policy routing ingenioso y aceptas el hairpin, pero ya estás eligiendo complejidad—al menos obtén el beneficio de latencia.
4) Tienes requisitos regulatorios de segmentación entre sitios
Esto suena contradictorio (“malla = más confianza”), pero si lo haces bien, la malla puede reducir la exposición al no encauzar todo por un hub
donde se mezcla. Puedes aplicar políticas por pares: DAL puede alcanzar finanzas en NYC, pero no el laboratorio de NYC; SFO puede alcanzar SSO de NYC, pero no OT de DAL.
5) Puedes operarlo como un sistema, no como un proyecto puntual
Full mesh es un compromiso operativo. Si no tienes monitorización, versionado de configuración y un proceso de cambios, estás construyendo un triángulo bonito
que se volverá arte moderno la primera vez que alguien cambie un CPE de ISP.
Idea parafraseada (John Allspaw): la confiabilidad viene de cómo se hace el trabajo en condiciones reales, no de planes perfectos
.
Los mesh VPNs castigan el pensamiento de “plan perfecto”.
Cuándo full-mesh es la herramienta equivocada
La razón más común por la que los equipos eligen full mesh es emocional: “No quiero un hub”. Justo. Pero evitar un hub creando tres túneles independientes,
administrados de forma inconsistente, no es una estrategia. Es un pasatiempo.
No hagas full mesh si realmente tienes un sitio core
Si la mayor parte del tráfico es “sucursal a sistemas del HQ”, construye hub-and-spoke. Haz el hub redundante. Dale múltiples uplinks. Monitorízalo agresivamente.
Obtendrás políticas más simples y mejor control del blast-radius.
No hagas full mesh si no puedes estandarizar equipos y configuraciones
Si NYC ejecuta un appliance de firewall, DAL ejecuta una caja Linux que alguien llamó “vpn1” y SFO ejecuta un router cloud con un stack IKE distinto,
te estás inscribiendo para depurar tres dialectos del mismo protocolo. Eso no es ingeniería. Eso es lingüística.
No hagas full mesh si tu problema es “acceso remoto”
Site-to-site mesh es para redes. Acceso remoto es para personas y dispositivos. Si intentas resolver acceso de laptop-a-oficina haciendo malla de oficinas,
terminarás con una red perfectamente conectada que aún no sabe quién es el usuario.
Broma #1: Un full mesh es como un chat grupal—genial hasta que alguien agrega la impresora y de repente todos reciben notificaciones a las 3 a.m.
Opciones de diseño: IPsec, WireGuard, SD-WAN y “barato y eficaz”
Opción A: IPsec (IKEv2) sitio-a-sitio
IPsec es aburrido en el buen sentido: ampliamente soportado, interoperable, entendido por firewalls y generalmente aceptable para auditores.
También tiene muchas perillas que pueden perjudicarte: proposals, lifetimes, DPD, NAT-T, PFS, comportamiento de fragmentación y la “ayuda” del proveedor.
Si optas por IPsec, prefiere:
- IKEv2 sobre IKEv1. Menos fantasmas.
- Túneles basados en ruta (VTI) en lugar de policy-based cuando sea posible. El enrutamiento pertenece al enrutamiento.
- Propuestas consistentes en todos los túneles, idealmente una suite única que tus dispositivos soporten bien.
Opción B: WireGuard sitio-a-sitio
WireGuard es operativamente agradable: configuración mínima, rekey rápido y una filosofía fuerte de “hacer menos”. Tampoco es un protocolo de enrutamiento.
Aún necesitas decidir cómo se propagan las rutas y cómo evitar que AllowedIPs se convierta en tu tabla de enrutamiento global accidental.
Para tres sitios, WireGuard puede ser excelente si:
- Controlas ambos extremos (routers Linux o appliances que lo soporten bien).
- Puedes estandarizar la postura de firewall y la monitorización.
- Te sientes cómodo manejando el enrutamiento dinámico por separado (rutas estáticas o BGP/OSPF encima).
Opción C: SD-WAN (política gestionada + overlays)
SD-WAN es lo que compras cuando quieres menos redes a medida y más operaciones repetibles. Te da política centralizada, selección de ruta
y mejor observabilidad. Pagas en licencias y en que “el controlador ahora es parte de producción”.
Para tres oficinas, SD-WAN puede ser exceso—a menos que estés creciendo, tengas múltiples circuitos por sitio o necesites steering consciente de la aplicación.
Opción D: Hub-and-spoke con enrutamiento inteligente (a menudo el compromiso correcto)
Si quieres “mayormente directo” pero no la complejidad completa del mesh, haz hub-and-spoke con:
- Hubs redundantes (active/active o active/passive).
- BGP entre sitios y hubs.
- Política que prefiera breakout local para internet y prefiera el hub para servicios core.
Obtienes una topología manejable y aún evitas algo de hairpin para tráfico hacia internet.
Enrutamiento, DNS e identidad: dónde el full-mesh falla en la práctica
Modelo de enrutamiento: rutas estáticas vs enrutamiento dinámico
Para tres oficinas, las rutas estáticas pueden funcionar. También se pudren en silencio.
En el momento en que añades una nueva subred, cambias un rango LAN o introduces un segundo circuito, encontrarás el túnel que no se actualizó.
Eso no es hipotético. Es martes.
El enrutamiento dinámico (típicamente BGP) sobre túneles basados en ruta es la opción “adulta”:
- Las rutas se propagan automáticamente.
- Puedes expresar preferencia y política de failover.
- Puedes filtrar lo que cada sitio aprende (vital para segmentación).
Elegir el enfoque de enrutamiento para exactamente tres sitios
Aquí va la opinión:
- Rutas estáticas son suficientes si cada oficina tiene un prefijo LAN, no hay redes superpuestas y no añadirás sitios pronto.
- BGP vale la pena si alguna oficina tiene múltiples segmentos internos, quieres failover limpio o planeas crecer más allá de tres sitios.
DNS split-horizon: el requisito silencioso
La mayor parte del dolor inter-sede no es conectividad IP. Es resolución de nombres y descubrimiento de servicios:
- El DNS de NYC devuelve una IP interna que solo NYC puede alcanzar a menos que las rutas sean correctas.
- Clientes en DAL resuelven “fileserver” al sitio equivocado porque alguien configuró un search suffix y lo dio por terminado.
- Split tunneling a SaaS envía DNS a un lado y tráfico a otro, y entonces obtienes “funciona en mi teléfono”.
Decide si quieres:
- Una vista DNS interna única (todas las oficinas ven las mismas respuestas internas), o
- DNS consciente del sitio (las respuestas varían según el sitio de origen, usualmente para mantener a los clientes locales).
DNS consciente del sitio es poderoso. También es la forma en que accidentalmente construyes un sistema distribuido sin darte cuenta.
Subredes superpuestas: la mentira “eso nunca lo haremos”
Si alguna oficina usa espacio RFC1918 que se superpone con otra oficina—o con una red de un socio—vas a tener un mal rato.
Renumerar es doloroso, pero NAT-over-VPN es peor a largo plazo porque se filtra en configuraciones de aplicaciones y en la resolución de problemas.
Controles de seguridad que evitan que la malla sea un paraíso para el movimiento lateral
Un full mesh aumenta la conectividad. A los atacantes les encanta la conectividad.
Tu trabajo es asegurarte de que la malla aumente la conectividad intencional, no la confianza accidental.
Principio: enruta todo lo que necesites, permite casi nada por defecto
Enrutamiento y firewalling son capas diferentes. Puedes anunciar rutas ampliamente (por simplicidad) y aun así aplicar políticas estrictas en L3/L4.
O puedes filtrar rutas estrictamente y mantener las reglas de firewall más simples. Escoge uno como plano de control primario y sé consistente.
Controles básicos recomendados
- ACLs intersitio por zona (LAN de usuarios, LAN de servidores, gestión, voz, OT).
- Aislamiento del plano de gestión: las gateways VPN deben tener una interfaz o subred de gestión dedicada, no “admin desde cualquier lugar”.
- Logging de denegaciones a través del VPN, con muestreo o límites de tasa para no DDoS tu SIEM.
- Rotación de claves e higiene de certificados: los PSKs tienden a vivir para siempre; los certificados obligan a que los adultos aparezcan.
Patrón de segmentación que funciona
Usa zonas y listas de permiso explícitas:
- NYC-users → DAL-apps: permitir 443, 22 (solo a bastión), 445 (solo al clúster de archivos), denegar el resto.
- DAL-users → SFO-users: denegar (la mayoría de las organizaciones no necesitan “LAN de usuarios a LAN de usuarios”).
- Todos los sitios → monitoring: permitir solo hacia endpoints centrales de métricas/log.
Broma #2: Si permites “any-any” entre oficinas “solo por ahora”, felicitaciones—has inventado una máquina del tiempo donde “ahora” dura tres años.
Cómo mantenerlo manejable: nombres, automatización, monitorización, control de cambios
Estandariza los elementos primitivos
Escoge un modelo consistente y apégate a él:
- Túneles basados en ruta con VTIs nombradas de forma predecible (por ejemplo,
vti-nyc-dal). - Subredes consistentes por sitio (evita genialidades). Ejemplo: NYC=10.10.0.0/16, DAL=10.20.0.0/16, SFO=10.30.0.0/16.
- ASNs BGP consistentes si usas BGP: AS privadas por sitio, documentadas.
- Diseño consistente de zonas de firewall: usuarios, servidores, gestión, guest.
Haz las configuraciones comparables (diffable)
Si tu configuración de VPN vive solo en una UI web, no tienes gestión de configuración—tienes esperanza.
Exporta la config, guárdala en control de versiones y trata los cambios como código incluso si el “código” es la sintaxis del proveedor.
Monitorización: mide lo que se rompe primero
Los VPNs fallan de maneras aburridas:
- Pérdida de paquetes y jitter rompen voz/VDI antes de que “el túnel esté abajo”.
- Problemas de MTU rompen apps específicas (SMB, algunos HTTPS) mientras ping funciona.
- Rekeys provocan flap y causan microcortes que los usuarios describen como “aleatorios”.
Monitoriza:
- Estado del túnel (IKE SA, child SA, salud del handshake).
- Latencia/pérdida entre sitios (no solo hacia Internet).
- Throughput y drops en la interfaz VPN y en la interfaz WAN.
- Adyacencia de enrutamiento (sesión BGP up/down, cambios en recuento de rutas).
Control de cambios que no te odie
No necesitas burocracia. Necesitas un hábito:
- Haz cambios durante una ventana.
- Tén un plan de rollback real (config guardada, procedimiento probado).
- Cambia un túnel a la vez a menos que hagas un corte coordinado.
- Después del cambio: verifica enrutamiento, verifica DNS, verifica un flujo de aplicación real.
Guion de diagnóstico rápido
Cuando “el VPN está lento” o “sitio B no llega a sitio C”, no tienes tiempo para una discusión filosófica sobre topología.
Necesitas encontrar el cuello de botella rápido. Aquí está el orden que funciona en producción.
Primero: ¿es realmente el VPN?
- Comprueba si el problema es específico de la app (SMB vs HTTPS vs RDP).
- Comprueba si es solo en una dirección (enrutamiento asimétrico, estado de firewall).
- Comprueba si es solo un par de sitios (NYC↔DAL bien, DAL↔SFO roto).
Segundo: la salud del underlay (ruta ISP) gana a argumentos del overlay
- Mide pérdida y latencia entre endpoints públicos de las gateways VPN.
- Busca ráfagas de pérdida de paquetes, no promedios.
- Confirma que nadie está saturando el uplink (backups, sincronización cloud, reunión de video sorpresa).
Tercero: salud del túnel y cripto
- ¿El IKE SA es estable o está rekeyeando/flapeando?
- ¿Hay retransmisiones, drops por fragmentación, problemas NAT-T?
- ¿Está activo el offload de hardware (si es relevante), o una actualización de firmware lo deshabilitó?
Cuarto: enrutamiento y MTU (los dos asesinos silenciosos)
- Enrutamiento: verifica next-hop y asegúrate de que no haya loops hairpin.
- MTU: prueba con DF set; clampa MSS si hace falta.
Quinto: política (firewall) e identidad (DNS/AD)
- Denegaciones de firewall entre zonas. Busca denegaciones implícitas.
- DNS devolviendo objetivos inalcanzables; mapeos de sitios AD equivocados; split-brain DNS.
Tareas prácticas: comandos, salida esperada y qué decisión tomar
A continuación hay tareas prácticas que puedes ejecutar desde gateways VPN basados en Linux u hosts de diagnóstico en cada sitio.
El punto no es el comando; es el ciclo: observar → interpretar → decidir.
Tarea 1: Confirma la alcanzabilidad básica entre gateways de sitio (underlay)
cr0x@server:~$ ping -c 5 203.0.113.20
PING 203.0.113.20 (203.0.113.20) 56(84) bytes of data.
64 bytes from 203.0.113.20: icmp_seq=1 ttl=54 time=18.7 ms
64 bytes from 203.0.113.20: icmp_seq=2 ttl=54 time=19.1 ms
64 bytes from 203.0.113.20: icmp_seq=3 ttl=54 time=18.6 ms
64 bytes from 203.0.113.20: icmp_seq=4 ttl=54 time=120.3 ms
64 bytes from 203.0.113.20: icmp_seq=5 ttl=54 time=19.0 ms
--- 203.0.113.20 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 18.6/39.1/120.3/40.6 ms
Qué significa: Sin pérdida de paquetes, pero un pico de latencia sugiere jitter o congestión transitoria.
Decisión: Si los picos correlacionan con “VPN lento”, investiga la ruta del ISP, saturación o bufferbloat antes de tocar ajustes del VPN.
Tarea 2: Traza la ruta pública para detectar desvíos raros
cr0x@server:~$ traceroute -n 203.0.113.20
traceroute to 203.0.113.20 (203.0.113.20), 30 hops max, 60 byte packets
1 198.51.100.1 1.012 ms 0.941 ms 0.915 ms
2 198.51.100.9 3.122 ms 3.101 ms 3.094 ms
3 203.0.113.1 9.884 ms 9.860 ms 9.841 ms
4 203.0.113.20 18.992 ms 18.970 ms 18.948 ms
Qué significa: Ruta corta, saltos estables. Si ves rutas largas repentinas o timeouts, el underlay es sospechoso.
Decisión: Si la ruta cambió recientemente, abre un ticket con el ISP o cambia al circuito secundario si tienes uno.
Tarea 3: Revisa interfaces y contadores del túnel (salud del overlay)
cr0x@server:~$ ip -s link show dev vti-nyc-dal
6: vti-nyc-dal: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1436 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/none
RX: bytes packets errors dropped overrun mcast
987654321 1234567 0 12 0 0
TX: bytes packets errors dropped carrier collsns
876543210 1122334 0 0 0 0
Qué significa: Drops en RX del túnel apuntan frecuentemente a problemas de MTU, colas o denegaciones de política aguas arriba.
Decisión: Si los drops incrementan durante quejas, pasa a pruebas MTU/MSS y revisa logs del firewall para denegaciones en la VTI.
Tarea 4: Verifica ruta a una subred remota (corrección de enrutamiento)
cr0x@server:~$ ip route get 10.30.5.10
10.30.5.10 via 169.254.30.1 dev vti-nyc-sfo src 10.10.0.1 uid 0
cache
Qué significa: El kernel enviará tráfico a SFO vía el túnel NYC↔SFO.
Decisión: Si esto inesperadamente va vía DAL (hairpin), corrige la preferencia de enrutamiento (métricas/política BGP) antes de culpar a la aplicación.
Tarea 5: Detectar enrutamiento asimétrico (clásico “funciona en un sentido”)
cr0x@server:~$ tcpdump -ni vti-nyc-dal host 10.20.8.50 and tcp port 445 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vti-nyc-dal, link-type RAW (Raw IP), snapshot length 262144 bytes
IP 10.10.9.25.49812 > 10.20.8.50.445: Flags [S], seq 112233, win 64240, options [mss 1360,sackOK,TS val 123 ecr 0,nop,wscale 7], length 0
IP 10.10.9.25.49812 > 10.20.8.50.445: Flags [S], seq 112233, win 64240, options [mss 1360,sackOK,TS val 1123 ecr 0,nop,wscale 7], length 0
IP 10.10.9.25.49812 > 10.20.8.50.445: Flags [S], seq 112233, win 64240, options [mss 1360,sackOK,TS val 2123 ecr 0,nop,wscale 7], length 0
5 packets captured
Qué significa: Retransmisiones SYN sin SYN-ACK de retorno en esta interfaz. O la ruta de retorno está por otro lado (asimétrica) o está bloqueada.
Decisión: Captura en el túnel del sitio remoto también. Si SYN-ACK retorna por otro túnel, corrige la simetría de rutas o las expectativas de firewalls stateful.
Tarea 6: Prueba MTU correctamente con DF set (deja de confiar en “ping funciona”)
cr0x@server:~$ ping -M do -s 1372 -c 3 10.30.5.10
PING 10.30.5.10 (10.30.5.10) 1372(1400) bytes of data.
1400 bytes from 10.30.5.10: icmp_seq=1 ttl=63 time=32.1 ms
1400 bytes from 10.30.5.10: icmp_seq=2 ttl=63 time=31.8 ms
1400 bytes from 10.30.5.10: icmp_seq=3 ttl=63 time=32.0 ms
--- 10.30.5.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 31.8/32.0/32.1/0.1 ms
Qué significa: Payload 1372 (1400 bytes ICMP) pasa con DF—así que el path MTU es al menos 1400.
Decisión: Si tamaños mayores fallan (ej., 1472), ajusta MTU del túnel y clampa TCP MSS para evitar agujeros negros de fragmentación.
Tarea 7: Busca errores de fragmentación necesaria (el arma humeante)
cr0x@server:~$ ping -M do -s 1472 -c 2 10.30.5.10
PING 10.30.5.10 (10.30.5.10) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1436
ping: local error: message too long, mtu=1436
--- 10.30.5.10 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1012ms
Qué significa: Tu MTU de interfaz local es 1436; tramas de 1500 bytes no caben por el túnel.
Decisión: Clampa MSS (ej., 1360) y asegura que las interfaces internas no asuman jumbo/1500 end-to-end a través del VPN.
Tarea 8: Comprueba estado de sesión BGP y recuento de rutas
cr0x@server:~$ vtysh -c "show ip bgp summary"
BGP router identifier 10.10.0.1, local AS number 65010
BGP table version is 42
3 BGP AS-PATH entries
1 BGP community entries
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
169.254.20.2 4 65020 812 799 42 0 0 02:11:34 18
169.254.30.2 4 65030 805 790 42 0 0 02:09:57 22
Qué significa: Ambos vecinos están Established; estás recibiendo prefijos. Caídas súbitas a 0 prefijos son un outage de enrutamiento incluso si el túnel está “up”.
Decisión: Si faltan prefijos, revisa filtros, alcanzabilidad del next-hop y si la IP de la interfaz del túnel cambió.
Tarea 9: Valida qué rutas estás realmente exportando (evita tránsito accidental)
cr0x@server:~$ vtysh -c "show ip bgp neighbors 169.254.20.2 advertised-routes"
BGP table version is 42, local router ID is 10.10.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.10.0.0/16 0.0.0.0 0 32768 i
*> 10.10.50.0/24 0.0.0.0 0 32768 i
Qué significa: Estás anunciando solo prefijos de NYC, no “el mundo entero”.
Decisión: Si ves rutas de DAL anunciadas a SFO vía NYC, podrías estar haciendo a NYC transit involuntario; corrige la política de exportación.
Tarea 10: Confirma el reenvío IP y rp_filter (los routers Linux muerden)
cr0x@server:~$ sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
net.ipv4.ip_forward = 1
net.ipv4.conf.all.rp_filter = 1
Qué significa: El reenvío está activado, pero el filtrado estricto de ruta inversa puede dropear flujos asimétricos (común en mallas multi-túnel).
Decisión: Si tienes enrutamiento asimétrico por diseño o durante failover, pon rp_filter en modo loose (2) en las interfaces relevantes.
Tarea 11: Revisa IKE y CHILD SAs de strongSwan (verdad de IPsec)
cr0x@server:~$ sudo swanctl --list-sas
nyc-dal: #12, ESTABLISHED, IKEv2, 1d 02:11:04, 198.51.100.10[nyc]...203.0.113.20[dal]
local 'nyc' @ 198.51.100.10[4500]
remote 'dal' @ 203.0.113.20[4500]
AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_256
nyc-dal-child: #22, INSTALLED, TUNNEL, reqid 1, 2h 11:04, ESP in UDP SPIs: c1a2b3c4_i c4b3a2c1_o
AES_GCM_16_256, 12345678 bytes_i, 11223344 bytes_o, rekeying in 31 minutes
Qué significa: El túnel está establecido, child SA instalada, contadores de tráfico incrementando, rekey programado.
Decisión: Si los bytes se quedan en 0 mientras las apps fallan, probablemente tienes problemas de enrutamiento/firewall, no “VPN abajo”.
Tarea 12: Observa flaps de rekey en logs (microcortes)
cr0x@server:~$ sudo journalctl -u strongswan --since "30 min ago" | tail -n 12
Aug 22 10:11:03 nyc-gw charon[2014]: 12[IKE] rekeying IKE_SA nyc-dal[12]
Aug 22 10:11:04 nyc-gw charon[2014]: 12[IKE] sending CREATE_CHILD_SA request 1 [ SA No KE TSi TSr ]
Aug 22 10:11:09 nyc-gw charon[2014]: 12[IKE] retransmit 1 of request with message ID 47
Aug 22 10:11:14 nyc-gw charon[2014]: 12[IKE] retransmit 2 of request with message ID 47
Aug 22 10:11:19 nyc-gw charon[2014]: 12[IKE] giving up after 3 retransmits
Aug 22 10:11:19 nyc-gw charon[2014]: 12[IKE] deleting IKE_SA nyc-dal[12] between 198.51.100.10[nyc]...203.0.113.20[dal]
Qué significa: Rekey falló; el túnel fue derribado. Los usuarios experimentan un breve outage que parece “aleatorio”.
Decisión: Investiga pérdida en el underlay, lifetimes/proposals desalineados, comportamiento NAT-T o CPU saturada durante el rekey.
Tarea 13: Verifica contadores de política de firewall para allows/denies intersitio
cr0x@server:~$ sudo nft list ruleset | sed -n '1,80p'
table inet filter {
chain forward {
type filter hook forward priority filter; policy drop;
ct state established,related accept
iifname "vti-nyc-dal" oifname "lan0" ip saddr 10.20.0.0/16 ip daddr 10.10.50.0/24 tcp dport { 443, 445 } accept
counter packets 1842 bytes 221040 drop
}
}
Qué significa: Política por defecto drop; existe un allow específico. El contador final-drop está capturando algo.
Decisión: Si el contador de drop aumenta durante una falla reportada, añade un allow focalizado (o arregla la app para que use los puertos esperados), no abras “any-any”.
Tarea 14: Mide throughput y pérdida reales con iperf3 (no adivinanzas)
cr0x@server:~$ iperf3 -c 10.20.8.50 -t 10 -P 4
Connecting to host 10.20.8.50, port 5201
[ 5] local 10.10.9.25 port 41862 connected to 10.20.8.50 port 5201
[ 6] local 10.10.9.25 port 41864 connected to 10.20.8.50 port 5201
[ 7] local 10.10.9.25 port 41866 connected to 10.20.8.50 port 5201
[ 8] local 10.10.9.25 port 41868 connected to 10.20.8.50 port 5201
[SUM] 0.00-10.00 sec 412 MBytes 346 Mbits/sec 0 sender
[SUM] 0.00-10.00 sec 410 MBytes 344 Mbits/sec receiver
Qué significa: Puedes mover ~344 Mbps entre sitios bajo condiciones de prueba.
Decisión: Si el tráfico real de negocio es más lento, mira límites por flujo, QoS, ventana TCP o cuellos de botella en capa aplicación—no culpes solo al “VPN”.
Tres microhistorias del mundo corporativo
Microhistoria 1: El incidente causado por una suposición errónea
La compañía tenía tres oficinas y una malla ordenada. El diagrama de red parecía un problema de tarea de geometría, lo que hacía a todos sentirse seguros.
También tenían una suposición: “Si el túnel está up, las rutas están bien.” Nadie lo escribió, y así las suposiciones se esparcen—silenciosamente, como polvo.
Luego llegó un pequeño cambio: una VLAN nueva en DAL para un laboratorio de contratistas. El ingeniero añadió la subred localmente, actualizó las rutas estáticas de un túnel
y siguió con su día. El laboratorio podía alcanzar NYC, así que el ticket se cerró con una nota alegre. SFO no podía alcanzar el laboratorio, pero nadie probó esa ruta.
Una semana después, una pipeline de build en SFO empezó a fallar al intentar descargar artefactos de un host en DAL que se había movido a la nueva VLAN.
Las fallas fueron intermitentes porque algunos jobs aún obtenían artefactos cacheados en otros lugares. El equipo lo llamó “CI inestable”, que es la frase que usas
cuando todavía no sabes qué está roto.
La solución no fue exótica: deja de confiar en el estado del túnel como proxy de conectividad y deja de usar rutas estáticas puntuales sin un inventario.
Pasaron a túneles basados en ruta y BGP, e implementaron una prueba post-cambio que alcanzara un host representativo en cada subred remota desde cada sitio.
El resultado fue aburrido. Lo cual es la meta.
Microhistoria 2: La optimización que salió mal
Otra organización quería “máximo rendimiento”, así que activaron settings cripto agresivos y acortaron lifetimes porque alguien leyó que los rekeys son más seguros.
También subieron el logging a “debug” durante el despliegue y se olvidaron de bajarlo. Clásico.
Por un tiempo todo pareció bien. Luego llegó el lunes: más usuarios, más tráfico, más rekeys. Las gateways empezaron a tener picos de CPU durante eventos de rekey,
y como los lifetimes eran cortos, los picos eran frecuentes. Los usuarios no vieron un outage total. Vieron micro-outages: llamadas que se cortaban, pausas en SMB,
RDP que se congelaba cinco segundos y luego volvía.
El helpdesk hizo lo que hacen los helpdesks: lo correlacionaron con “problemas VPN” y escalaron. El equipo de red vio túneles establecidos y siguió adelante.
Mientras tanto el volumen de logs fue tan alto que un disco en una gateway empezó a llenarse y entonces la caja se puso “interesante” de nuevas maneras.
Revirtieron la “optimización”: lifetimes sensatos, logging debug solo durante sesiones planeadas y dimensionamiento de hardware basado en carga pico de rekey.
El rendimiento mejoró no porque la criptografía fuera más rápida, sino porque el sistema dejó de golpearse cada pocos minutos.
Microhistoria 3: La práctica aburrida pero correcta que salvó el día
Una compañía centrada en finanzas tenía tres oficinas con malla, pero trataban el VPN como producción: config en control de versiones, ventanas de cambio
y un runbook simple para validación. No era glamoroso. También era por lo que a veces podían dormir.
Una tarde, un ISP en una ciudad tuvo una caída parcial: no una caída total, solo suficiente pérdida de paquetes para arruinar tráfico encapsulado en UDP.
El túnel se quedó “up” lo suficiente para confundir a todos, pero los síntomas en las apps fueron inmediatos—jitter en voz, acceso a archivos lento, timeouts extraños.
Su monitorización lo detectó porque medían pérdida entre gateways y registraban retransmisiones IPSec. El on-call siguió el runbook:
comprobar pérdida del underlay, confirmar contadores del túnel, ejecutar pruebas MTU y luego mover el tráfico al circuito secundario. No discutieron con la red.
Moveron la carga.
La mejor parte: tenían una lista de verificación post-cambio que incluía pasos para “restaurar primario”, así que el failback no se convirtió en un segundo incidente.
Sin heroísmos. Solo aburrida práctica.
Errores comunes (síntomas → causa raíz → solución)
1) Síntoma: “Ping funciona, pero SMB/HTTPS se atasca”
Causa raíz: Agujero negro de Path MTU; paquetes TCP más grandes que el MTU del túnel se pierden, ICMP fragmentation-needed bloqueado o MSS no clamped.
Solución: Ajusta MTU del túnel y clampa TCP MSS en ingreso/egreso del VPN. Confirma con pings DF y pruebas de aplicaciones reales.
2) Síntoma: “El túnel está up, pero una subred es inalcanzable”
Causa raíz: Falta de anuncio de ruta (ruta estática no añadida, filtro BGP, next-hop erróneo), o subredes superpuestas causando selección de ruta equivocada.
Solución: Valida tablas de rutas en los tres sitios; si usas BGP, revisa rutas anunciadas/recibidas y prefix-lists. Arregla solapamientos renumerando.
3) Síntoma: “Funciona de NYC a DAL, no de DAL a NYC”
Causa raíz: Enrutamiento asimétrico más drop por firewall stateful; rp_filter en Linux; rutas de política enviando el retorno por el túnel equivocado.
Solución: Asegura enrutamiento simétrico para flujos stateful o usa reglas stateless donde proceda. Ajusta rp_filter a modo loose según sea necesario.
4) Síntoma: “Cortes aleatorios de 10–30 segundos”
Causa raíz: Flaps de rekey por pérdida de paquetes, lifetimes desajustados, picos de CPU o DPD demasiado agresivo.
Solución: Alinea lifetimes/proposals; ajusta DPD; investiga pérdida del underlay; dimensiona CPU; evita intervalos de rekey extremos.
5) Síntoma: “DAL puede alcanzar SFO solo cuando el túnel NYC está abajo”
Causa raíz: Preferencia de enrutamiento equivocada; NYC actúa como tránsito por fugas de rutas, métricas o local-pref en BGP.
Solución: Corrige la política de enrutamiento: prefiere el túnel directo, filtra rutas de tránsito, ajusta local-pref/weight y asegura next-hop-self donde corresponda.
6) Síntoma: “DNS funciona, pero la IP devuelta es inalcanzable desde una oficina”
Causa raíz: Desajuste de split-horizon; registros conscientes del sitio no alineados con el enrutamiento; servicios internos fijados a subredes locales.
Solución: Decide un modelo DNS (vista única vs consciente del sitio). Hazlo explícito y prueba resolución + conectividad desde cada sitio.
7) Síntoma: “Throughput es terrible solo para flujos individuales”
Causa raíz: Shaping por flujo, problemas de ventana TCP o la aplicación usa un solo stream; el overhead de cifrado reduce MSS efectivo/throughput.
Solución: Usa iperf3 con streams paralelos para comparar. Considera QoS, tuning TCP o cambios en la app; no solo “aumentes ancho de banda”.
8) Síntoma: “Todo muere durante los backups”
Causa raíz: Sin QoS y saturación del uplink; bufferbloat; el tráfico de backup se apodera del túnel.
Solución: Limita la tasa de backups, prográmalos o aplica QoS. Mide drops y latencia bajo carga; prioriza tráfico interactivo.
Listas de verificación / plan paso a paso
Plan paso a paso: construir una malla de tres oficinas que no te persiga
- Decide la topología por una razón: latencia/ancho de banda/aislamiento de fallos. Escribe la razón.
- Normaliza direccionamiento: elige rangos RFC1918 no superpuestos por sitio; reserva espacio para crecer.
- Elige tipo de túnel: túneles basados en ruta (VTI) por defecto.
- Elige enrutamiento: estático si es realmente pequeño y estable; BGP si algo cambia más de trimestralmente.
- Define zonas de seguridad: usuarios, servidores, gestión, guest, voz/OT según sea necesario.
- Escribe la política intersitio: listas de permiso por par de zonas; denegar user-to-user LAN por defecto.
- Plan de DNS: vista única o consciente del sitio; documenta qué nombres internos resuelven en cada sitio.
- Baseline MTU/MSS: establece MTU del túnel, clampa MSS y verifica con pings DF.
- Observabilidad: estado del túnel, estado BGP, sondas de pérdida/latencia, drops en interfaces y muestreo de logs.
- Gestión de configuración: exporta configs; guarda en control de versiones; usa convenciones de nombres consistentes.
- Pruebas: por cada cambio, prueba desde cada sitio a al menos un host en cada subred remota.
- Simulacros de fallo: simula un túnel abajo, un circuito degradado y un mis-route de DNS. Practica failover y failback.
Lista previa al cambio (haz esto antes de tocar producción)
- Configs actuales exportadas y guardadas (con timestamps y ID de cambio).
- Procedimiento de rollback escrito y factible sin heroicidades de internet.
- Lista de flujos críticos entre sitios (puertos + subredes + responsables).
- Ventana de mantenimiento comunicada (incluyendo “qué se romperá”).
- Dashboards de monitorización abiertos: pérdida/latencia, estado de túnel, BGP, errores de interfaz.
Checklist de verificación post-cambio (la parte que todos saltan)
- Túneles establecidos y estables (sin flapping en logs).
- Rutas presentes en todos los sitios (recuentos de prefijos esperados).
- Prueba MTU pasa en el tamaño esperado (ping DF).
- Al menos una transacción real de aplicación por par de sitios (no solo ping).
- Contadores de denegación del firewall no explotando.
- Documento actualizado: prefijos, peers, políticas y cualquier excepción.
Preguntas frecuentes
1) Para tres oficinas, ¿es full mesh siempre mejor que hub-and-spoke?
No. Si la mayor parte del tráfico va a un sitio “core” (datacenter/HQ), hub-and-spoke es más simple y a menudo más fiable.
Full mesh es mejor cuando el tráfico sitio-a-sitio es intenso o cuando necesitas aislamiento de fallos por pares.
2) ¿Debo usar rutas estáticas o BGP para una malla de tres sitios?
Las rutas estáticas son aceptables si la red es muy pequeña y estable. BGP vale la pena si tienes múltiples subredes por sitio, esperas crecimiento
o quieres failover y filtrado limpios. Si ya mantienes más que un puñado de rutas estáticas, ya las superaste.
3) ¿Cuál es la forma más rápida de evitar fugas de rutas en una malla?
Usa prefix-lists (o equivalente) y anuncia solo prefijos locales a cada vecino. Asume que cada vecino aceptará cualquier tontería a menos que lo detengas.
Además decide si algún sitio puede actuar como tránsito. Usualmente la respuesta es “no”.
4) ¿Por qué mi túnel aparece “up” pero los usuarios aún se quejan?
Porque “up” normalmente significa que el plano de control está vivo (IKE SA). El plano de datos puede estar roto por agujeros MTU, pérdida de paquetes, loops de enrutamiento
o denegaciones de firewall. Mide pérdida/latencia, revisa contadores y valida flujos de aplicaciones reales.
5) ¿Necesito clamping de MSS?
Si tu MTU efectivo a través del VPN es inferior a 1500 (común con IPsec/NAT-T), clamping de MSS suele ser la forma más fácil de prevenir stalls difíciles de depurar.
Verifica con pings DF y observa si “respuestas grandes” fallan.
6) ¿WireGuard puede hacer full mesh entre oficinas de forma segura?
Sí, si gestionas las keys correctamente y eres disciplinado con AllowedIPs y la política de firewall. WireGuard facilita los túneles; no automatiza la política de enrutamiento.
Para tres sitios, es excelente en gateways Linux con configuraciones y monitorización consistentes.
7) ¿Cómo evito que una malla se convierta en una pesadilla de seguridad?
Forwarding intersitio por defecto-denegar, segmenta por zonas y permite explícitamente solo los flujos requeridos.
Registra denegaciones con límites de tasa sensatos. Y mantén el acceso de gestión fuera de la tela intersitio general.
8) ¿Qué debo monitorizar para detectar problemas antes que los usuarios?
Pérdida y latencia entre gateways, estabilidad de rekeys del túnel, drops/errores de interfaces, estado de sesión BGP y recuentos de prefijos,
y un par de checks sintéticos de aplicación (resolución DNS + conexión TCP + pequeña transferencia de datos).
9) ¿Qué hay de alta disponibilidad para tres sitios?
HA ayuda, pero no es magia. Comienza con circuitos de internet duales si es posible, luego gateways redundantes con un método de failover probado.
Asegúrate de que el failover no cambie IPs de origen de forma que rompa expectativas de los peers, y practica el failback.
10) ¿Cómo sé si SD-WAN vale la pena solo para tres oficinas?
Vale la pena cuando necesitas política centralizada, mejor observabilidad, múltiples circuitos por sitio y steering consciente de aplicaciones.
Si tu entorno es estable y puedes estandarizar en un solo stack de gateway, un VPN clásico con BGP suele ser suficiente.
Conclusión: próximos pasos prácticos
Para tres oficinas, un VPN full mesh es o bien una tela limpia de baja latencia o un juego triangular de culpas. La diferencia no es la topología.
Es si tratas al enrutamiento, DNS, MTU y la política como ciudadanos de primera clase y si operas la cosa con disciplina.
Próximos pasos que puedes hacer esta semana:
- Escribe la razón real para la malla (latencia, ancho de banda, aislamiento). Si no puedes, reconsidera hub-and-spoke.
- Haz inventario de subredes y elimina solapamientos antes de que se multipliquen.
- Ejecuta pruebas MTU DF y clampa MSS donde sea necesario.
- Si usas rutas estáticas, cuéntalas. Si el recuento te molesta, pasa a BGP.
- Añade monitorización para pérdida/latencia entre gateways y para flaps de rekey. “Túnel up” no es observabilidad.
- Implementa política intersitio por defecto-denegar y añade listas de permiso explícitas para flujos de negocio reales.
Construye la malla como si tuvieras que depurarla a las 2 a.m. Porque lo harás. La meta es que sea aburrida cuando lo hagas.