Lo notas primero en las pequeñas cosas: las carpetas compartidas se sienten “pegajosas”, las llamadas VoIP entre oficinas suenan como si alguien hablara desde dentro de una pecera, y el panel favorito del CFO carga lo bastante lento como para culpar a “la nube”.
Luego miras la ruta y te das cuenta de que estás haciendo hairpin del tráfico de la Oficina A a la Oficina B a través de un centro de datos central a tres estados de distancia porque así se construyó la VPN en 2017 y nadie quiere tocarla.
La malla completa con WireGuard parece la cura: conectar cada oficina directamente con todas las demás. La latencia baja, las salidas a Internet se quedan locales y dejas de pagar el “impuesto del hub”.
También es una buena forma de construir un copo de nieve operativo que explota en cuanto añades tu sitio número 13.
Lo que realmente estás decidiendo: topología y dominios de fallo
La gente habla de “malla completa” como si fuera una característica de producto. No lo es. Es una apuesta.
La apuesta es que reducir la longitud del camino (y evitar un punto de estrangulamiento en el hub) vale la pena aumentar el número de relaciones que debes gestionar: claves, endpoints, rutas, reglas de firewall, monitorización y el radio de impacto de incidentes.
WireGuard en sí no es la parte difícil. WireGuard es un protocolo limpio, minimalista, con una base de código pequeña y comportamiento predecible.
La parte difícil es el sistema alrededor: políticas de enrutamiento, la realidad del NAT, gestión de direcciones, casos límite de MTU/fragmentación y humanos haciendo gestión de cambios a escala.
La matemática de escalado que nadie quiere en una diapositiva
En una malla completa con n sitios, tienes n(n-1)/2 túneles (o relaciones entre pares) si todos se emparejan directamente con todos.
Eso es 10 sitios → 45 relaciones. 20 sitios → 190. 50 sitios → 1225. El crecimiento es cuadrático, y tu paciencia no lo es.
Puedes automatizar la generación y distribución de configuraciones. Debes hacerlo. Pero la automatización no elimina la complejidad operativa; solo te permite crear complejidad más rápido.
Lo que WireGuard hace bien (y para lo que no pretende servir)
WireGuard te da cifrado autenticado, un modelo de interfaz simple y una propiedad agradable: si no hay tráfico, básicamente no hay estado.
Pero WireGuard no hace enrutamiento dinámico. No hace selección de ruta. No te dice “el peer B está caído; usa el peer C”.
Esos comportamientos vienen de tu capa de enrutamiento (rutas estáticas, BGP/OSPF vía FRR, enrutamiento por políticas, lógica SD-WAN) y de tu diseño de red.
La lección fiable de sistemas aquí es vieja y sigue siendo cierta: mantén simple el plano de control, pero no pretendas que no tienes uno.
Una cita para mantenerte honesto
La esperanza no es una estrategia.
— General Gordon R. Sullivan
Se aplica de maravilla a topologías VPN. Si tu plan depende de “probablemente el hub no tendrá problemas”, tienes un plan hecho de deseos.
Cuándo valen la pena los túneles directos entre oficinas
La malla completa puede ser la respuesta correcta. No porque sea tendencia, sino porque resuelve problemas físicos y organizativos específicos.
Aquí están los casos en los que lo recomendaré sin poner la cara de “¿estás seguro?”.
1) Tienes tráfico en tiempo real entre sitios que sufre por la latencia del hairpin
VoIP, vídeo, VDI, escritorio remoto a aplicaciones on-prem, telemetría OT/SCADA y cualquier cosa interactiva.
Si la Oficina A y la Oficina B están a 8 ms, y tu hub es un desvío de 40 ms, las matemáticas no perdonan.
El jitter suele ser peor que la latencia bruta, y la congestión del hub añade jitter gratis.
Un túnel directo te da una ruta consistente que no compite con tráfico no relacionado dirigido al hub.
2) Tu hub es un cuello de botella que no puedes (o no debes) escalar infinitamente
A veces el hub es un par de firewalls virtuales con licencias que cuestan como un yate pequeño. Otras veces es un circuito apretado en el DC que compras no actualizará hasta el próximo trimestre, lo que equivale a “nunca”.
La malla completa reparte la carga y reduce el modo de fallo “todas las rutas llevan a Roma”.
3) Necesitas salidas locales a Internet pero aún quieres conectividad fuerte site-to-site
Si cada oficina reenvía internet a través de un egress central, obtienes controles de seguridad consistentes y logs fáciles. También obtienes rendimiento terrible en SaaS y problemas divertidos con enrutamiento asimétrico.
Una malla puede permitir que las oficinas mantengan su propio egress mientras se preserva la accesibilidad directa para servicios internos.
4) Tu transporte WAN es heterogéneo y quieres diversidad de rutas
Las oficinas pueden tener fibra, cable, LTE o ese “banda ancha para negocios” que parece alérgica al uptime.
Con múltiples WANs por sitio, puedes hacer múltiples peers WireGuard y enrutamiento por políticas para mantener el tráfico fuera del enlace peor.
La malla no te da ingeniería de tráfico automáticamente, pero te ofrece más opciones de ruta para engineerar.
5) Tienes un pequeño número de sitios y una fuerte cultura de automatización
La malla completa es manejable en 3–8 sitios. Puede funcionar bien en ~10–15 si generas configs centralmente, haces seguimiento de asignaciones IP, exiges revisiones y pruebas de cambios.
Más allá de eso, necesitas un plan serio para enrutamiento y distribución de configuración o estarás construyendo una máquina de Rube Goldberg que cae con la primera taza de café derramada.
6) Necesitas contener fallos a pares de sitios
En un diseño hub-and-spoke, la inestabilidad del hub se convierte en problema de todos. En una malla, un flap de túnel afecta a los dos endpoints.
Ese radio de impacto más estrecho puede ser la diferencia entre “un ticket” y “una llamada de incidente que involucra a la empresa”.
7) Estás migrando desde MPLS y la expectativa de “any-to-any” está integrada
Las organizaciones que crecieron con MPLS esperan que cualquier oficina pueda hablar con cualquier otra. Cuando reemplazas eso por hub-and-spoke, los usuarios lo notan.
Una malla (o una malla parcial con enrutamiento) puede igualar expectativas sin tantas batallas políticas.
Cuándo la malla completa es una trampa
La malla falla de maneras predecibles. Las fallas no son bugs exóticos de criptografía; son fallas de “humanos y tablas de enrutamiento”.
Aquí cuándo evitaría una malla completa y elegiría un patrón diferente.
1) Tienes más sitios de los que puedes prestar atención operativa
Si te encaminas hacia 20+ ubicaciones, la malla completa sin enrutamiento dinámico y sin automatización fuerte se vuelve un peligro de mantenimiento.
Solo la rotación de claves se convierte en un problema de calendario con invitaciones y correos incómodos de escalado.
Además, cuando cada cambio toca docenas de peers, cada cambio es un “gran cambio”, lo que significa menos cambios, más drift y peores outages.
2) Tus sitios están detrás de NAT hostil o tienen IPs que cambian frecuentemente
WireGuard puede funcionar detrás de NAT, pero aún necesita una forma de encontrar al otro extremo.
Si ambos extremos están detrás de carrier-grade NAT con direcciones cambiantes y sin rendezvous estable (o no puedes usar un relay), los túneles directos se vuelven un pasatiempo para la disponibilidad.
3) Necesitas segmentación limpia o límites de cumplimiento
La malla completa tiende a fomentar “todo puede alcanzar todo” a menos que pongas políticas serias de enrutamiento/firewall.
Si estás en un entorno regulado o tienes unidades de negocio que no deben compartir redes, una malla se convierte en un rompecabezas de aplicación de políticas.
Cuantos más bordes tengas, más lugares donde accidentalmente puedes permitir tráfico.
4) No puedes tolerar el error humano en AllowedIPs
AllowedIPs es a la vez el control de acceso de WireGuard y su selector de enrutamiento. Eso es elegante. También es un cuchillo afilado.
Una entrada equivocada en AllowedIPs puede dejar tráfico en un agujero negro, robar tráfico hacia el peer equivocado o crear bucles de enrutamiento cuando se combina con rutas del SO.
5) Tu equipo necesita “configurar y olvidar”
Si el banco de networking es corto y los cambios son raros, prefiere un diseño con menos piezas móviles:
hub-and-spoke, hubs duales o un pequeño número de hubs regionales.
No eres menos profesional por elegir lo aburrido. Eres más empleado.
Chiste corto #1: La malla completa es como un chat de grupo: genial con cinco personas, y un desastre cuando le agregan a la tía de todos.
Opciones de diseño que no son “malla o nada”
Hub-and-spoke (hub único) — el kit de inicio
Beneficios: más simple de razonar, más fácil de securizar centralmente, monitorización más sencilla.
Costes: el hub se convierte en un cuello de botella de throughput y dominio de fallo; latencia por hairpin; costes de circuito del hub.
Úsalo cuando: tengas pocos flujos entre oficinas, mayormente tráfico “sucursal a centro de datos” y el hub sea robusto y redundante.
Hub dual — la versión “adulta”
Dos hubs (preferiblemente en diferentes regiones/proveedores) con sucursales conectadas a ambos. Usar preferencia de enrutamiento y failover.
Esto reduce el punto único de fallo y puede cortar latencia por hairpin si eliges hubs con criterio.
A menudo es el mejor valor: evitas el crecimiento cuadrático mientras mejoras la resiliencia.
Hubs regionales (malla parcial) — latencia sin locura
Crea 3–6 puntos de agregación regionales; las oficinas hacen mesh dentro de una región o se conectan a su región más cercana. El tráfico inter-región va hub-a-hub.
Mantienes la mayoría de las ganancias de latencia y reduces dramáticamente el conteo de peers.
Malla con enrutamiento dinámico (FRR + BGP) — la opción “red seria”
Si insistes en malla a escala, no lo hagas con enrutamiento estático y la esperanza.
Ejecuta un demonio de enrutamiento (comúnmente FRR) e intercambia rutas sobre WireGuard. Deja que la capa de enrutamiento maneje alcance y failover.
Aviso: ahora has introducido un verdadero plano de control de enrutamiento. Debes securizarlo, monitorizarlo y mantenerlo consistente. Vale la pena, pero no es gratis.
Overlay + relay para sitios NATeados — acepta la realidad
Algunos sitios no pueden tener conectividad entrante estable. En ese caso, considera un relay (un VPS o hub) que ambos extremos puedan alcanzar.
No es “malla pura”, pero te da conectividad funcional con comportamiento predecible.
Hechos interesantes y contexto histórico
- WireGuard fue creado por Jason A. Donenfeld a mediados de la década de 2010 con el objetivo de ser pequeño, moderno y auditable en comparación con pilas VPN tradicionales.
- La integración en el kernel de Linux llegó en 2020, lo que cambió materialmente su historia operativa: las actualizaciones y el rendimiento se volvieron más fáciles para muchas organizaciones.
- WireGuard usa un handshake basado en Noise (ideas del framework de protocolos Noise), favoreciendo primitivas modernas y complejidad mínima de negociación.
- Evita intencionadamente la agilidad de algoritmos—una decisión históricamente controvertida, pero que reduce la posibilidad de degradación y la complejidad de configuración en despliegues reales.
- AllowedIPs es un mecanismo de doble propósito (enrutamiento + control de acceso). Ese diseño es elegante y también la principal fuente de tickets “¿por qué el tráfico va allí?”.
- Las VPNs en malla completa existían antes de WireGuard por décadas: los primeros diseños WAN corporativos intentaron conectividad any-to-any mucho antes de que SD-WAN la hiciera popular en marketing.
- El dolor por MTU es más antiguo que las VPNs. Los problemas de fragmentación aparecieron en las primeras redes IP; la encapsulación VPN simplemente reintroduce la misma física con nuevos envoltorios.
- “Hub-and-spoke” se volvió popular en parte por la centralización de firewalls—es más fácil auditar un punto de estrangulamiento que 40 bordes, especialmente bajo presión de cumplimiento.
- Los modos de fallo operativos tienden a dominar a los modos de fallo criptográficos en VPNs maduras: fugas de enrutamiento, supuestos de NAT y huecos en la monitorización causan más outages que la criptografía.
Tareas prácticas: comandos, salidas y decisiones
Estas son las tareas que realmente ejecuto cuando decido si una malla se comporta, se porta mal o está tramando algo en silencio contra mí.
Cada tarea incluye: un comando, una salida de ejemplo, lo que significa y la decisión que tomas.
Tarea 1: Confirmar que WireGuard está arriba y haciendo handshake
cr0x@server:~$ sudo wg show
interface: wg0
public key: pGZ2...Qm8=
private key: (hidden)
listening port: 51820
peer: 7y8N...aZk=
endpoint: 198.51.100.10:51820
allowed ips: 10.60.1.0/24, 10.60.200.2/32
latest handshake: 32 seconds ago
transfer: 1.21 GiB received, 980.45 MiB sent
persistent keepalive: every 25 seconds
Qué significa: “latest handshake” reciente y contadores de transferencia moviéndose indican que el túnel está vivo.
Si el handshake es “never”, tienes problemas de reachability, NAT, firewall o desajuste de claves.
Decisión: Si el handshake está viejo o nunca ocurre, no toques enrutamiento aún. Arregla primero la reachability (firewall, UDP, endpoints, keepalive).
Tarea 2: Verificar que la interfaz tenga las direcciones correctas
cr0x@server:~$ ip -br addr show dev wg0
wg0 UNKNOWN 10.60.200.1/24
Qué significa: La IP del overlay está configurada. “UNKNOWN” es normal para interfaces WireGuard.
Decisión: Si la dirección falta o es incorrecta, arregla la configuración local antes de culpar a la red.
Tarea 3: Confirmar que las rutas del kernel coincidan con tu intención
cr0x@server:~$ ip route show table main | grep -E 'wg0|10\.60\.'
10.60.1.0/24 dev wg0 scope link
10.60.2.0/24 dev wg0 scope link
10.60.200.0/24 dev wg0 proto kernel scope link src 10.60.200.1
Qué significa: Existen rutas apuntando subredes a wg0. Si usas wg-quick, instalará rutas basadas en AllowedIPs.
Decisión: Si falta una ruta de subred, revisa AllowedIPs del peer que debería llevarla, o tu demonio de enrutamiento si usas BGP.
Tarea 4: Identificar “robo de rutas” por AllowedIPs solapadas
cr0x@server:~$ sudo wg show wg0 allowed-ips
7y8N...aZk= 10.60.1.0/24 10.60.200.2/32
Jp2c...9Qs= 10.60.0.0/16 10.60.200.3/32
Qué significa: Un peer reclama 10.60.0.0/16, que solapa 10.60.1.0/24. WireGuard escoge el prefijo más específico, pero los prefijos amplios son una trampa común.
Decisión: Elimina AllowedIPs amplios a menos que intentes conscientemente un diseño de “default vía este peer”. Sé explícito por sitio.
Tarea 5: Comprobar si NAT o firewall bloquean UDP/51820
cr0x@server:~$ sudo ss -ulpn | grep 51820
UNCONN 0 0 0.0.0.0:51820 0.0.0.0:* users:(("wg",pid=1322,fd=6))
Qué significa: La máquina está escuchando en UDP/51820 en todas las interfaces.
Decisión: Si no hay nada escuchando, estás depurando un problema de servicio/configuración, no de camino de red.
Tarea 6: Validar reglas de firewall para el puerto de WireGuard
cr0x@server:~$ sudo nft list ruleset | grep -n '51820'
117: udp dport 51820 accept
Qué significa: Hay una regla de allow. Si no ves una, asume que está bloqueado hasta demostrar lo contrario.
Decisión: Añade reglas de allow explícitas y registra drops temporalmente si persigues handshakes intermitentes.
Tarea 7: Probar reachability básica a través del túnel (ICMP)
cr0x@server:~$ ping -c 3 10.60.200.2
PING 10.60.200.2 (10.60.200.2) 56(84) bytes of data.
64 bytes from 10.60.200.2: icmp_seq=1 ttl=64 time=8.12 ms
64 bytes from 10.60.200.2: icmp_seq=2 ttl=64 time=8.25 ms
64 bytes from 10.60.200.2: icmp_seq=3 ttl=64 time=8.09 ms
--- 10.60.200.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2005ms
rtt min/avg/max/mdev = 8.089/8.155/8.246/0.070 ms
Qué significa: La conectividad L3 básica funciona y la latencia está en el rango esperado.
Decisión: Si ping funciona pero las aplicaciones no, sospecha MTU, TCP MSS o políticas de firewall en tráfico reenviado.
Tarea 8: Encontrar problemas de MTU con pings DF
cr0x@server:~$ ping -M do -s 1420 -c 2 10.60.200.2
PING 10.60.200.2 (10.60.200.2) 1420(1448) bytes of data.
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420
--- 10.60.200.2 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1015ms
Qué significa: El MTU de la interfaz local (o una limitación de path MTU) impide ese tamaño de paquete. La sobrecarga de encapsulación lo hace común.
Decisión: Reduce el MTU de wg0 (por ejemplo 1380 o 1360), o aplica clamping de TCP MSS en tráfico reenviado. No adivines—prueba tamaños hasta que pase.
Tarea 9: Inspeccionar el camino y dónde aparece la latencia (traceroute)
cr0x@server:~$ traceroute -n 10.60.2.10
traceroute to 10.60.2.10 (10.60.2.10), 30 hops max, 60 byte packets
1 10.60.200.2 8.431 ms 8.207 ms 8.189 ms
2 10.60.2.10 8.922 ms 8.743 ms 8.701 ms
Qué significa: Un camino de dos saltos indica enrutamiento limpio vía el peer. Si ves saltos inesperados (como un hub), tu política de enrutamiento no está haciendo lo que crees.
Decisión: Si el tráfico hace hairpin, arregla la preferencia de ruta (métricas, enrutamiento por política, local-pref en BGP) o elimina rutas conflictivas.
Tarea 10: Confirmar que el forwarding está habilitado (error clásico)
cr0x@server:~$ sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 0
Qué significa: El forwarding IPv4 está activado. El forwarding IPv6 está apagado (lo que puede ser correcto o explicar fallos solo IPv6).
Decisión: Si enrutas entre LANs de oficina, por lo general quieres forwarding activado en tus routers VPN. Para IPv6 decide intencionalmente; no lo dejes en negro.
Tarea 11: Vigilar paquetes para probar dónde mueren
cr0x@server:~$ sudo tcpdump -ni wg0 host 10.60.2.10 and tcp port 445 -c 6
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:01:14.220123 IP 10.60.1.50.51234 > 10.60.2.10.445: Flags [S], seq 2209001, win 64240, options [mss 1360,sackOK,TS val 111 ecr 0], length 0
12:01:15.221004 IP 10.60.1.50.51234 > 10.60.2.10.445: Flags [S], seq 2209001, win 64240, options [mss 1360,sackOK,TS val 112 ecr 0], length 0
12:01:16.221998 IP 10.60.1.50.51234 > 10.60.2.10.445: Flags [S], seq 2209001, win 64240, options [mss 1360,sackOK,TS val 113 ecr 0], length 0
Qué significa: Retransmisiones de SYN sin SYN-ACK. El tráfico entra al túnel pero no recibe respuesta.
Eso suele ser un firewall en el otro lado, ruta de retorno faltante o enrutamiento asimétrico que hace que las respuestas salgan por otro lado.
Decisión: Revisa la ruta de retorno: rutas en la LAN de destino, políticas de firewall y reglas NAT. Si las respuestas no vuelven por el mismo camino, arregla la simetría de enrutamiento.
Tarea 12: Detectar enrutamiento asimétrico con reglas de política
cr0x@server:~$ ip rule show
0: from all lookup local
1000: from 10.60.2.0/24 lookup 100
32766: from all lookup main
32767: from all lookup default
Qué significa: Hay una regla de política que fuerza tráfico con origen 10.60.2.0/24 a usar la tabla 100. Si la tabla 100 enruta hacia internet en lugar de wg0, has creado asimetría.
Decisión: Asegura que el enrutamiento por políticas coincida con tu diseño VPN. Si haces local internet breakout, sé explícito sobre las rutas de retorno para tráfico inter-oficinas.
Tarea 13: Validar que rp_filter no esté descartando tráfico reenviado legítimo
cr0x@server:~$ sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.wg0.rp_filter
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.wg0.rp_filter = 1
Qué significa: El filtrado de ruta inversa estricto puede descartar paquetes cuando las rutas de retorno no coinciden con la idea del kernel de “mejor ruta”. Esto afecta diseños multihomed y con policy routing.
Decisión: Para enrutamiento complejo, pon rp_filter en 2 (loose) en las interfaces relevantes, o rediseña para simetría. No lo desactives por completo sin pensar.
Tarea 14: Medir throughput real y detectar techos por CPU o MTU
cr0x@server:~$ iperf3 -c 10.60.200.2 -P 4 -t 10
Connecting to host 10.60.200.2, port 5201
[SUM] 0.00-10.00 sec 1.05 GBytes 902 Mbits/sec 0 sender
[SUM] 0.00-10.00 sec 1.04 GBytes 893 Mbits/sec 12 receiver
Qué significa: Estás obteniendo ~900 Mbps con pocas retransmisiones. Si ves números mucho más bajos, revisa CPU, MTU o shaping en el WAN.
Decisión: Si la CPU está al máximo durante iperf, el dimensionamiento del router es incorrecto o necesitas offload hardware (o simplemente menos túneles en esa caja).
Tarea 15: Revisar saturación de CPU durante cifrado
cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.5.0 (edge-a) 12/27/2025 _x86_64_ (4 CPU)
12:02:01 AM CPU %usr %nice %sys %iowait %irq %soft %idle
12:02:02 AM all 62.00 0.00 30.00 0.00 0.00 6.00 2.00
12:02:02 AM 0 78.00 0.00 20.00 0.00 0.00 2.00 0.00
12:02:02 AM 1 60.00 0.00 36.00 0.00 0.00 4.00 0.00
12:02:02 AM 2 55.00 0.00 35.00 0.00 0.00 8.00 2.00
12:02:02 AM 3 55.00 0.00 29.00 0.00 0.00 10.00 6.00
Qué significa: Estás casi sin CPU idle mientras empujas tráfico. WireGuard es eficiente, pero aún puede saturar routers pequeños a alto throughput.
Decisión: Aumenta hardware, reduce concurrencia o reduce el número de túneles de alto throughput por caja (hubs regionales en lugar de malla completa).
Tarea 16: Confirmar clamping MSS si haces NAT o tienes restricciones MTU
cr0x@server:~$ sudo iptables -t mangle -S | grep -E 'TCPMSS|wg0'
-A FORWARD -o wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Qué significa: Los paquetes SYN tienen MSS ajustada para evitar problemas de fragmentación. Esto suele “arreglar” estancamientos raros de aplicaciones que ping no muestra.
Decisión: Si ves estancamientos relacionados con MTU, añade clamping en el borde VPN. Si ya lo tienes y persisten problemas, prueba el PMTU real y reduce el MTU de wg0.
Tarea 17: Verificar que el endpoint de un peer sea lo que crees
cr0x@server:~$ sudo wg show wg0 endpoints
7y8N...aZk= 198.51.100.10:51820
Qué significa: WireGuard muestra el endpoint actual que está usando. Si el peer hace roaming (cambio de NAT), esto se actualiza después de recibir paquetes.
Decisión: Si el endpoint es incorrecto (IP antigua), asegura que el lado remoto pueda iniciar tráfico (keepalive) o actualiza la gestión de DNS/IP. La malla con endpoints inestables necesita un plan.
Guía de diagnóstico rápido
Cuando el CEO dice “la conexión entre oficinas está lenta” no tienes tiempo para un seminario de filosofía. Necesitas una secuencia de triaje que te lleve al cuello de botella rápido.
Primero: decide si es un problema de túnel o de enrutamiento/camino
- Revisa handshake y contadores:
wg show. Si el handshake está viejo/nunca, es reachability/NAT/firewall/claves. - Revisa a dónde va el tráfico:
ip route get <dest>ytraceroute -n. Si hace hairpin por un hub, es preferencia de enrutamiento o rutas directas faltantes. - Captura unos paquetes:
tcpdump -ni wg0. Si salen SYNs pero no regresan SYN-ACK, es ruta de retorno o firewall en el destino.
Segundo: aislar MTU y fragmentación (el asesino silencioso)
- Haz pings DF con tamaños crecientes:
ping -M do -s 1200/1300/1400. - Si falla en tamaños modestos, reduce MTU de wg0 y/o aplica clamp MSS.
- Vuelve a probar la aplicación real (SMB, HTTPS, RDP). Los bugs de MTU adoran la ilusión de “funciona para cosas pequeñas”.
Tercero: decide si es throughput, CPU o shaping del WAN
- Ejecuta
iperf3a través del túnel para una línea base. - Mira la CPU con
mpstatdurante la prueba. - Comprueba pérdida/jitter con
pingy drops con contadores de interfaz (ip -s link).
Cuarto: busca enrutamiento por política y sabotaje de rp_filter
ip rule showpara sorpresas de policy routing.sysctl net.ipv4.conf.all.rp_filtercuando existan caminos asimétricos.- Arregla el diseño, no solo los síntomas. Pero si debes parchear, pon rp_filter en loose en las interfaces correctas y documenta por qué.
Chiste corto #2: Los problemas de MTU son el equivalente en redes de la luz de “revisar motor”—vago, ominoso y de alguna manera siempre es tu problema.
Errores comunes: síntoma → causa raíz → solución
1) “El túnel está arriba, pero solo algunas apps funcionan”
Síntoma: Ping y peticiones HTTP pequeñas funcionan; SMB, SSH con payloads grandes o uploads HTTPS se estancan.
Causa raíz: MTU/PMTUD en agujero negro por sobrecarga de encapsulación; ICMP “fragmentation needed” bloqueado; MSS no ajustado.
Solución: Pon MTU de wg0 conservador (a menudo ~1380), y clampa MSS en paquetes SYN TCP reenviados. Verifica con pings DF.
2) “Los handshakes se detienen tras unos minutos a menos que haya tráfico”
Síntoma: latest handshake se vuelve viejo; el tráfico se reanuda solo tras un ping manual desde un lado.
Causa raíz: El mapeo NAT expira; ninguno de los dos lados inicia para refrescar; no hay keepalive en el lado NATeado.
Solución: Configura PersistentKeepalive = 25 (o similar) en el lado detrás de NAT. Asegura que el firewall permita UDP de retorno.
3) “El tráfico hacia la Oficina B va a la Oficina C y muere”
Síntoma: El peer equivocado recibe tráfico; traceroute muestra salto inicial inesperado; tcpdump muestra paquetes saliendo por el túnel equivocado.
Causa raíz: AllowedIPs solapadas o prefijos amplios instalados por conveniencia; robo de rutas por prefijo general combinado con métricas del SO.
Solución: Haz AllowedIPs precisos por subred de sitio; evita 0.0.0.0/0 y grandes sumarios salvo que realmente lo quieras. Audita con wg show allowed-ips.
4) “Funciona de A a B, pero no de B a A”
Síntoma: Flujos unidireccionales; SYNs vistos solo en una dirección; respuestas salen por internet u otro WAN.
Causa raíz: Enrutamiento asimétrico por policy routing, WAN dual o rutas de retorno faltantes en routers LAN.
Solución: Asegura que la ruta de retorno apunte de nuevo al router WireGuard; usa enrutamiento por origen con cuidado; considera tablas de rutas por origen por subred.
5) “Tras añadir una nueva oficina, otras oficinas se rompen al azar”
Síntoma: Añadir un peer nuevo causa pérdida de conectividad no relacionada; agujeros negros intermitentes.
Causa raíz: Solapamiento de direcciones (IPs de túnel duplicadas o subredes LAN duplicadas), o AllowedIPs que incluye accidentalmente la subred de otro.
Solución: Impone IPAM para overlay y rangos LAN; rechaza duplicados en CI; ejecuta una comprobación de solapamiento de rutas antes de desplegar.
6) “El throughput es terrible pero la CPU está bien”
Síntoma: iperf muestra Mbps bajos; CPU idle; picos de pérdida de paquetes; rendimiento varía según la hora del día.
Causa raíz: Shaping del WAN, bufferbloat o ruta ISP congestionada; a veces policías UDP en banda ancha comercial.
Solución: Confírmalo con pruebas sostenidas; añade QoS/SQM en el borde; considera múltiples WANs con failover; no culpes a WireGuard por la personalidad del ISP.
7) “Todo se rompe durante la rotación de claves”
Síntoma: Algunos túneles vuelven, otros no; handshakes no se reanudan para un subconjunto.
Causa raíz: Despliegue inconsistente de configuraciones; claves públicas antiguas aún referenciadas; configs obsoletas no recargadas; automatización parcial.
Solución: Rota con un enfoque por etapas (añade claves nuevas en paralelo cuando sea posible), recarga de forma determinista y verifica handshakes con chequeos automatizados.
Tres microhistorias corporativas desde el terreno
Microhistoria 1: El incidente causado por una suposición equivocada
Una empresa mediana pasó de seis oficinas a once en menos de un año. El equipo de red decidió “terminar lo que empezamos” y construir una malla completa con configs WireGuard estáticos.
Su suposición: “Estas son oficinas; las IPs públicas son estables.” Eso era cierto para los sitios con fibra. Fue hilarantemente falso para dos ubicaciones nuevas que usaban banda ancha “temporal” que se volvió permanente.
Un lunes por la mañana, dos oficinas perdieron reachability a tres otras. No todas. Justo las suficientes para crear un caos de servicios medio funcionales: presencia telefónica falló, pero a veces las llamadas funcionaban; las comparticiones de archivos estaban mapeadas pero no se podían abrir; las impresoras mostraban offline.
El panel de monitorización estaba verde porque los túneles hacia el hub estaban bien, y el equipo había creado checks que solo validaban branch-to-hub.
La causa raíz fue mundana: esos circuitos de banda ancha cambiaron IPs el fin de semana. Algunos peers actualizaron endpoints por roaming (porque el lado NATeado inició tráfico) y otros no (porque los sitios remotos nunca iniciaron).
Así que la mitad de la malla convergió y la otra mitad quedó congelada con “latest handshake: 3 days ago.”
La solución no fue solo “poner PersistentKeepalive.” También introdujeron una regla de diseño: cualquier sitio sin endpoint estable no participa como nodo de malla de primera clase.
Esos sitios se conectan a un pequeño conjunto de hubs de rendezvous estables. La comunicación directa entre oficinas está permitida solo entre sitios estables o vía un path de relay controlado.
La lección: la malla asume simetría de reachability y descubrimiento estable. Si no tienes eso, no estás construyendo una malla; estás construyendo un juego distribuido de adivinanzas.
Microhistoria 2: La optimización que salió mal
Otra empresa tenía una VPN hub-and-spoke y odiaba la latencia entre dos regiones.
Alguien propuso un “win simple”: añadir túneles directos entre todas las oficinas de la Región Este y todas las de la Región Oeste. Sonaba razonable—hasta que se topó con sumarios BGP y optimismo humano.
Ya usaban enrutamiento dinámico dentro del data center. Para evitar anunciar docenas de subredes pequeñas, resumían rutas en cada límite de oficina.
Luego activaron los enlaces de malla cross-region e importaron los sumarios sin filtros estrictos, porque la ventana de cambio era corta y el plan de rollback era básicamente “apagarlo y fingir que nunca pasó.”
Durante una semana, todo fue genial. Luego un router de oficina en Región Este anunció mal un resumen por un bug en la plantilla de configuración.
De repente, el tráfico de una gran parte de Región Este empezó a fluir hacia la oficina equivocada, cruzando un enlace de malla, y luego fue descartado por un firewall que nunca esperó tráfico transitivo.
El outage fue doloroso porque parecía “lentitud aleatoria en SaaS” al principio. Los gráficos WAN estaban normales; el hub estaba sano; solo un subconjunto de apps internas falló.
Tomó una captura de paquetes y un diff de tablas de enrutamiento para detectar el sumario malo.
Mantuvieron los enlaces de malla, pero dejaron de tratar la política de enrutamiento como una tarea secundaria.
Filtros de prefijo estrictos, límites de max-prefix y validación de rutas se volvieron no negociables. La optimización estaba bien; la falta de barreras no lo estaba.
Microhistoria 3: La práctica aburrida pero correcta que salvó el día
Una empresa con nueve oficinas ejecutaba una malla parcial: hubs regionales más algunos túneles directos para apps sensibles a latencia.
No era glamoroso. Estaba documentado. Eso solo los puso por delante de la mayoría de la industria.
Su “práctica aburrida” era una auditoría automatizada semanal: exportar wg show, tablas de rutas y reglas de firewall en un snapshot, luego hacer diff contra la semana anterior.
La salida iba a una cola de tickets que a nadie le gustaba, pero significaba que el drift era visible.
Una tarde, un técnico de helpdesk haciendo “limpieza” eliminó lo que parecía una ruta estática sin uso en un router de oficina.
En minutos, un sistema de gestión de almacén dejó de sincronizar actualizaciones de inventario con otro sitio. Los usuarios culparon a la aplicación. Por supuesto que lo hicieron.
El diff de la auditoría señaló la ruta removida y apuntó al dispositivo y hora exactos. La reparación fue inmediata: restaura la ruta y añade un comentario en la configuración que explique por qué existía.
El incidente nunca se convirtió en un festival de culpas entre equipos porque la evidencia estaba ahí, aburrida y precisa.
La lección: la malla no falla solo porque es compleja. Falla porque la gente olvida por qué existen las cosas. Haz que la red se explique a sí misma.
Listas de verificación / plan paso a paso
Decide si deberías hacer malla completa
- Lista los flujos inter-oficina principales: VoIP, SMB, ERP, replicación de bases de datos, tráfico de backup. Pon ancho de banda aproximado y sensibilidad a latencia al lado de cada uno.
- Cuenta sitios ahora y en 18 meses. Si te diriges más allá de ~15, asume que necesitas automatización de enrutamiento y/o una malla parcial.
- Clasifica endpoints: IP pública estable, IP dinámica, detrás de CGNAT, WAN dual, respaldo LTE. La malla odia la incertidumbre.
- Decide tu modelo de seguridad: any-to-any plano, segmentado o “solo apps específicas”. Malla más segmentación exige disciplina de políticas.
- Elige dominios de fallo intencionalmente: ¿quieres “fallo del hub impacta a todos” o “fallo de túnel par afecta a dos”?
Constrúyelo como planeas operarlo
- Asigna IPs del overlay vía IPAM (incluso un simple registro gestionado por Git). Nunca “elige una al azar”.
- Estandariza nombres de interfaz: wg0 para site-to-site, wg-mgmt para gestión, etc. La consistencia te compra velocidad en incidentes.
- Genera configs desde la fuente de la verdad. Configs de malla editadas por humanos son el plan de retiro para tu futuro terapeuta.
- Define patrones de AllowedIPs: solo prefijos LAN por sitio; evita grandes sumarios a menos que estén respaldados por política de enrutamiento y revisión.
- Configura MTU intencionalmente y documenta la razón. Si no lo haces, lo redescubrirás durante un outage, que es una forma cara de aprender.
- Planifica la rotación de claves: calendario, radio de impacto y pasos de verificación. Hazlo un procedimiento, no un ritual.
Operalo con salvaguardas
- Monitorización: alerta por handshakes viejos en peers críticos, aumento de pérdida de paquetes y saturación de CPU en routers VPN.
- Gestión de cambios: cada alta/baja de sitio debe ser reproducible y revisable. La malla amplifica errores.
- Pruebas: tras cada cambio, ejecuta ping/DF ping/iperf hacia al menos un peer y un host LAN remoto.
- Detección de drift: snapshot de configs y estado de enrutamiento; haz diffs regularmente. “No cambiamos nada” suele ser falso.
Preguntas frecuentes
1) ¿Es la malla completa WireGuard más segura que hub-and-spoke?
No inherentemente. La seguridad de WireGuard depende de la gestión de claves y las restricciones de peers. La malla puede aumentar la superficie de ataque porque hay más bordes y más lugares donde malconfigurar AllowedIPs o reglas de firewall.
Si haces malla, trata la política como primera clase: restringe rutas, aplica segmentación y audita regularmente.
2) ¿Cuál es la mayor ventaja práctica de túneles directos entre oficinas?
Reducción de latencia y jitter para tráfico inter-oficina. Si el hub está lejos geográficamente o congestionado, los túneles directos pueden convertir “casi inutilizable” en “aceptable”.
3) ¿Cuál es la mayor desventaja operativa de la malla completa?
El conteo de peers y el radio de impacto de cambios. Añadir un sitio se convierte en una actualización multi-peer. La rotación de claves y la resolución de problemas se vuelven problemas combinatorios a menos que automatices y monitorices seriamente.
4) ¿Cuántos sitios son “demasiados” para una malla estática?
Aproximadamente: más allá de 10–15 sitios, la malla estática se vuelve desagradable a menos que tu automatización y disciplina de enrutamiento sean excelentes. Pasados los 20, generalmente quieres enrutamiento dinámico y/o hubs regionales.
5) ¿Debería ejecutar BGP sobre WireGuard?
Si necesitas escala, failover y menos dolores de cabeza con rutas estáticas, sí—BGP (vía FRR) es una buena opción. Pero no es magia.
Debes implementar filtros de prefijos, límites de max-prefix y monitorización, o convertirás un bug de enrutamiento en un outage a nivel empresa.
6) ¿Cómo manejo oficinas con IPs dinámicas?
Usa PersistentKeepalive en el lado NATeado para que pueda hacer roaming y mantener vivo el mapeo NAT, y prefiere puntos de rendezvous estables (hubs/relays) para esos sitios.
Espera que “malla directa pura en todas partes” sea frágil si múltiples sitios tienen endpoints inestables.
7) ¿Puedo hacer túneles active-active entre oficinas?
No con WireGuard solo. WireGuard te da enlaces cifrados; el enrutamiento decide cómo usarlos.
Active-active normalmente se hace con enrutamiento de costo igual (ECMP) vía un demonio de enrutamiento, o balanceo a nivel de aplicación. Ten cuidado: ECMP más caminos asimétricos puede romper firewalls y middleboxes con estado.
8) ¿Por qué WireGuard usa AllowedIPs para enrutamiento?
Es una elección de diseño para mantener WireGuard minimalista: decide a qué peer enviar un paquete según el matching de prefijo de destino.
Reduce la superficie de configuración pero hace que la corrección sea tu responsabilidad. Trata AllowedIPs como código de producción.
9) ¿Debería NATear tráfico a través de túneles site-to-site?
Prefiere no hacerlo. NAT oculta errores de direccionamiento hasta que se vuelven incidentes. Enruta prefijos reales cuando sea posible.
NAT es a veces útil para solapar espacios RFC1918 durante fusiones, pero trátalo como una herramienta de transición con plan de retiro.
10) ¿Cuál es la forma más limpia de evitar subredes LAN solapadas entre oficinas?
Establece un estándar de direccionamiento tempranamente (asignaciones por sitio) y aplícalo con IPAM y revisión. Los solapamientos son una de las principales causas de que “la malla esté embrujada”.
Próximos pasos prácticos
Si estás decidiendo si construir túneles directos office-to-office con WireGuard, haz esto en orden:
- Mide la latencia y jitter por hairpin actuales entre las oficinas que más se quejan.
- Prototipa un túnel directo entre dos sitios y valida: estabilidad de handshake, MTU, throughput y enrutamiento de retorno.
- Elige una topología basada en conteo de sitios y estabilidad de endpoints: malla completa (pequeña/estable), malla parcial (regional) o hubs duales (usualmente mejor compromiso).
- Automatiza la generación de configs antes de escalar más allá de un puñado de sitios. Si esperas, nunca alcanzarás a ponerte al día.
- Instala guardarraíles: filtros de rutas, chequeos de sanidad de prefijos, detección de drift y una política estándar MTU/MSS.
- Escribe el runbook mientras todavía te parece obvio. El tú del futuro estará cansado y desconfiado durante el outage.
Los túneles directos valen la pena cuando eliminan un cuello de botella real y puedes mantener el modelo operativo limpio.
No valen la pena cuando los usas para evitar escoger una arquitectura de red. Tu topología te elegirá a ti—usualmente durante una ventana de cambio un viernes.