VPNSmith
self-host-vpnINFO

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

Une dos LAN completas con WireGuard - oficina y casa, dos centros de datos, o sucursal y sede. Enrutamiento de subred, AllowedIPs, NAT y cortafuegos, paso a paso en un VPS.

Por Eric Gerard · Fundador · VPNSmith - Especialista en VPN self-host y VPS GDPR10 min de lecturaFoto vía Pixabay

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.

Cables Ethernet azules con marcas de cinta de colores conectados a los puertos numerados de un switch, con LEDs verdes encendidos debajo
Cables Ethernet azules con marcas de cinta de colores conectados a los puertos numerados de un switch, con LEDs verdes encendidos debajo

Una VPN cambia su IP. No cambia su navegador.

Un túnel sustituye la dirección que ve un servicio. No cambia nada de lo que su navegador anuncia por su cuenta - fuentes, pantalla, zona horaria, pila gráfica - y esa combinación suele bastar para reconocerle de una sesión a otra.

Mida su huella de navegador - medición pasiva, sin preguntas, sin cuenta, sin correo electrónico.

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.

RangoEjemploRegla
Subred del túnel10.66.66.0/24Propia de la VPN, no debe solaparse con ninguna LAN
LAN Sitio A192.168.10.0/24La red de casa/oficina
LAN Sitio B192.168.20.0/24La red remota - debe diferir del Sitio A

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

Fuentes y referencias:

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á. VPNSmith publica este contenido con fines educativos.

★ Datacenter Núremberg GDPR · ✓ IPv4 dedicada incluida · 200+ Mbps garantizados

Aloja tu VPN en tu propio VPS → ContaboAcceso root completo · IPv4 pública · elige tu región→

Preguntas frecuentes

¿Qué diferencia hay entre una configuración sitio a sitio y una de acceso remoto (road-warrior)?
Una configuración de acceso remoto conecta un solo dispositivo - tu portátil, tu móvil - a una red. Una configuración sitio a sitio conecta dos redes enteras: cada máquina de la LAN A puede alcanzar cada máquina de la LAN B, de forma transparente, sin instalar WireGuard en cada dispositivo. Toda la diferencia vive en AllowedIPs y el enrutamiento: un par de acceso remoto anuncia una única IP de túnel en /32, un par sitio a sitio anuncia la subred LAN remota (p. ej. 192.168.20.0/24) y los routers reenvían por las máquinas que tienen detrás.
¿Necesitan los dos sitios una IP pública?
No - solo un lado necesita una IP pública alcanzable y un puerto UDP abierto. WireGuard es punto a punto: el lado detrás de NAT (una conexión doméstica, un enlace móvil con CGNAT) inicia el túnel y lo mantiene abierto con PersistentKeepalive. El patrón clásico: un VPS barato con IPv4 pública que actúa de hub siempre activo, y una o más LAN que se conectan a él. Si ningún sitio tiene IP pública, haz pasar ambos por un hub VPS en lugar de conectarlos directamente.
¿Cómo dejo que la LAN remota alcance la LAN local a través de WireGuard?
Tres cosas deben alinearse. (1) AllowedIPs en cada par debe incluir la subred LAN remota, no solo el /32 del túnel. (2) El reenvío IP debe estar activo: net.ipv4.ip_forward=1. (3) Las máquinas de cada LAN deben saber enviar el tráfico de la subred remota a su router WireGuard local - mediante una ruta estática en cada host, o una ruta estática en la puerta de enlace por defecto de la LAN que apunte la subred remota al equipo WireGuard. Saltarse el paso 3 es la causa nº 1 de un túnel sitio a sitio que «funciona» entre routers pero donde ningún host se hace ping.
¿Las subredes solapadas rompen un VPN sitio a sitio?
Sí, y mal. Si ambas LAN usan 192.168.1.0/24, un host no puede saber si 192.168.1.50 es local o remoto, así que nunca envía el paquete por el túnel. Hay que renumerar un lado (p. ej. mover una LAN a 192.168.20.0/24) o usar NAT 1:1 para mapear la subred remota a un rango sin solape. Planifica tu direccionamiento antes de construir - renumerar una red en producción después es doloroso.
¿Es WireGuard sitio a sitio más rápido que OpenVPN sitio a sitio?
WireGuard suele tener menos carga de CPU y menos latencia que OpenVPN porque corre en espacio de núcleo y usa criptografía moderna y fija, lo que importa en VPS pequeños y en enlaces que saturas. El rendimiento exacto depende de tu CPU, la MTU y la calidad del camino entre los dos sitios - mide siempre tu propia configuración. Para una comparación función por función, consulta nuestro análisis OpenVPN vs WireGuard.
Artículos relacionados

Para profundizar