WireGuard hub-and-spoke para 3 oficinas con acceso por roles

enero 3, 2026 • febrero 3, 2026 • Lectura: 31 min • Views: 10

¿Te fue útil?

Tres oficinas. Una VPN “rápida”. De pronto el CFO puede acceder a la impresora del laboratorio, pero el servicio de soporte no puede llegar a la base de datos de tickets, y las llamadas de Zoom del CEO suenan como un robot ahogándose. No “configuraste un túnel”. Construiste una red. Las redes tienen física, políticas y bordes afilados.

Este es un diseño práctico y orientado a producción para una VPN WireGuard hub-and-spoke que conecta tres oficinas, con reglas de acceso por rol. Lo haremos con un enrutamiento sensato, segmentación explícita y suficiente observabilidad para que puedas depurar la inevitable página de “ayer funcionaba” sin adivinar.

Decisiones de arquitectura que no te morderán más tarde

¿Por qué hub-and-spoke para tres oficinas?

Con tres sedes, la malla completa tienta: “conecta todo con todo”. Eso funciona hasta que añades roles, servicios compartidos, futuras sedes y un auditor de cumplimiento con una libreta y sueños. Hub-and-spoke te da un único punto de control donde puedes:

aplicar la política de forma coherente (firewall, registro, DNS)
hacer el enrutamiento predecible (los spokes envían tráfico no local al hub)
reducir la complejidad operativa (un solo lugar para depurar problemas intersede)
añadir una cuarta oficina sin aprender nuevas formas de sufrir

La desventaja es que el hub se vuelve importante. Está bien. Los sistemas de producción siempre tienen partes importantes; la clave es saber cuáles son y tratarlas como tal.

Define los roles antes de definir las reglas

“Reglas de acceso por rol” no es una característica del firewall. Es una decisión de negocio expresada en paquetes. Empieza con roles que mapeen a patrones de tráfico:

IT/Admin: puede llegar a subredes de gestión, jump hosts, monitorización, quizá a todo durante incidentes.
Finanzas: puede acceder a sistemas contables, compartidos de archivos, impresoras limitadas, no a redes de I+D.
Ingeniería: puede acceder a sistemas de build, repositorios, entornos de staging, no a sistemas de RR.HH.
Invitado/Proveedor: puede acceder a una o dos aplicaciones, y nada más.

En el momento en que tus “roles” son en realidad “personas”, acabarás con una tormenta de ACL. Mantén pocos roles. Adjunta usuarios/dispositivos a roles mediante IPs de peer de WireGuard o interfaces separadas, y aplica la política de forma centralizada.

No uses WireGuard como tu único motor de políticas

WireGuard es excelente en lo que hace: un túnel cifrado pequeño y rápido con un modelo de claves claro. No es un sistema RBAC. AllowedIPs de WireGuard es tanto enrutamiento como un control de admisión muy burdo. No es un firewall, y pretender que lo es conduce a fallos extraños.

Usa WireGuard para transporte seguro y acotamiento básico de peers. Usa nftables (o iptables, si debes) en el hub para aplicar quién puede hablar con qué. Esto te da auditabilidad y un único lugar para implementar “Finanzas puede alcanzar 10.10.20.0/24 pero no 10.10.30.0/24”.

Chiste #1: Una VPN sin reglas de firewall es solo un cable de red muy confiado.

Asume que existe NAT en algún sitio y planea en consecuencia

Las oficinas suelen estar detrás de routers comerciales. WireGuard usa UDP y es amigable con NAT, pero NAT seguirá influyendo en keepalives, MTU y accesibilidad entrante. Tu hub debería tener una IP pública estática si es posible. Si no, necesitarás un enfoque más creativo, pero para tres oficinas, paga por la IP estática y listo.

Decide: enrutado vs puenteado. Elige enrutado.

Puentear L2 entre sedes es cómo importas tormentas de broadcast y “ARP misterioso” a tu vida. Usa subredes enrutadas por oficina. Si alguien insiste en que “necesita L2”, haz que nombre la aplicación y el protocolo, y luego arregla esa aplicación.

Datos interesantes y contexto (porque la historia se repite en los tickets)

El objetivo de diseño de WireGuard fue la simplicidad: muchas menos líneas de código que las pilas VPN tradicionales, lo que reduce la superficie de ataque y el tiempo de depuración.
Usa criptografía moderna por defecto: Curve25519 para intercambio de claves, ChaCha20-Poly1305 para cifrado autenticado y BLAKE2s para hashing.
“Enrutamiento criptoclave” es la idea central de WireGuard: la clave que usas también determina qué rangos IP puedes enviar a ese peer.
IPsec es más antiguo que muchos de tus routers: se originó en los 90, y su complejidad es en parte un registro fósil de requisitos antiguos.
Los VPN site-to-site solían ser solo hardware: los primeros despliegues empresariales dependían de appliances dedicados porque las CPUs eran más lentas y la criptografía costaba.
Los VPN UDP pueden superar a los TCP: porque el colapso TCP-sobre-TCP es real; WireGuard evita esa clase de miseria quedándose en UDP.
Los fallos de MTU son eternos: la detección de MTU de ruta y el filtrado de ICMP han causado incidentes tipo “todo funciona menos esta app” durante décadas.
Las bases de datos de política de enrutamiento de Linux (múltiples tablas de enrutamiento y ip rule) existen porque “una ruta por defecto” dejó de ser suficiente en redes reales.

Una idea para tener en el monitor: la esperanza no es una estrategia — a menudo atribuida en cultura ops a Gordon R. Sullivan. Trátala como una mentalidad, no como un ejercicio de citas.

Plan de direcciones y modelo de enrutamiento (la parte aburrida que te salva)

Subredes de oficina: mantenlas únicas y aburridas

Si tus tres oficinas usan 192.168.1.0/24, no tienes “un problema de VPN”. Tienes un problema de direccionamiento. Arréglalo primero. Renumerar duele, pero menos que ejecutar NAT dentro de tu VPN para siempre.

Un plan limpio y legible:

LAN Oficina A: 10.10.10.0/24
LAN Oficina B: 10.10.20.0/24
LAN Oficina C: 10.10.30.0/24
Transito VPN (WireGuard): 10.200.0.0/24

Las IPs de la interfaz WireGuard viven en 10.200.0.0/24. Esto no es una “LAN”. Es una red de tránsito. No pongas impresoras ahí. No pongas personas ahí. Mantenla sagrada y un poco aburrida.

¿Dónde viven los gateways?

Cada oficina obtiene un pequeño gateway Linux (hardware, VM o router que pueda ejecutar WireGuard). El hub también es un gateway Linux en un centro de datos o VPC en la nube con una IP pública estable.

Nombres de ejemplo:

hub1 (IP pública, política central): wg0: 10.200.0.1/24
spoke-a: wg0: 10.200.0.11/24, interfaz LAN en 10.10.10.0/24
spoke-b: wg0: 10.200.0.21/24, interfaz LAN en 10.10.20.0/24
spoke-c: wg0: 10.200.0.31/24, interfaz LAN en 10.10.30.0/24

Modelo de enrutamiento: los spokes envían por defecto al hub para redes remotas

Los spokes deben enrutar el tráfico destinado a otras subredes de oficina a través del hub. El hub enruta hacia el spoke correcto según el destino. Esto te da política centralizada y evita que las excepciones “spoke-a-spoke” se multipliquen.

Aún así tendrás salida directa a Internet local en cada oficina. Este no es un diseño de “enviar todo el tráfico al hub” a menos que lo necesites específicamente y disfrutes depurar la navegación web sobre un enlace WAN.

Acceso por roles: qué significa realmente “por rol” en WireGuard

Tres formas de implementar roles

Puedes implementar “roles” en diferentes capas. Elige una y sé consistente.

Por subred de origen (recomendado): asigna roles a VLANs/subredes internas en cada oficina (p. ej., VLAN de Finanzas). El firewall del hub aplica el acceso desde esas subredes.

Pros: escalable, fácil de auditar. Contras: requiere higiene de red interna.
Por IP de peer de WireGuard: da a cada rol (o a cada dispositivo) una IP VPN y escribe reglas de firewall usando esas IPs de origen.

Pros: funciona aunque las LANs sean planas. Contras: puede volverse desordenado; estás codificando identidad como IP.
Por interfaces WireGuard separadas por rol: wg-finance, wg-eng, etc.

Pros: muy explícito. Contras: más interfaces, más cosas en movimiento; usualmente innecesario para tres oficinas a menos que cumplimiento lo exija.

La recomendación práctica

Implementa roles por subred de origen dentro de cada oficina y haz cumplir en el hub. Si la Oficina A es actualmente una única subred plana, divídela. Sí, eso es “trabajo de redes”. También ese es el punto.

Ejemplo de VLANs de rol en Oficina A:

Finanzas Oficina A: 10.10.11.0/24
Ingeniería Oficina A: 10.10.12.0/24
IT/Admin Oficina A: 10.10.13.0/24

Repite de forma similar para las Oficinas B y C, o mantén roles consistentes entre oficinas si puedes. La consistencia es un multiplicador de fuerza cuando estás cansado.

Lo que WireGuard puede y no puede hacer para RBAC

WireGuard puede garantizar que un peer dado solo se use para ciertos prefijos de destino mediante AllowedIPs. Eso evita fugas de enrutamiento accidentales y algunas clases de suplantación. No impide que un peer alcance todo lo que pueda enrutar una vez dentro del túnel. Esa es tarea del firewall.

Configuraciones de WireGuard: hub, spokes y qué hace realmente AllowedIPs

Configuración del hub

El hub termina los tres spokes. Los AllowedIPs del hub para cada peer deberían incluir:

la IP del túnel WireGuard del spoke (un /32)
las subredes LAN del spoke (LAN de la oficina y VLANs de rol)

cr0x@server:~$ sudo cat /etc/wireguard/wg0.conf
[Interface]
Address = 10.200.0.1/24
ListenPort = 51820
PrivateKey = HUB_PRIVATE_KEY
# Optional but practical:
SaveConfig = false

# Spoke A
[Peer]
PublicKey = SPOKE_A_PUBLIC_KEY
AllowedIPs = 10.200.0.11/32, 10.10.10.0/24, 10.10.11.0/24, 10.10.12.0/24, 10.10.13.0/24

# Spoke B
[Peer]
PublicKey = SPOKE_B_PUBLIC_KEY
AllowedIPs = 10.200.0.21/32, 10.10.20.0/24, 10.10.21.0/24, 10.10.22.0/24, 10.10.23.0/24

# Spoke C
[Peer]
PublicKey = SPOKE_C_PUBLIC_KEY
AllowedIPs = 10.200.0.31/32, 10.10.30.0/24, 10.10.31.0/24, 10.10.32.0/24, 10.10.33.0/24

Configuración del spoke

Cada spoke tiene un único peer: el hub. Los AllowedIPs del spoke para el hub deberían incluir:

la IP del túnel del hub (/32) y cualquier servicio central en el lado del hub
todas las LANs de otras oficinas alcanzables vía el hub

Eso significa que el spoke enruta otras oficinas vía el hub. Nada de peering spoke-a-spoke. Sin rarezas especiales.

cr0x@server:~$ sudo cat /etc/wireguard/wg0.conf
[Interface]
Address = 10.200.0.11/24
PrivateKey = SPOKE_A_PRIVATE_KEY

[Peer]
PublicKey = HUB_PUBLIC_KEY
Endpoint = hub1.example.net:51820
AllowedIPs = 10.200.0.1/32, 10.200.0.0/24, 10.10.20.0/24, 10.10.21.0/24, 10.10.22.0/24, 10.10.23.0/24, 10.10.30.0/24, 10.10.31.0/24, 10.10.32.0/24, 10.10.33.0/24
PersistentKeepalive = 25

¿Por qué incluir 10.200.0.0/24 en AllowedIPs en el spoke?

Para que el spoke pueda alcanzar las IPs de túnel de otros peers si es necesario (monitorización, ping, comprobaciones de salud). Si prefieres bloquearlo, incluye solo 10.200.0.1/32 y confía en la monitorización basada en el hub. Ambas son válidas; elige una. Yo normalmente permito el /24 de tránsito y lo firewallo en el hub.

Reenvío IP: debes habilitarlo

Esto es lo que la gente olvida y luego culpa a WireGuard. El túnel está arriba, pero nadie alcanza nada porque la caja Linux no enruta.

Aplicación de acceso con nftables (no por buenas intenciones)

Principio: denegar por defecto entre roles, permitir por necesidad

El hub debe aplicar segmentación entre subredes de rol de oficinas y servicios compartidos. Empieza con “denegar inter-oficina por defecto”, luego permite los flujos que sean realmente necesarios. Se siente estricto. También evita incidentes como “el portátil de Finanzas puede escanear toda la red de ingeniería”.

Direcciones de tráfico que te interesan

Tráfico reenviado a través del hub: oficina-a-oficina y oficina-a-servicios-centrales
Tráfico de entrada al propio hub: SSH, monitorización, DNS si el hub lo ejecuta

Ejemplo de política nftables en el hub

Este es un patrón simplificado pero realista: acepta establecido, luego permisos explícitos, luego descarta. Registra los drops con moderación, o te harás un DDoS a tu propio disco durante un incidente.

cr0x@server:~$ sudo cat /etc/nftables.conf
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority 0;
    policy drop;

    iif lo accept
    ct state established,related accept

    # Allow WireGuard
    udp dport 51820 accept

    # Allow SSH from IT/Admin role subnets only
    ip saddr { 10.10.13.0/24, 10.10.23.0/24, 10.10.33.0/24 } tcp dport 22 accept

    # Allow monitoring from IT/Admin
    ip saddr { 10.10.13.0/24, 10.10.23.0/24, 10.10.33.0/24 } tcp dport { 9100, 9182 } accept

    # Optional: ICMP for troubleshooting
    ip protocol icmp accept
    ip6 nexthdr icmpv6 accept
  }

  chain forward {
    type filter hook forward priority 0;
    policy drop;

    ct state established,related accept

    # Allow IT/Admin roles cross-office (jump hosts, mgmt)
    ip saddr { 10.10.13.0/24, 10.10.23.0/24, 10.10.33.0/24 } ip daddr { 10.10.0.0/16 } accept

    # Allow Finance to reach accounting service subnet (central or specific office)
    ip saddr { 10.10.11.0/24, 10.10.21.0/24, 10.10.31.0/24 } ip daddr 10.10.50.0/24 tcp dport { 443, 5432 } accept

    # Allow Engineering to reach build systems
    ip saddr { 10.10.12.0/24, 10.10.22.0/24, 10.10.32.0/24 } ip daddr 10.10.60.0/24 tcp dport { 22, 443, 8080 } accept

    # Allow limited printer access within each office only (example)
    ip saddr 10.10.11.0/24 ip daddr 10.10.10.50 tcp dport { 631, 9100 } accept
    ip saddr 10.10.21.0/24 ip daddr 10.10.20.50 tcp dport { 631, 9100 } accept
    ip saddr 10.10.31.0/24 ip daddr 10.10.30.50 tcp dport { 631, 9100 } accept

    # Log and drop everything else
    limit rate 5/second log prefix "vpn-forward-drop " flags all counter drop
  }
}

Aquí es donde demuestras tu valía. El hub se convierte en un punto de aplicación de políticas. Cuando alguien pregunte “¿por qué el proveedor X no puede llegar a Y?”, puedes responder con una regla, una línea de registro y una solicitud de cambio—no con folklore.

DNS entre sedes sin convertirlo en una casa embrujada

Elige una estrategia DNS y apégate a ella

Los VPN multi-sede fallan de dos maneras: se rompe el enrutamiento, o se rompe el DNS. Los fallos de enrutamiento son obvios; los de DNS son lentos, extraños y emocionalmente agotadores.

Estrategias comunes:

DNS central: un único servicio DNS interno alcanzable por la VPN. Política más sencilla, fuente única de verdad. Asegura redundancia.
DNS por oficina con reenvío condicional: cada oficina resuelve nombres locales y reenvía otras zonas por la VPN. Funciona bien pero requiere disciplina.
Puro IP + archivos hosts: técnicamente posible, socialmente desastroso. No lo hagas.

Recomendación

Para tres oficinas, ejecuta DNS central en el hub (o dos hubs para HA), y configura los clientes de las oficinas para usarlo para zonas internas. Si las oficinas deben resolver nombres locales únicamente, usa forwarders condicionales. Mantén zonas internas explícitas (p. ej., corp.internal, svc.corp.internal).

Rendimiento: MTU, realidades UDP y por qué “rápido” es una elección de diseño

MTU no es trivia opcional

WireGuard añade overhead. Si envías paquetes demasiado grandes, se fragmentan o se descartan. Si el ICMP “se necesita fragmentación” está bloqueado en algún punto (a menudo lo está), obtendrás síntomas clásicos: SSH funciona pero las transferencias de archivos se quedan; las webs se cargan a medias; SMB se convierte en arte performativo.

Ajusta MTU deliberadamente. Un valor seguro común es 1420 en interfaces WireGuard. A veces necesitas menos (1412, 1380) según los enlaces upstream y encapsulaciones.

UDP y el “estado”

WireGuard es UDP. Eso es bueno para el rendimiento y evita problemas TCP-sobre-TCP, pero significa:

Los timeouts de NAT pueden romper silenciosamente caminos de retorno a menos que uses keepalives.
Algunas redes tratan UDP como sospechoso y lo limitan por tasa.
Debes monitorizar la frescura de los handshakes y los contadores de tráfico, no el “estado de la conexión”.

Chiste #2: Los problemas de MTU son como los gatos—si crees que no tienes uno, solo se está escondiendo debajo del sofá.

Moldeo de ancho de banda y equidad

Si una oficina satura el enlace del hub, todos comparten el dolor. Si esto preocupa, usa control de tráfico (tc) para moldear por interfaz o por subred de origen. No lo hagas prematuramente. Pero hazlo a propósito si las apps de negocio quedan atrapadas detrás del trabajo de backup de alguien.

Operaciones: rotación de claves, control de cambios y actualizaciones

La gestión de claves no es difícil, pero es real

WireGuard usa claves públicas/privadas estáticas por peer. Las claves no expiran por defecto. Eso es a la vez una fortaleza y un problema de gobernanza. Debes:

rotar claves según un calendario (p. ej., anual) y en salidas de personal
almacenar claves privadas de forma segura (archivos root-only, backups cifrados)
documentar qué clave pertenece a qué sitio/rol

Control de cambios que no arruine tu fin de semana

El hub es central. Trata su configuración como código de producción:

mantén /etc/wireguard y la configuración de firewall en control de versiones (repositorio privado)
usa convenciones de nombres para peers y comentarios fuera del archivo de configuración si hace falta
despliega cambios con un proceso predecible (Ansible, Salt, o al menos un rsync scriptado)
siempre ten un plan de reversión

Actualizaciones

WireGuard en kernel de Linux es estable. Aun así, las actualizaciones cambian kernels, comportamiento de nftables y drivers NIC. No actualices el hub y todos los spokes a la vez. Hazlo por fases. Verifica handshakes y rutas después de cada paso.

Tareas prácticas: comandos, salidas, decisiones (12+ que realmente ejecutarás)

Tarea 1: Verificar estado de la interfaz WireGuard

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 1Xh9nR...hubpub...
  private key: (hidden)
  listening port: 51820

peer: rGm8z...spokeA...
  allowed ips: 10.200.0.11/32, 10.10.10.0/24, 10.10.11.0/24, 10.10.12.0/24, 10.10.13.0/24
  latest handshake: 37 seconds ago
  transfer: 2.31 GiB received, 3.02 GiB sent
  persistent keepalive: every 25 seconds

Qué significa: “latest handshake” te dice si el peer está vivo. Los contadores de transferencia indican si el tráfico fluye en ambas direcciones.

Decisión: Si los handshakes están obsoletos (>2 minutos) para un spoke detrás de NAT, comprueba keepalive, la alcanzabilidad UDP y la corrección del endpoint antes de tocar el enrutamiento.

Tarea 2: Confirmar IP de interfaz y MTU

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

Qué significa: MTU está en 1420; la interfaz está UP.

Decisión: Si ves MTU 1500 y estás en PPPoE u otros enlaces con overhead, planifica una reducción de MTU y vuelve a probar transferencias de archivos.

Tarea 3: Asegurar que el reenvío IPv4 está habilitado en hub y spokes

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

Qué significa: El enrutamiento de Linux está habilitado.

Decisión: Si es 0, habilítalo y hazlo persistente; de lo contrario tienes una “VPN que conecta pero no enruta”, clásico.

Tarea 4: Comprobar rutas de subredes de oficina en el hub

cr0x@server:~$ ip route show table main | grep 10.10.
10.10.10.0/24 dev wg0 scope link
10.10.20.0/24 dev wg0 scope link
10.10.30.0/24 dev wg0 scope link

Qué significa: El hub cree que esas subredes son alcanzables vía wg0.

Decisión: Si faltan rutas, el AllowedIPs del peer en el hub puede estar incompleto o la interfaz no está aplicándolas como rutas (según cómo gestiones el enrutamiento). Arregla AllowedIPs primero.

Tarea 5: Validar que un spoke enruta otras oficinas vía el hub

cr0x@server:~$ ip route get 10.10.20.10
10.10.20.10 dev wg0 src 10.200.0.11 uid 0
    cache

Qué significa: Spoke A enruta tráfico a Oficina B vía wg0.

Decisión: Si intenta salir por la interfaz WAN, al AllowedIPs del spoke en el peer del hub le faltan las subredes de Oficina B.

Tarea 6: Comprobar que las reglas nftables están cargadas (hub)

cr0x@server:~$ sudo nft list ruleset | sed -n '1,80p'
table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;
		iif "lo" accept
		ct state established,related accept
		udp dport 51820 accept
		ip saddr { 10.10.13.0/24, 10.10.23.0/24, 10.10.33.0/24 } tcp dport 22 accept
		ip protocol icmp accept
	}
	chain forward {
		type filter hook forward priority filter; policy drop;
		ct state established,related accept
		ip saddr { 10.10.13.0/24, 10.10.23.0/24, 10.10.33.0/24 } ip daddr 10.10.0.0/16 accept
		limit rate 5/second log prefix "vpn-forward-drop " flags all counter drop
	}
}

Qué significa: Tu política existe y se aplica con default-drop.

Decisión: Si las reglas no están presentes, o no cargas nftables en el arranque o otra herramienta las sobrescribió. Arregla el orden de servicios antes de añadir más reglas.

Tarea 7: Encontrar por qué un flujo está bloqueado usando contadores y registros

cr0x@server:~$ sudo nft list chain inet filter forward
table inet filter {
  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    ip saddr { 10.10.13.0/24, 10.10.23.0/24, 10.10.33.0/24 } ip daddr 10.10.0.0/16 accept
    limit rate 5/second log prefix "vpn-forward-drop " flags all counter packets 41 bytes 2460 drop
  }
}

Qué significa: 41 paquetes reenviados fueron descartados por la regla catch-all.

Decisión: Si los usuarios reportan problemas de acceso y este contador sube durante su prueba, necesitas una regla de allow explícita (o estás viendo tráfico inesperado que debería seguir bloqueado).

Tarea 8: Confirmar alcanzabilidad UDP 51820 desde un spoke

cr0x@server:~$ sudo tcpdump -ni eth0 udp port 51820 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:44:01.102938 IP 198.51.100.22.39422 > 203.0.113.10.51820: UDP, length 148
12:44:01.128440 IP 203.0.113.10.51820 > 198.51.100.22.39422: UDP, length 92

Qué significa: Los paquetes llegan y las respuestas vuelven. La alcanzabilidad básica está bien.

Decisión: Si ves entrantes pero no salientes, sospecha firewall en el hub. Si no ves nada entrante, sospecha NAT/forwarding upstream o IP de endpoint errónea.

Tarea 9: Validar que no se esté aplicando NAT accidentalmente al tráfico VPN

cr0x@server:~$ sudo nft list table ip nat
table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oifname "eth0" masquerade
  }
}

Qué significa: Todo lo que sale por eth0 está NATeado, lo que podría incluir tráfico enrutado por la VPN si egrese vía el hub.

Decisión: Si planeas tráfico oficina-a-oficina puro enrutado, asegúrate de que el tráfico entre oficinas permanezca en wg0 y no haga hairpin por eth0. Si haces breakout a internet central, NAT puede ser correcto—pero entonces debes planificar ancho de banda y registro en consecuencia.

Tarea 10: Detectar agujeros MTU con ping + DF

cr0x@server:~$ ping -M do -s 1372 10.10.20.10 -c 3
PING 10.10.20.10 (10.10.20.10) 1372(1400) bytes of data.
1380 bytes from 10.10.20.10: icmp_seq=1 ttl=62 time=18.9 ms
1380 bytes from 10.10.20.10: icmp_seq=2 ttl=62 time=18.7 ms
1380 bytes from 10.10.20.10: icmp_seq=3 ttl=62 time=18.8 ms

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

Qué significa: Un paquete de 1400 bytes (incluyendo cabeceras) pasa sin fragmentación. Buen signo.

Decisión: Si esto falla a tamaños muy por debajo de 1400, reduce la MTU de WireGuard y vuelve a probar, o deja de bloquear ICMP “frag needed” en algún punto upstream.

Tarea 11: Confirmar que reverse path filtering no está descartando tráfico enrutado por la VPN

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

Qué significa: El filtrado de ruta inversa estricto está deshabilitado globalmente (0), lo cual suele ser necesario en escenarios multihomed.

Decisión: Si rp_filter es 1 o 2 y ves tráfico unidireccional, ajústalo (con cuidado) en las interfaces relevantes. No desactives la seguridad a ciegas; entiende primero la asimetría de enrutamiento.

Tarea 12: Verificar que existan rutas en el lado LAN de vuelta a subredes remotas

cr0x@server:~$ ip route | grep 10.10.20.0/24
10.10.20.0/24 via 10.10.10.1 dev eth1

Qué significa: Un host en la LAN de la Oficina A sabe enviar tráfico a la Oficina B vía el gateway local (10.10.10.1).

Decisión: Si los clientes de oficina no tienen ruta, o el router de oficina debe anunciar rutas estáticas hacia el gateway VPN local, o configura el gateway Linux como gateway por defecto para esas VLANs. El enrutamiento de VPN falla si solo los gateways conocen las rutas.

Tarea 13: Comprobar estado conntrack para un flujo específico

cr0x@server:~$ sudo conntrack -L -p tcp --dport 443 2>/dev/null | head
tcp      6 431999 ESTABLISHED src=10.10.11.22 dst=10.10.50.10 sport=53422 dport=443 src=10.10.50.10 dst=10.10.11.22 sport=443 dport=53422 [ASSURED] mark=0 use=1

Qué significa: El hub ve un flujo TCP establecido entre un cliente de Finanzas y el servicio contable.

Decisión: Si los usuarios se quejan de resets/timeouts pero conntrack nunca muestra ESTABLISHED, sospecha drops del firewall, enrutamiento o MTU. Si muestra ESTABLISHED pero la app va lenta, mira congestión/pérdida de paquetes.

Tarea 14: Confirmar que la hora es correcta (a los handshakes no les gusta viajar en el tiempo)

cr0x@server:~$ timedatectl status | sed -n '1,8p'
Local time: Sun 2025-12-28 10:25:44 UTC
Universal time: Sun 2025-12-28 10:25:44 UTC
RTC time: Sun 2025-12-28 10:25:44
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

Qué significa: El reloj está sincronizado. Bien.

Decisión: Si la hora está mal, arregla NTP primero. Problemas extraños de handshake y correlación de registros están garantizados cuando los relojes se desincronizan.

Guion de diagnóstico rápido

Cuando suena el teléfono y alguien dice “la VPN está caída”, usualmente se refieren a “una aplicación está rota”. No depures la aplicación primero. Depura el camino.

Primero: ¿el túnel está vivo?

En el hub: wg show — comprueba latest handshake para el spoke afectado.
En el spoke: wg show — confirma que habla con el endpoint del hub y que los contadores aumentan durante una prueba.
Si el handshake está obsoleto: comprueba alcanzabilidad UDP, IP/puerto del endpoint, keepalive de NAT y cambios recientes del ISP/router.

Segundo: ¿es correcto el enrutamiento en ambos extremos?

En el spoke: ip route get <remote-ip> — debería seleccionar wg0.
En el hub: ip route get <destination> — asegúrate de que apunte al peer correcto vía wg0.
Comprueba la LAN de la oficina: ¿los clientes tienen rutas de vuelta vía el gateway local?

Tercero: ¿el firewall hace lo que le pediste?

En el hub: nft list chain inet filter forward — observa contadores mientras reproducen el problema.
Busca drops que coincidan con las subredes/puertos relevantes.
Añade temporalmente una regla allow estrecha (subred origen + destino + puerto) para confirmar la hipótesis. Revierte si no prueba nada.

Cuarto: ¿es un problema MTU/fragmentación?

Usa pruebas de ping -M do -s a través de la VPN.
Si los paquetes pequeños funcionan y los grandes fallan o se quedan, ajusta la MTU de WireGuard y/o arregla el filtrado ICMP.

Quinto: ¿es DNS?

Si los usuarios pueden hacer ping a IPs pero no a nombres, deja de tocar rutas.
Comprueba resolvers, forwarders condicionales y configuraciones de split-DNS. Confirma que el servidor DNS es alcanzable desde la subred de rol.

El punto es velocidad: túnel → ruta → firewall → MTU → DNS. En ese orden. Siempre.

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

“El túnel está arriba pero no puedo alcanzar nada”

Síntoma: wg show muestra handshakes; pings a LAN remota fallan.

Causa raíz: Reenvío IP deshabilitado en hub o spoke, o rutas faltantes en el lado LAN.

Arreglo: Habilita net.ipv4.ip_forward=1. Asegura que los clientes de oficina enruten subredes remotas vía el gateway local; no asumas que lo saben mágicamente.

“Oficina A puede alcanzar Oficina B, pero no al revés”

Síntoma: Conectividad unidireccional; sesiones TCP cuelgan.

Causa raíz: Enrutamiento asimétrico o drops por rp_filter; también posibles problemas de estado del firewall.

Arreglo: Revisa rutas en ambos lados y en el hub. Ajusta rp_filter en gateways multihomed. Verifica que las reglas forward del hub permitan ambos sentidos o usa handling de established/related.

“Solo algunas apps fallan; transferencias de archivos se quedan; SSH funciona”

Síntoma: Paquetes pequeños triunfan; cargas grandes fallan.

Causa raíz: Agujero MTU / problemas de fragmentación, frecuentemente con ICMP bloqueado upstream.

Arreglo: Pon mtu 1420 (o menor) en wg0. Prueba con ping -M do. Arregla el filtrado ICMP donde sea posible.

“Se instaló un router nuevo en la oficina y ahora la VPN flaquea”

Síntoma: Handshakes intermitentes obsoletos; contadores de tráfico se congelan y luego saltan.

Causa raíz: Cambio en handling de NAT o timeouts de UDP; keepalive faltante.

Arreglo: Ajusta PersistentKeepalive = 25 en spokes detrás de NAT. Verifica que el puerto del hub sea alcanzable y no esté remapeado inesperadamente.

“Finanzas puede acceder a servicios de ingeniería (ups)”

Síntoma: Usuarios alcanzan cosas que no deberían; no hay denegaciones obvias del firewall.

Causa raíz: Regla allow demasiado amplia, o confiar en AllowedIPs como “política”.

Arreglo: Implementa default-drop en la cadena forward del hub y añade allows explícitos por rol. Mantén las reglas lo más estrechas posible: subred origen, subred destino, puertos.

“Después de un reinicio, nada enruta hasta que alguien ejecuta un comando”

Síntoma: Funciona tras intervención manual.

Causa raíz: Orden de servicios: WireGuard arriba antes que sysctl/nftables, o nftables no cargado.

Arreglo: Asegura persistencia de sysctl, habilita el servicio nftables, y haz que el bring-up de WireGuard dependa de la preparación de la red. Prueba arranque en frío, no solo reinicios calientes.

“DNS va lento entre sedes”

Síntoma: La primera consulta tarda segundos; luego va bien.

Causa raíz: El resolver intenta servidores DNS inalcanzables primero (orden errónea), o fragmentación UDP de respuestas DNS.

Arreglo: Asegura que los clientes usen primero el DNS interno alcanzable. Considera fallback TCP para DNS y arregla MTU si hace falta.

Tres micro-historias corporativas desde el terreno

Micro-historia 1: El incidente causado por una suposición incorrecta

Una empresa mediana conectó tres oficinas con un hub WireGuard nuevo. El diagrama de red parecía limpio. El plan de despliegue era simple: instalar gateways, añadir rutas, celebrar.

La suposición era del tipo que solo notas cuando duele: “los clientes aprenderán rutas automáticamente”. Los gateways tenían las rutas correctas. El hub tenía los AllowedIPs correctos. Los handshakes estaban frescos. Pings entre gateways funcionaban. Pero los usuarios no podían alcanzar nada a través de la VPN a menos que estuvieran en una subred donde el gateway fuese la ruta por defecto.

El helpdesk escaló a “VPN caída”. El SRE de guardia miró WireGuard primero, lo encontró sano, y perdió una hora persiguiendo problemas fantasma de firewall porque “túnel arriba” suele implicar “los caminos existen”. No fue así.

La solución fue dolorosamente ordinaria: actualizar los routers de oficina para anunciar rutas estáticas de las otras oficinas vía el gateway VPN local (o hacer que el gateway VPN fuera el gateway por defecto para las VLANs de rol). Tras eso, todo “mágicamente” funcionó, que es lo que parece el enrutamiento cuando lo haces correctamente.

La lección: cuando despliegas una VPN enrutada, tu LAN debe participar. Si el edge router de la oficina no sabe dónde está 10.10.20.0/24, tus clientes tampoco. Las redes no leen la mente.

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

Otra organización se puso ambiciosa. Querían reducir latencia entre las Oficinas B y C, así que añadieron un túnel directo spoke-a-spoke WireGuard “solo para tráfico pesado”. El hub seguía siendo el camino oficial. El túnel directo era la “vía rápida”.

Funcionó de maravilla en pruebas de laboratorio. En producción, creó una segunda verdad de enrutamiento. Algunas subredes preferían el túnel directo; otras seguían el hub. Las políticas de firewall vivían en el hub, así que ahora el tráfico o bien evitaba la política o bien era descartado dependiendo de qué camino eligiera la ruta ese día.

Luego vino el apagón más extraño: los compartidos de archivos funcionaban de B a C pero no de C a B, y solo para usuarios en una VLAN. Habían creado enrutamiento asimétrico accidental: los paquetes de petición tomaban el camino directo, las respuestas volvían por el hub. Los firewalls stateful no aplauden la creatividad.

La “optimización” fue eliminada. Volvieron a hub-and-spoke, y luego mejoraron el rendimiento de la forma aburrida: ajustaron MTU correctamente, arreglaron QoS en el borde WAN y dejaron de ejecutar backups durante horas de trabajo. La latencia mejoró y, más importante, volvió la predictibilidad.

La lección: en redes multi-sede, “un túnel más” casi nunca es “solo un túnel más”. Es un universo de enrutamiento adicional.

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

Una tercera empresa trató su hub como un servicio de producción real. Mantenían configs en control de versiones. Cada cambio tenía una pequeña descripción y un impacto esperado. También tenían una página “diagnóstico rápido VPN” pegada dentro del cuaderno de guardia, como si fuera 2004 y las impresoras aún importaran.

Una tarde, la Oficina A perdió acceso a una aplicación interna alojada en la Oficina C. El túnel estaba arriba. La app estaba arriba. La gente empezó a señalar con el dedo a “la VPN” y “el firewall” como si fueran estados de ánimo.

El ingeniero de guardia siguió el runbook: comprobó handshakes (frescos), comprobó enrutamiento (correcto), comprobó contadores forward de nftables (drops aumentando en la regla default drop). Eso lo redujo a política. El último cambio fue una regla allow de Ingeniería que por error excluía una subred usada por esa aplicación.

Revirtieron la regla en minutos, restauraron el servicio y luego reintrodujeron una regla corregida con un plan de pruebas adecuado. El incidente se mantuvo pequeño porque los cambios eran trazables y el orden de depuración fue disciplinado.

La lección: la higiene aburrida—configs versionadas, cambios estrechos y un orden de diagnóstico determinista—vence al heroísmo. Siempre.

Listas de verificación / plan paso a paso

Plan de construcción paso a paso (haz esto, en este orden)

Arregla solapamientos de IP: asegura que cada oficina tenga subredes únicas. Si no, renumera ahora. No te “temporices” con NAT y conviertas la deuda técnica en permanente.
Define subredes de rol: crea VLANs/subredes por rol donde sea posible. Empieza con IT/Admin y Finanzas; añade más solo cuando sea necesario.
Provisiona el hub: IP pública estable, Linux, WireGuard, nftables, NTP, logging, agente de monitorización.
Provisiona los tres spokes: cada uno con WireGuard y capacidad para enrutar entre LAN y wg0.
Genera claves: un par de claves por gateway (y opcionalmente por rol o por dispositivo si expandes más tarde).
Configura WireGuard: peers en el hub para cada spoke con AllowedIPs correctos; los spokes apuntan al endpoint del hub con subredes remotas en AllowedIPs.
Habilita forwarding y sysctls básicos: ip_forward, ajuste de rp_filter según necesidad.
Instala enrutamiento en la LAN de oficina: el router de oficina anuncia rutas de otras oficinas vía el gateway local, o el gateway VPN se convierte en gateway de la VLAN.
Implementa firewall en el hub: default drop para forward, allows explícitos por rol. Mantén un conjunto temporal “break-glass” que puedas aplicar en incidentes graves.
Plan DNS: decide central vs forwarders condicionales. Prueba resolución de nombres desde cada VLAN de rol.
Validación MTU: configura MTU de wg (empezar en 1420), prueba pings de paquetes grandes y cargas reales (copias de archivos, HTTPS, BD).
Monitorización: controla edad de handshake, tasas de transferencia, drops (contadores nft), errores de interfaz, CPU y ancho de banda.
Documenta: plan de IPs, reglas por rol, propiedad de claves y orden de diagnóstico rápido. Tu yo futuro es un stakeholder.

Checklist previo al cambio (cada vez que toques políticas)

¿Sé qué subredes/roles serán impactados?
¿Tengo un caso de prueba (IP origen, IP destino, puerto) para validar?
¿Verifiqué contadores/registros actuales para establecer línea base?
¿El cambio es estrecho (principio de menor privilegio) y reversible?
¿Tengo acceso por consola si me dejo fuera del hub?

Checklist post-cambio (pruébalo, no lo asumas)

wg show en el hub: todos los peers siguen handshaking
Ping y una prueba de aplicación por rol (Finanzas, Eng, IT)
Revisa contadores nftables: incrementos esperados en reglas allow; regla drop estable
Valida resolución DNS para zonas internas
Registra el cambio y el impacto observado

Preguntas frecuentes

1) ¿Debería hacer malla completa en vez de hub-and-spoke?

Para tres oficinas puedes hacerlo, pero te arrepentirás cuando añadas reglas por rol y necesites aplicación consistente. Hub-and-spoke centraliza la política y hace la resolución de problemas más simple.

2) ¿Puedo imponer roles usando solo AllowedIPs?

No de forma fiable. AllowedIPs es burdo y está orientado principalmente a enrutamiento y acotamiento de peers. Usa nftables en el hub para aplicar acceso por roles, porque ahí puedes expresar “Finanzas puede alcanzar estos puertos en esas subredes”.

3) ¿Dónde deben vivir las reglas de acceso: en el hub o en los spokes?

Coloca la política canónica en el hub. Puedes añadir reglas locales de salida en los spokes para defensa en profundidad, pero no conviertas la política en un puzzle distribuido a menos que disfrutes del comportamiento inconsistente.

4) ¿Necesito BGP/OSPF para tres sitios?

No. El enrutamiento estático está bien y a menudo es mejor para la predictibilidad. El enrutamiento dinámico puede ser útil más adelante, pero añade un segundo plano de control a depurar. Gánate esa complejidad.

5) ¿Cómo manejo subredes solapadas si renumerar es políticamente imposible?

Puedes usar NAT (1:1 o masquerade) en los spokes, pero trátalo como deuda técnica con interés. Documenta las traducciones, espera casos borde en aplicaciones y planea un proyecto de renumeración de todos modos.

6) ¿Debería ejecutar el hub en la nube o on-prem?

La nube suele ser más fácil para una IP pública estable, buen ancho de banda y manos remotas. On-prem puede ser válido si tienes Internet y energía redundantes. El factor decisorio es la madurez operativa, no la ideología.

7) ¿Cómo añado usuarios remotos más adelante sin romper el modelo site-to-site?

Añade una interfaz o grupo de peers de WireGuard separado para usuarios remotos, asígnales una subred dedicada (p. ej., 10.200.10.0/24) y aplica reglas de rol en el hub de la misma manera. Evita mezclar clientes road-warrior en la misma pool de direcciones que los gateways.

8) ¿Qué hace “PersistentKeepalive” y cuándo lo necesito?

Envía paquetes periódicos para mantener mappings NAT vivos. Úsalo en spokes detrás de NAT (común) y en clientes que se mueven. No lo pongas en el hub con IP pública a menos que tengas una razón específica.

9) ¿Cómo hago esto altamente disponible?

Ejecuta dos hubs y usa anycast/BGP (avanzado) o DNS + tooling de failover (más simple), además de túneles duales desde cada spoke. Mantén el estado mínimo (WireGuard es casi sin estado), pero tu firewall y DNS también deben ser redundantes.

10) ¿Qué debo registrar sin ahogarme en datos?

Registra forwards descartados con rate limit en el hub, controla edad de handshake y contadores de tráfico, y captura cambios de configuración. No registres cada paquete aceptado; tu sistema de almacenamiento merece algo mejor.

Próximos pasos que harán el lunes más tranquilo

Si quieres una VPN que se comporte como infraestructura en lugar de un truco de magia, constrúyela como infraestructura: subredes únicas, diseño enrutado, política central y observabilidad. WireGuard hub-and-spoke es un patrón sólido para tres oficinas, especialmente cuando necesitas acceso por rol en vez de “todos pueden ver todo”.

Pasos prácticos siguientes:

Escribe el plan de IPs y subredes por rol, y aplica la unicidad entre oficinas.
Levanta el hub con WireGuard + nftables y forwarding por defecto-drop.
Activa un spoke, valida enrutamiento end-to-end, luego clona el patrón a los otros dos.
Implementa reglas por rol como allows explícitos, observa contadores y mantén una reversión lista.
Añade monitorización para edad de handshake, ancho de banda y contadores de drops, y mantén el orden de diagnóstico rápido a mano.

Seguirás recibiendo tickets. Pero serán del tipo solucionable, no del tipo sobrenatural.