VPN sitio a sitio con WireGuard: unir dos redes (guía 2026)

Aviso de afiliación — Este artículo contiene enlaces de afiliado de Contabo. Si pides un VPS a través de ellos, ganamos una comisión sin coste extra para ti. Todos los comandos y configuraciones de abajo están documentados a partir de las fuentes oficiales de WireGuard y escritos para ser reproducibles en tus propias máquinas.

Una VPN sitio a sitio une dos redes enteras para que se comporten como una sola. Cada host de la LAN de la oficina puede alcanzar cada host de la LAN de casa — tu NAS, una impresora, un hipervisor, una base de datos — sin instalar un cliente VPN en cada dispositivo. WireGuard lo hace ligero y rápido: un solo puerto UDP, unas pocas líneas de configuración, criptografía en espacio de núcleo. Esta guía construye un túnel WireGuard sitio a sitio funcional desde cero, y luego explica los tres errores recurrentes: AllowedIPs, el reenvío IP y el enrutamiento de los hosts.

Usaremos una topología concreta y habitual: el Sitio A es una LAN doméstica o de oficina detrás de NAT (sin IP pública utilizable), y el Sitio B es un VPS con IPv4 pública que actúa de hub siempre activo. La misma configuración también une dos casas, dos oficinas o dos centros de datos — solo cambian las subredes.

Sitio a sitio vs acceso remoto: qué cambia de verdad

Si ya has configurado WireGuard para un portátil, el 90 % de todo esto te resultará familiar. El cambio de mentalidad es pequeño pero crucial:

• Acceso remoto (road-warrior): un dispositivo se une a la red. Su par anuncia una única dirección de túnel — AllowedIPs = 10.66.66.2/32.
• Sitio a sitio: una red entera se une. El par anuncia la subred LAN que tiene detrás — AllowedIPs = 10.66.66.2/32, 192.168.10.0/24 — y el equipo WireGuard reenvía por cada host de esa LAN.

Todo lo demás — claves, handshake, puerto UDP — es idéntico. Si tu handshake nunca se completa, las causas son las mismas que en cualquier túnel; recorre la lista de soluciones del handshake de WireGuard antes de culpar a la parte sitio a sitio.

Planifica primero el direccionamiento (5 minutos que ahorran horas)

Antes de tocar una configuración, anota tres rangos. Equivocarte aquí es la causa nº 1 de un túnel que conecta pero no transporta tráfico de hosts.

La regla dura: las dos LAN no deben solaparse. Si ambos lados usan hoy 192.168.1.0/24, renumera uno ahora. Un host no puede enrutar a una subred remota idéntica a la suya — tratará la dirección como local y nunca entregará el paquete a WireGuard. Si el cálculo de subredes se te escapa, nuestra explicación de qué es una subred cubre el CIDR de forma sencilla.

Paso 1 — Aprovisionar el hub (Sitio B, el VPS)

El Sitio B necesita una IPv4 pública y un puerto UDP abierto. Usamos un Contabo Cloud VPS 10 (4 vCPU, 8 GB RAM, 75 GB NVMe) a 5,50 €/mes en el plan de 12 meses — sobrado para un túnel, cómodo si además ejecuta otros servicios. Si aún no tienes un VPS, hazte con el Contabo Cloud VPS 10; elige una región cercana al sitio que envía más tráfico. Para una instalación limpia de WireGuard en él, sigue la guía paso a paso de Contabo + WireGuard y vuelve aquí para el enrutamiento sitio a sitio.

Instala WireGuard y genera las claves en el VPS:

sudo apt update && sudo apt install -y wireguard
umask 077
wg genkey | tee siteB.key | wg pubkey > siteB.pub

Paso 2 — Montar el router WireGuard en el Sitio A

El equipo WireGuard del Sitio A es cualquier máquina Linux siempre encendida de la LAN — una Raspberry Pi, una VM pequeña, un portátil viejo. No necesita IP pública; marca hacia el VPS. Genera sus claves del mismo modo:

wg genkey | tee siteA.key | wg pubkey > siteA.pub

Esta máquina se convierte en la puerta de enlace de la subred remota, así que debe reenviar paquetes entre su interfaz LAN y la interfaz WireGuard.

Paso 3 — Las dos configuraciones

Aquí está todo el túnel. Fíjate en cómo el AllowedIPs de cada lado incluye la LAN del otro sitio — esa línea es la que convierte un enlace punto a punto en un enlace red a red.

Sitio B — el hub VPS (/etc/wireguard/wg0.conf):

[Interface]
Address = 10.66.66.1/24
ListenPort = 51820
PrivateKey = <siteB.key>
# forward + masquerade para que los hosts del Sitio A también alcancen internet vía el VPS
PostUp = sysctl -w net.ipv4.ip_forward=1
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# Sitio A
PublicKey = <siteA.pub>
AllowedIPs = 10.66.66.2/32, 192.168.10.0/24

Sitio A — el router LAN (/etc/wireguard/wg0.conf):

[Interface]
Address = 10.66.66.2/24
PrivateKey = <siteA.key>
PostUp = sysctl -w net.ipv4.ip_forward=1
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT

[Peer]
# Sitio B (el hub VPS)
PublicKey = <siteB.pub>
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.66.66.0/24, 192.168.20.0/24
PersistentKeepalive = 25

Dos detalles que importan:

• PersistentKeepalive = 25 va en el lado detrás de NAT (Sitio A). Envía un paquete diminuto cada 25 segundos para que el router doméstico mantenga abierto el camino UDP y el VPS siempre pueda responder.
• Endpoint solo aparece en el bloque de par del Sitio A — es el Sitio A quien llama al VPS. El VPS aprende la dirección del Sitio A al llegar el primer paquete, así que su bloque de par no lleva Endpoint.

Levanta ambos túneles con sudo wg-quick up wg0 y comprueba sudo wg show. Un latest handshake de menos de dos minutos en ambos lados significa que el enlace está vivo.

Paso 4 — El paso que todos olvidan: el enrutamiento de los hosts

Aquí es donde la mayoría de los túneles sitio a sitio se atascan. Los routers se hacen ping en 10.66.66.x, pero un portátil del Sitio A sigue sin alcanzar un NAS del Sitio B. ¿Por qué? Porque los demás hosts de cada LAN no saben que el equipo WireGuard es la puerta a la subred remota. Envían el paquete a su puerta de enlace por defecto, que no tiene ruta para 192.168.20.0/24, y muere.

Tienes dos formas limpias de arreglarlo:

1. Ruta estática en la puerta de enlace de la LAN (lo mejor). En el router principal del Sitio A, añade una ruta estática: destino 192.168.20.0/24, puerta de enlace = la IP LAN del equipo WireGuard del Sitio A (p. ej. 192.168.10.5). Haz el espejo en el Sitio B. Ahora cada host hereda la ruta automáticamente. La mayoría de routers domésticos y profesionales admiten rutas estáticas en su panel de administración.
2. Rutas estáticas por host. Si no puedes tocar el router, añade una ruta en cada máquina que necesite acceso al otro sitio:

# en un host del Sitio A, alcanzar la LAN del Sitio B vía el equipo WireGuard local
sudo ip route add 192.168.20.0/24 via 192.168.10.5

Si el equipo WireGuard es la puerta de enlace por defecto de tu LAN, puedes saltarte esto por completo — ya reenvía. Conceptualmente es un problema de enrutamiento, no de VPN; la misma lógica que el reenvío de puertos pero aplicada a una subred entera en lugar de a un solo puerto.

Paso 5 — Cortafuegos en el camino de reenvío

Reenviar sin regla de cortafuegos es dejar pasar o nada o todo. Sé explícito. En el hub VPS, el PostUp de arriba ya acepta el tráfico reenviado desde wg0; ajústalo si solo quieres que hablen ciertas subredes:

# permitir solo LAN Sitio A <-> LAN Sitio B, descartar el resto
iptables -A FORWARD -s 192.168.10.0/24 -d 192.168.20.0/24 -i wg0 -j ACCEPT
iptables -A FORWARD -s 192.168.20.0/24 -d 192.168.10.0/24 -o wg0 -j ACCEPT

Haz las reglas persistentes (iptables-save, o netfilter-persistent save en Debian/Ubuntu) para que sobrevivan a un reinicio. El puerto UDP único también debe estar abierto delante del VPS — consulta qué puerto usa WireGuard y cómo abrirlo si el handshake nunca arranca.

Verificar el camino completo

Ejecuta esto en orden y detente en el primer fallo:

1. ¿Túnel activo? sudo wg show en ambos extremos → latest handshake reciente, transfer distinto de cero.
2. ¿Router a router? Desde el equipo WireGuard del Sitio A: ping 10.66.66.1. Falla → es un problema de túnel, no de sitio a sitio.
3. ¿Router a LAN remota? Desde el equipo del Sitio A: ping 192.168.20.1. Falla → AllowedIPs o ip_forward en el Sitio B.
4. ¿Host a host remoto? Desde un portátil del Sitio A: ping 192.168.20.50. Falla aquí pero el paso 3 funcionaba → enrutamiento de hosts (paso 4).

Esta escalera de cuatro líneas aísla en menos de un minuto la capa exacta que está rota.

Cuándo añadir más sitios — hub-and-spoke

Para unir tres redes o más, mantén el VPS como hub central y añade cada LAN nueva como par satélite en él. Cada satélite incluye todas las demás subredes LAN en su AllowedIPs (enrutadas vía el hub), y el hub incluye la LAN de cada satélite. Esto sigue siendo simple hasta un puñado de sitios. Más allá — o si quieres rotación automática de claves, ACL y atravesar NAT sin IP pública en ningún lado — un plano de control en malla como Tailscale o Headscale da menos trabajo que editar los pares a mano; sopésalo en nuestro comparativa Tailscale vs WireGuard self-host.

Por qué autoalojar el hub en vez de un servicio gestionado

Un enlace sitio a sitio es precisamente donde poseer el equipo compensa: sin precio por puesto, sin límite de datos, sin terceros en el camino entre tus dos redes. Un Contabo Cloud VPS 10 a 5,50 €/mes ofrece IPv4 pública, root completo, tráfico ilimitado (uso razonable) y la libertad de abrir el único puerto UDP que necesitas — el hub siempre activo ideal para unir tus sitios. Constrúyelo una vez y funciona durante años.

Para profundizar

• VPN autoalojada en Contabo: guía completa de WireGuard 2026
• El handshake de WireGuard no se completa: la lista completa de soluciones
• ¿Qué es una subred? Subnetting y CIDR explicados
• El reenvío de puertos explicado: alcanzar un servidor detrás de tu router
• Tailscale vs WireGuard self-host: cuál elegir
• Plantillas de configuración WireGuard listas para usar 2026

Fuentes y referencias:

• Libro blanco de WireGuard — Jason A. Donenfeld
• Quickstart de WireGuard y docs de wg-quick
• Páginas de manual wg(8) y wg-quick(8)
• Arch Wiki — WireGuard (enrutamiento y sitio a sitio)

Publicado el 2026-06-26. Topología validada en Debian 12 y Ubuntu 24.04 con un hub Contabo Cloud VPS 10 y un router LAN Raspberry Pi. Tus subredes, modelos de router y el comportamiento NAT de tu ISP serán distintos — confirma siempre cada capa con wg show, ping e ip route antes de dar por final una configuración.

Recordatorio: ejecutar WireGuard y autoalojar una VPN es legal en la UE, EE. UU., Canadá y la mayoría de países democráticos. VPNSmith publica este contenido con fines educativos.