WireGuard Hub-and-Spoke en Linux: cómo unir 3 o más nodos detrás de un servidor central (Guía 2026)

La topología hub-and-spoke de WireGuard es el siguiente paso después del P2P puro: tienes un nodo central (hub) al que se conectan N nodos (spokes), y el hub enruta tráfico entre ellos. Es la topología para cuando tienes más de 3 nodos pero quieres seguir operando la VPN manualmente sin caer en Tailscale. Esta guía documenta la configuración que recomiendo, con IP ranges por spoke, el truco del AllowedIPs para que cada nodo sepa qué red está detrás del otro, y la integración con DNS para que `db.internal` resuelva al spoke correcto.

Si P2P te quedó corto y Tailscale te parece overkill, esto es el medio justo.

---

Por qué hub-and-spoke y no punto a punto ni full mesh

Si ya configuraste un túnel WireGuard entre dos máquinas y quisiste sumar una tercera, te encontraste con el momento incómodo de elegir topología. Las guías rápidas suelen mostrar el caso road warrior (un servidor central y muchos clientes móviles), pero hay otro patrón que domina la realidad operativa de los sysadmins en LATAM y Europa: tres o más nodos Linux fijos que necesitan hablar entre sí como si estuvieran en la misma LAN. Una oficina en Bogotá con un servidor de aplicaciones, una réplica de base de datos en una VPS en São Paulo y un nodo de CI en un homelab en Buenos Aires. O un clúster K3s repartido entre tres bare-metal en distintos ISPs. O tres sucursales de una pyme que comparten una base central de inventario.

En todos esos casos hay tres opciones de topología WireGuard, y solo una escala bien:

• Punto a punto: N nodos requieren N×(N-1)/2 túneles independientes. Con 4 nodos son 6 túneles, con 6 nodos son 15. Mantener claves, IPs y reglas de firewall para 15 túneles es una pesadilla operacional.
• Full mesh: cada nodo habla directo con todos los demás. Misma cuenta de túneles que punto a punto, pero permite ruteo spoke-to-spoke sin pasar por el hub. Útil solo cuando necesitas latencia mínima entre todos los pares.
• Hub-and-spoke: un nodo central (el hub) actúa como rendezvous y router entre todos los demás (los spokes). Solo se configuran N-1 túneles por nodo, todos hacia el hub. La comunicación spoke-to-spoke pasa a través del hub, lo que suma un hop de latencia pero simplifica drásticamente la operación, el firewall, las IPs y el troubleshooting.

Para la mayoría de equipos chicos y medianos, hub-and-spoke es la respuesta correcta. La latencia extra del hop por el hub (típicamente 1-5 ms si el hub está cerca geográficamente, 30-80 ms si está en otro continente) es irrelevante para tráfico de aplicación, base de datos o backups. Lo que importa es que cuando algo falla, hay un solo lugar donde mirar: el hub. Y cuando sumás un quinto o séptimo nodo, agregás un solo túnel nuevo en el hub y un solo túnel nuevo en el spoke, sin tocar el resto de la red.

Esta guía asume kernel Linux 5.6 o superior en todos los nodos (WireGuard mergeado upstream desde enero 2020, cualquier distro moderna lo trae). Si tienes un kernel más viejo, instala wireguard-dkms + wireguard-tools desde los repos de tu distro antes de seguir.

Qué necesitas antes de empezar

Antes de tocar wg-quick, reuní esta información. Detenerse a medio setup a buscar una IP pública o una clave te hace perder contexto y termina en AllowedIPs mal escritas:

• 3 o más máquinas Linux con kernel 5.6+ y acceso root (o capabilities de red). El hub típicamente corre en una VPS con IP pública estable; los spokes pueden ser bare-metal, VPS o containers LXC con forwarding habilitado.
• Una IP pública IPv4 estable para el hub. Si tu hub está detrás de CGNAT, esta guía no aplica directo — necesitas un relay externo o mudar a Tailscale/Headscale, que resuelven ese caso mejor. Para ISPs residenciales de LATAM (Claro, Telmex, VTR, etc.) es muy común tener CGNAT; verifica con un curl ifconfig.me y compara con la IP de tu interfaz WAN.
• Un puerto UDP libre en el hub, típicamente 51820 pero cualquier alto (>1024) sirve. Confirmá que está abierto y reachable con nc -uvz <ip-hub> 51820 desde un spoke antes de empezar.
• Un rango de IPs privadas para la red WireGuard. Convención común: 10.10.0.0/24 con el hub en 10.10.0.10 y cada spoke en 10.10.0.11, 10.10.0.12, etc. NO uses rangos que ya estén en uso en tu LAN física (típicos: 192.168.0.0/24, 192.168.1.0/24, 10.0.0.0/24) o vas a tener routing confuso entre las dos redes.
• Conectividad a internet desde cada nodo. Los spokes pueden estar detrás de NAT doméstico (eso está bien, lo resolvemos con persistent keepalive), pero el hub debe ser accesible directamente desde internet en el puerto UDP que elijas.

Diseñá el addressing del hub y los spokes

Antes de generar claves, asigná las IPs WireGuard a cada nodo. Una tabla mental te evita errores:

Rol	Hostname	IP física pública	IP WireGuard
Hub	wg-hub-bog	203.0.113.10	10.10.0.10/24
Spoke 1	app-bog	198.51.100.5	10.10.0.11/24
Spoke 2	db-sao	192.0.2.20	10.10.0.12/12
Spoke 3	ci-bue	dinámica (casa)	10.10.0.13/24

El hub escucha en un puerto fijo (51820) y los spokes mantienen conexiones persistentes hacia él. Cada spoke tiene una IP WireGuard única. Esta tabla es la fuente de verdad — cuando agregues un cuarto nodo en seis meses, agregás una fila y un solo [Peer] en el hub, nada más.

Generar las claves (cryptokey, una por nodo)

WireGuard usa criptografía de curva elíptica Curve25519. Cada nodo tiene un par de claves: una privada (que NO sale del nodo) y una pública (que se comparte con los peers). Generá las claves en cada máquina:

# En el hub (203.0.113.10)
umask 077
wg genkey | tee /etc/wireguard/hub_private.key | wg pubkey > /etc/wireguard/hub_public.key
chmod 600 /etc/wireguard/hub_private.key
cat /etc/wireguard/hub_public.key

El comando umask 077 antes de genkey garantiza que las claves se creen con permisos 600 (solo root). El tee guarda la privada mientras simultáneamente la pipea a wg pubkey para derivar la pública. La clave privada NO debe compartirse nunca, ni siquiera entre tus propios nodos: si el hub tiene la privada del spoke1, un compromiso del hub expone el spoke1. Cada nodo solo conoce su propia privada y las públicas de sus peers.

Repetí el procedimiento en cada spoke (app-bog, db-sao, ci-bue) y guardá las tres claves públicas. Las necesitas para escribir los archivos .conf del hub. Las privadas de los spoke quedan en cada máquina y nunca tocan el hub.

Configurar el hub

El hub es el archivo más denso porque conoce a todos los peers. Editá /etc/wireguard/wg0.conf:

sudo install -d -m 700 /etc/wireguard
sudo tee /etc/wireguard/wg0.conf >/dev/null <<'EOF'
[Interface]
Address = 10.10.0.10/24
ListenPort = 51820
PrivateKey = <HUB_PRIVATE_KEY>
# Habilitar forwarding para que el hub rutee tráfico spoke-to-spoke
PostUp = sysctl -w net.ipv4.ip_forward=1
PostUp = iptables -t nat -A POSTROUTING -s 10.10.0.0/24 ! -d 10.10.0.0/24 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.10.0.0/24 ! -d 10.10.0.0/24 -j MASQUERADE
[Peer]
# app-bog
PublicKey = <APP_BOG_PUBLIC_KEY>
AllowedIPs = 10.10.0.11/32
[Peer]
# db-sao
PublicKey = <DB_SAO_PUBLIC_KEY>
AllowedIPs = 10.10.0.12/32
[Peer]
# ci-bue (IP dinámica, por eso no se filtra por Endpoint)
PublicKey = <CI_BUE_PUBLIC_KEY>
AllowedIPs = 10.10.0.13/32
PersistentKeepalive = 25
EOF
sudo chmod 600 /etc/wireguard/wg0.conf

El bloque [Interface] define la IP del hub y el puerto de escucha. Los PostUp y PostDown activan IP forwarding y NAT solo cuando la interfaz está arriba — cuando bajás la interfaz con wg-quick down wg0, el NAT se limpia automáticamente. Cada [Peer] es un spoke: su clave pública (la que generaste en su máquina) y un AllowedIPs estricto a la IP WireGuard del spoke (/32, no la subred completa, para evitar superposiciones accidentales).

El PersistentKeepalive = 25 es importante para el spoke con IP dinámica (ci-bue): NAT doméstico cierra conexiones UDP inactivas típicamente después de 30-120 segundos. Mandando un keepalive cada 25 segundos, el NAT mantiene la traducción activa y el hub puede responder incluso si el spoke cambió de IP. Levantá la interfaz:

sudo systemctl enable --now wg-quick@wg0
sudo wg show

wg show te debe listar la interfaz wg0 con la listen port 51820 y tres peers vacíos hasta que los spokes se conecten.

Configurar los spokes

Cada spoke es más simple porque solo conoce al hub. Editá /etc/wireguard/wg0.conf en el spoke 1 (app-bog):

sudo tee /etc/wireguard/wg0.conf >/dev/null <<'EOF'
[Interface]
Address = 10.10.0.11/24
PrivateKey = <APP_BOG_PRIVATE_KEY>
[Peer]
# Hub
PublicKey = <HUB_PUBLIC_KEY>
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.10.0.0/24
PersistentKeepalive = 25
EOF
sudo chmod 600 /etc/wireguard/wg0.conf
sudo systemctl enable --now wg-quick@wg0

El AllowedIPs = 10.10.0.0/24 en el spoke dice: todo el tráfico cuya destino sea la red WireGuard, mandalo por el hub. Esto incluye tráfico hacia el propio hub (10.10.0.10), hacia db-sao (10.10.0.12) y hacia ci-bue (10.10.0.13). El PersistentKeepalive = 25 mantiene la conexión activa desde el lado del spoke, lo cual es útil para el spoke con IP dinámica y para que el hub pueda responderle.

Repetí el archivo en db-sao y ci-bue, ajustando Address, PrivateKey y el comentario. En los tres casos el Endpoint apunta al hub porque es el único peer directo.

Verificar la conectividad spoke-a-spoke

Después de levantar wg-quick@wg0 en los tres nodos, espera 5-10 segundos y valida desde el hub que cada spoke aparezca con latest handshake reciente:

sudo wg show

La salida debe mostrar algo como peer: <APP_BOG_PUBLIC_KEY> latest handshake: 12 seconds ago para cada peer. Si dice (none) en handshake, el spoke no llegó al hub: revisa firewall upstream, NAT en el spoke o el Endpoint. Una prueba de ruteo spoke-a-spoke:

# Desde app-bog, ping al db-sao via el hub
ping -c 3 10.10.0.12
# Desde app-bog, ping al ci-bue
ping -c 3 10.10.0.13

Si los pings funcionan, tienes una red hub-and-spoke operativa: app-bog habla con db-sao y ci-bue pasando por el hub. traceroute 10.10.0.12 desde app-bog debe mostrar un solo hop (el hub, 10.10.0.10) — esa es la latencia extra del patrón, y es la trade-off por la simplicidad operacional.

Cuándo NO usar hub-and-spoke (y qué usar en su lugar)

El patrón no es universal. Hay escenarios donde otra topología rinde mejor:

• Tres o más nodos con tráfico intenso spoke-a-spoke: si tu base de datos replica entre db-sao y db-bog con 500 Mbps constantes, sumar el hop por el hub duplica el ancho de banda usado en el hub y agrega latencia. En ese caso, agrega un [Peer] directo en los dos nodos de base de datos (túnel P2P) y mantén el hub para el resto. Es híbrida, pero funciona.
• Spoke detrás de CGNAT doble: si el hub también está detrás de CGNAT (raro pero pasa con algunas VPS IPv6-only o ciertos carriers móviles), ningún extremo puede iniciar el túnel. La solución no es WireGuard puro sino un relay externo con IP pública, o mudar a Tailscale/NetBird/Headscale que coordinan NAT traversal con un servidor DERP.
• Más de ~50 spokes: WireGuard escala bien hasta decenas de peers por interfaz, pero arriba de 50-100 los [Peer] en el hub se vuelven difíciles de mantener. En ese rango evalúa una solución de gestión (Netmaker, Headscale con ACLs, o un plano de control propio con Ansible + etcd).
• Necesidad de roaming entre hubs: si tus nodos se mueven geográficamente y quieres failover entre dos hubs, WireGuard puro no lo resuelve — cada nodo solo puede tener un Endpoint activo por peer. La solución es un script que cambia el Endpoint en runtime con wg set wg0 peer <pubkey> endpoint <new-ip:port>, o un cliente mesh como Tailscale que lo automatiza.

Para el 90% de los casos sysadmin — homelab con 3-8 nodos, pyme con 3-5 sedes, cluster K3s multi-región, replica de base de datos entre 2-3 datacenters — hub-and-spoke es la elección correcta. Los [Peer] en el hub son lineales en cantidad de nodos, no cuadráticos. El troubleshooting es localizado al hub. Y cuando un spoke se cae, solo afecta a ese spoke — los demás siguen hablando entre sí a través del hub.

Operación del día a día

Después del setup inicial, hay cuatro operaciones que vas a repetir. Las cubro en orden de frecuencia.

Sumar un nuevo spoke: en el spoke nuevo generas las claves, le das la pública al operador del hub, ese operador agrega un [Peer] con la pública nueva y la IP WireGuard asignada. En el spoke nuevo, configuras el archivo .conf apuntando al hub. Sin tocar los demás spokes. Sin reiniciar nada en el hub si usas wg syncconf:

# En el hub, sin bajar la interfaz
sudo wg syncconf wg0 <(wg-quick strip wg0)

Cambiar clave de un spoke (rotación): generas un par nuevo en el spoke, reemplazás la línea PublicKey en el bloque [Peer] del hub, haces wg syncconf. La conexión se cae y se restablece en segundos. Cambiar clave del hub (rotación): más disruptivo — todos los spokes tienen que actualizar su [Peer] PublicKey en simultáneo, o todos se caen al mismo tiempo. hazlo en una ventana de mantenimiento.

Monitoreo: sudo wg show te da lo básico (latest handshake, transfer, endpoint). Para métricas más ricas, sudo wg show all dump da una salida parseable con awk. Integrá con tu stack de monitoring exportando transfer_rx y transfer_tx por peer a Prometheus con node_exporter + textfile collector.

Troubleshooting de un spoke que no se conecta: el patrón mental es siempre tres capas — (1) ¿UDP llega al hub? (nc -uvz hub 51820 desde el spoke), (2) ¿la clave es correcta? (sudo wg show en el hub debe mostrar el peer), (3) ¿la IP WireGuard del spoke está en el AllowedIPs del hub? (sudo wg show wg0 en el hub). Si todo eso está bien y aún no hay handshake, es casi seguro un firewall stateful upstream en algún NAT que cierra UDP — el PersistentKeepalive = 25 lo mitiga en el 95% de los casos. Si no, revisa conntrack -L en el spoke.

Resumen

WireGuard hub-and-spoke es la topología correcta para la mayoría de redes de 3+ nodos Linux administradas por sysadmins individuales o equipos chicos: linear en cantidad de túneles, fácil de debuggear, y agrega una sola capa de indirección (un hop por el hub) que para tráfico de aplicación es insignificante. Las claves del éxito son tres: IP pública estable en el hub, rango WireGuard único fuera de tu LAN física, y PersistentKeepalive en cada spoke para que el NAT doméstico no corte la conexión. Con eso, tienes una VPN privada entre tus nodos en menos de una tarde, y agregar un quinto o décimo nodo toma minutos, no horas.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux