WireGuard sitio a sitio: conectar dos oficinas por Internet paso a paso

octubre 26, 2025 • febrero 3, 2026 • Lectura: 28 min • Views: 6

¿Te fue útil?

Las VPNs sitio a sitio fallan de una manera muy específica: todo parece “arriba”, nadie puede alcanzar el servidor de archivos y tu teléfono empieza a vibrar como si intentara encapsularlo todo.
WireGuard suele ser el antídoto: configuración limpia, criptografía rápida, pocas piezas móviles; pero sitio a sitio aún tiene suficientes aristas en enrutamiento y firewall como para mantener a un SRE ocupado.

Esta guía explica cómo construyo realmente un enlace WireGuard oficina a oficina en producción: dos gateways, dos LAN, enrutamiento real, decisiones de NAT que puedas defender y un libro de jugadas de diagnóstico para cuando la realidad discrepe con tu diagrama.

Topología, supuestos y lo que vamos a construir

Conectaremos dos oficinas a través de Internet público usando dos gateways Linux que ejecutan WireGuard.
Cada oficina tiene su propia LAN privada. Los gateways enrutarán entre las LAN a través de un túnel WireGuard.
Los clientes dentro de cada oficina deben alcanzar las subredes de la otra oficina sin instalar WireGuard ellos mismos.

Direcciones de ejemplo (ajusta a tu realidad)

LAN Oficina A: 10.10.0.0/24
LAN Oficina B: 10.20.0.0/24
Red del túnel WireGuard: 10.99.0.0/24
IP pública Gateway A: 198.51.100.10 (ejemplo)
IP pública Gateway B: 203.0.113.20 (ejemplo)
IP wg Gateway A: 10.99.0.1
IP wg Gateway B: 10.99.0.2
Puerto de escucha: 51820/udp

Cómo luce “hecho”

Desde un host en Oficina A (p. ej., 10.10.0.50) puedes alcanzar 10.20.0.60 en Oficina B (ping + TCP).
Desde un host en Oficina B puedes alcanzar los servicios de la LAN de Oficina A.
El túnel permanece activo a través de NAT y periodos de inactividad.
El enrutamiento es explícito; el NAT es una elección consciente, no un accidente “porque funcionó”.
Cuando se rompe, puedes identificar si es criptografía, transporte, enrutamiento o política en minutos.

Datos interesantes y breve historia

WireGuard es joven comparado con otras VPN. Se introdujo a mediados de la década de 2010 como una alternativa más simple y moderna a IPsec y OpenVPN.
Entró en el kernel de Linux en 2020. Eso importa: menos módulos fuera del árbol, menos sorpresas en actualizaciones y mejor rendimiento.
Usa el marco del protocolo Noise. El intercambio de claves de WireGuard se basa en patrones Noise: pequeños, revisables y diseñados para criptografía moderna.
No hay negociación de suites de cifrado. No es una carencia; es una elección deliberada para reducir ataques por degradación y proliferación de configuraciones.
Es intencionadamente “aburrido en la capa IP”. WireGuard transporta paquetes IP; no pretende ser un sistema completo de gestión de redes.
“AllowedIPs” es tanto enrutamiento como control de acceso. Es una primitiva de política que funciona también como selector de tabla de enrutamiento.
Roaming es un concepto de primera clase. Si la IP de origen de un par cambia (móvil, cambio de NAT), WireGuard puede seguirlo después de un handshake válido.
UDP lo mantiene simple. Evita desastres de TCP sobre TCP y la mayoría de los problemas de bloqueo por cabeceras que obtienes al tunelizar sobre TCP.
Código base pequeño. WireGuard es famoso por ser compacto comparado con muchas pilas VPN, lo que ayuda en auditorías y reduce la superficie de bugs.

Decisiones de diseño que importan (y las que no)

Decidir: enrutamiento vs NAT entre oficinas

Para sitio a sitio, el enrutamiento es la opción por defecto a la que deberías aspirar: la Oficina A ve a la Oficina B como 10.20.0.0/24, y viceversa.
El NAT “funciona”, pero oculta identidad, complica el registro y crea comportamientos extraños en aplicaciones (Kerberos, ACL basadas en IP, cualquier cosa que dependa de la IP de origen).

Usa NAT sólo cuando tengas solapamientos inevitables (ambas oficinas usaron 192.168.1.0/24 porque el router vino en caja y nadie tuvo ganas de cambiarlo),
o cuando el lado remoto se niega a agregar rutas. Si puedes enrutar, enrútalo.

Decidir: dónde vive el enrutamiento

Necesitas que los hosts de la LAN envíen tráfico hacia la LAN remota al gateway WireGuard. Hay dos patrones sensatos:

Enrutamiento adecuado: Añade una ruta estática en el router/core de la oficina para que 10.20.0.0/24 vaya a la IP LAN del Gateway A, y 10.10.0.0/24 vaya a la IP LAN del Gateway B.
Rutas en hosts: Añade rutas en hosts individuales. Esto está bien para laboratorios pequeños y es terrible para oficinas con humanos.

Decidir: límites de la política de firewall

Un túnel sitio a sitio no es un paraguas de confianza mágico. Trátalo como enchufar un cable Ethernet largo al switch de otra organización.
Permite lo que necesites; deniega lo que no; registra lo que lamentarás no haber registrado.

MTU y MSS: elige ser feliz

La mayoría de los misteriosos fallos “hace ping pero SMB muere” son problemas de MTU/MSS disfrazados.
Empieza con un MTU conservador en la interfaz WireGuard como 1420, y recorta el MSS de TCP en el firewall del gateway si atraviesas PPPoE, LTE o middleboxes desconocidos.

Una cita para mantenerte honesto: “La esperanza no es una estrategia.” — idea parafraseada común en círculos de operaciones (la frase exacta varía).

Prerequisitos y comprobaciones básicas

Dos gateways Linux (ejemplos Debian/Ubuntu). Pueden ser VMs, equipos dedicados o pequeños appliances.
Cada gateway tiene:
- Una interfaz en la LAN de la oficina (p. ej., eth1)
- Una interfaz a Internet (p. ej., eth0)
Controlas el enrutamiento en cada red de oficina, o al menos el gateway/router por defecto.
El puerto UDP 51820 puede ser reenviado a cada gateway si está detrás de NAT.
Subredes LAN sin solapamientos. Si hay solapamiento, estás haciendo NAT/traducción (cubierto más adelante como una salida).

Broma #1: Si encuentras ambas oficinas usando 192.168.0.0/24, felicidades: has descubierto la tradición corporativa más popular del mundo.

Listas de verificación / plan paso a paso

Fase 0: aclara la historia de enrutamiento

Elige una subred dedicada para el túnel WireGuard (ejemplo 10.99.0.0/24).
Confirma que la LAN Oficina A y la LAN Oficina B no se solapan.
Elige qué dispositivo en cada oficina será el “gateway” y asegúrate de que tenga energía fiable e Internet estable.
Decide el método de enrutamiento:
- Preferido: añade rutas estáticas en los routers de oficina.
- Alternativa: añade rutas en los hosts (solo para despliegues pequeños).

Fase 1: instala WireGuard y genera claves

Instala las herramientas de WireGuard en ambos gateways.
Genera pares de claves; almacena las claves privadas con permisos estrictos.
Crea archivos de configuración wg0 con direcciones explícitas y AllowedIPs.

Fase 2: habilita el reenvío y el firewall

Habilita el reenvío IPv4 en ambos gateways.
Permite UDP 51820 entrante hacia cada gateway (interfaz pública).
Permite el reenvío entre wg0 y la interfaz LAN para las subredes/servicios específicos que necesites.
Opcionalmente recorta MSS.

Fase 3: levántalo y valida por capas

Levanta WireGuard, verifica tiempos de handshake y verifica endpoints.
Haz ping a las IPs del túnel WireGuard (10.99.0.1 ↔ 10.99.0.2).
Haz ping LAN a LAN usando un host de prueba en cada lado.
Valida servicios TCP (SSH/HTTP/SMB) en ambas direcciones.
Reafirma las reglas del firewall y el registro una vez que funcione.

Tareas prácticas: comandos, salidas y decisiones

La diferencia entre una VPN de laboratorio y una VPN de producción es la observabilidad y la toma de decisiones disciplinada.
A continuación hay tareas concretas que ejecuto en orden. Cada una incluye qué significa la salida y qué decido a continuación.

Tarea 1: confirma nombres de interfaces y direcciones

cr0x@gw-a:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             198.51.100.10/24
eth1             UP             10.10.0.1/24

Significado: eth0 es pública, eth1 es la LAN de la Oficina A. Bien.
Si tu interfaz “LAN” muestra la IP pública, para. Tu cableado (o el mapeo de NIC en la VM) está mal.

Decisión: Apunta la interfaz LAN para reglas de reenvío del firewall y la IP gateway LAN para rutas estáticas.

Tarea 2: instala herramientas de WireGuard

cr0x@gw-a:~$ sudo apt-get update
...output...
cr0x@gw-a:~$ sudo apt-get install -y wireguard
...output...

Significado: Tienes wg, wg-quick y soporte en kernel (o DKMS) instalado.

Decisión: Si esto instala un módulo DKMS en un kernel antiguo, planea una actualización de kernel. Las VPNs de producción no deberían depender de builds frágiles fuera del árbol.

Tarea 3: genera el par de claves (haz esto en cada gateway)

cr0x@gw-a:~$ umask 077
cr0x@gw-a:~$ wg genkey | tee /etc/wireguard/privatekey | wg pubkey > /etc/wireguard/publickey
cr0x@gw-a:~$ sudo ls -l /etc/wireguard
total 8
-rw------- 1 root root 45 privatekey
-rw-r--r-- 1 root root 45 publickey

Significado: La clave privada es solo para root. La clave pública se comparte con el par.

Decisión: Si los permisos no son estrictos, arréglalos. La clave privada es la identidad.

Tarea 4: crea la configuración WireGuard en Gateway A

cr0x@gw-a:~$ sudo tee /etc/wireguard/wg0.conf >/dev/null <<'EOF'
[Interface]
Address = 10.99.0.1/24
ListenPort = 51820
PrivateKey = __GW_A_PRIVATE_KEY__
MTU = 1420

# Optional: ensure routes are added by wg-quick
# (wg-quick will add routes for AllowedIPs on peers)

[Peer]
PublicKey = __GW_B_PUBLIC_KEY__
Endpoint = 203.0.113.20:51820
AllowedIPs = 10.99.0.2/32, 10.20.0.0/24
PersistentKeepalive = 25
EOF

Significado: Gateway A enrutará el tráfico destinado a la LAN Oficina B (10.20.0.0/24) hacia el túnel, y conoce la IP del túnel del par.

Decisión: Mantén AllowedIPs ajustado. No pongas 0.0.0.0/0 aquí para sitio a sitio salvo que realmente quieras enrutar todo por la otra oficina.

Tarea 5: crea la configuración WireGuard en Gateway B (reflejar)

cr0x@gw-b:~$ sudo tee /etc/wireguard/wg0.conf >/dev/null <<'EOF'
[Interface]
Address = 10.99.0.2/24
ListenPort = 51820
PrivateKey = __GW_B_PRIVATE_KEY__
MTU = 1420

[Peer]
PublicKey = __GW_A_PUBLIC_KEY__
Endpoint = 198.51.100.10:51820
AllowedIPs = 10.99.0.1/32, 10.10.0.0/24
PersistentKeepalive = 25
EOF

Significado: Simetría. Cada lado es autoritativo para su subred LAN en AllowedIPs.

Decisión: Si algún gateway está detrás de NAT y tiene IP pública dinámica, necesitarás una estrategia de endpoint estable (IP estática, nombre DNS o un lado como “dial-out only”). No finjas que es estable.

Tarea 6: habilita el reenvío IP (ambos gateways)

cr0x@gw-a:~$ sudo sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1
cr0x@gw-a:~$ echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-wireguard-forward.conf
net.ipv4.ip_forward=1

Significado: El gateway puede enrutar paquetes entre interfaces.

Decisión: Si olvidas esto, el túnel parecerá bien pero el tráfico LAN-a-LAN morirá silenciosamente. Habilítalo permanentemente vía drop-in de sysctl.

Tarea 7: levanta la interfaz y confirma que está activa

cr0x@gw-a:~$ sudo systemctl enable --now wg-quick@wg0
Created symlink /etc/systemd/system/multi-user.target.wants/wg-quick@wg0.service → /lib/systemd/system/wg-quick@.service.
cr0x@gw-a:~$ sudo wg show
interface: wg0
  public key: 7wz...REDACTED...nU=
  private key: (hidden)
  listening port: 51820

peer: X1p...REDACTED...b0=
  endpoint: 203.0.113.20:51820
  allowed ips: 10.99.0.2/32, 10.20.0.0/24
  latest handshake: 18 seconds ago
  transfer: 84.12 KiB received, 90.44 KiB sent
  persistent keepalive: every 25 seconds

Significado: “Latest handshake” es tu primer semáforo verde. Si dice “(none)”, aún no tienes túnel: no pierdas tiempo con rutas LAN.

Decisión: Sin handshake, céntrate en la alcanzabilidad UDP, endpoints, claves y deriva de tiempo (raro, pero real). Con handshake, sube en la pila a enrutamiento y firewall.

Tarea 8: verifica que el kernel creó rutas para AllowedIPs

cr0x@gw-a:~$ ip route show table main | grep -E '10\.20\.0\.0/24|10\.99\.0\.2'
10.20.0.0/24 dev wg0 scope link
10.99.0.2 dev wg0 scope link

Significado: Los paquetes destinados a la LAN Oficina B serán enrutados a wg0. Esto es esencial.

Decisión: Si falta la ruta, tu config no la está aplicando wg-quick, o editaste el archivo equivocado. Arregla eso antes de tocar routers.

Tarea 9: abre el firewall para el transporte WireGuard (UDP 51820)

cr0x@gw-a:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif "lo" accept
    ct state established,related accept
    tcp dport 22 accept
  }
}

Significado: La política de input es drop; UDP 51820 no está permitido. Por eso los handshakes a menudo no ocurren.

Decisión: Añade una regla explícita para permitir UDP 51820 en la interfaz pública.

cr0x@gw-a:~$ sudo nft add rule inet filter input iif "eth0" udp dport 51820 ct state new accept
cr0x@gw-a:~$ sudo nft list chain inet filter input
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif "lo" accept
    ct state established,related accept
    tcp dport 22 accept
    iif "eth0" udp dport 51820 ct state new accept
  }
}

Significado: Permitimos el transporte WireGuard desde Internet. Aún es una exposición mínima.

Decisión: Refleja esto en Gateway B. Si algún lado está detrás de NAT, asegúrate de que el reenvío de puertos caiga en el host interno correcto.

Tarea 10: permite el reenvío entre LAN y wg0 (modo enrutamiento)

cr0x@gw-a:~$ sudo nft add table inet wgsite
cr0x@gw-a:~$ sudo nft add chain inet wgsite forward '{ type filter hook forward priority 0; policy drop; }'
cr0x@gw-a:~$ sudo nft add rule inet wgsite forward ct state established,related accept
cr0x@gw-a:~$ sudo nft add rule inet wgsite forward iif "eth1" oif "wg0" ip saddr 10.10.0.0/24 ip daddr 10.20.0.0/24 accept
cr0x@gw-a:~$ sudo nft add rule inet wgsite forward iif "wg0" oif "eth1" ip saddr 10.20.0.0/24 ip daddr 10.10.0.0/24 accept
cr0x@gw-a:~$ sudo nft list chain inet wgsite forward
table inet wgsite {
  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    iif "eth1" oif "wg0" ip saddr 10.10.0.0/24 ip daddr 10.20.0.0/24 accept
    iif "wg0" oif "eth1" ip saddr 10.20.0.0/24 ip daddr 10.10.0.0/24 accept
  }
}

Significado: Solo el tráfico LAN-a-LAN está permitido a través del gateway. Todo lo demás es descartado por defecto.

Decisión: Si necesitas servicios específicos solo, reduce aún más usando puertos TCP. Empieza amplio durante las pruebas y luego aprieta.

Tarea 11: añade rutas estáticas en los routers de oficina (preferido)

Esto depende del vendor, pero la lógica siempre es la misma: indica al router de la oficina que la LAN remota es alcanzable vía la IP LAN del gateway WireGuard local.
Si no puedes configurarlo en el router, puedes hacerlo en un host de prueba para validar.

cr0x@host-a:~$ ip route
default via 10.10.0.254 dev eth0
10.10.0.0/24 dev eth0 proto kernel scope link src 10.10.0.50

Significado: No hay ruta a 10.20.0.0/24. El host enviará ese tráfico al gateway por defecto, que probablemente no tendrá idea.

Decisión: Añade una ruta temporal en el host para pruebas, luego implémentala correctamente en el router de la oficina.

cr0x@host-a:~$ sudo ip route add 10.20.0.0/24 via 10.10.0.1
cr0x@host-a:~$ ip route get 10.20.0.60
10.20.0.60 via 10.10.0.1 dev eth0 src 10.10.0.50 uid 1000
    cache

Significado: El host ahora enviará el tráfico de LAN remota al Gateway A (10.10.0.1).

Decisión: Si esto hace que todo funcione, has probado que la VPN y el reenvío del gateway están bien; ahora solo necesitas el enrutamiento apropiado en el borde de red.

Tarea 12: prueba la conectividad IP del túnel (gateway a gateway)

cr0x@gw-a:~$ ping -c 3 10.99.0.2
PING 10.99.0.2 (10.99.0.2) 56(84) bytes of data.
64 bytes from 10.99.0.2: icmp_seq=1 ttl=64 time=21.3 ms
64 bytes from 10.99.0.2: icmp_seq=2 ttl=64 time=20.9 ms
64 bytes from 10.99.0.2: icmp_seq=3 ttl=64 time=21.1 ms

--- 10.99.0.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 20.9/21.1/21.3/0.16 ms

Significado: El camino cifrado funciona y el reenvío para la subred del túnel es correcto.

Decisión: Si esto falla pero existe handshake, probablemente bloqueaste ICMP en reglas de reenvío o mal configuraste AllowedIPs para la IP del túnel. Arregla la política primero.

Tarea 13: prueba conectividad LAN-a-LAN desde un host

cr0x@host-a:~$ ping -c 3 10.20.0.60
PING 10.20.0.60 (10.20.0.60) 56(84) bytes of data.
64 bytes from 10.20.0.60: icmp_seq=1 ttl=63 time=24.7 ms
64 bytes from 10.20.0.60: icmp_seq=2 ttl=63 time=24.1 ms
64 bytes from 10.20.0.60: icmp_seq=3 ttl=63 time=23.9 ms

--- 10.20.0.60 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms

Significado: El enrutamiento a través del gateway funciona. TTL 63 indica al menos un salto (gateway) en la ruta. Bien.

Decisión: Si el ping funciona pero TCP falla, probablemente sea firewall, MTU/MSS o enrutamiento asimétrico. No adivines: mide.

Tarea 14: prueba conectividad TCP (porque “hace ping” es una trampa)

cr0x@host-a:~$ nc -vz -w 2 10.20.0.60 445
Connection to 10.20.0.60 445 port [tcp/microsoft-ds] succeeded!

Significado: Al menos el handshake TCP completa hacia SMB. Eso implica enrutamiento + firewall stateful lo permiten.

Decisión: Si se agota el tiempo, revisa reglas de reenvío y cualquier firewall interno en el host destino. Si está “rechazado”, el servicio no escucha o las ACLs lo bloquean—problema distinto.

Tarea 15: confirma que el tráfico realmente fluye dentro de wg0

cr0x@gw-a:~$ sudo wg show wg0 transfer
peer: X1p...REDACTED...b0=
  transfer: 2.31 MiB received, 2.88 MiB sent

Significado: Los contadores en movimiento confirman que tráfico real atravesó el túnel, no solo un handshake.

Decisión: Si los handshakes ocurren pero el transfer se mantiene cercano a cero durante las pruebas, el tráfico no llega al gateway (enrutamiento) o se bloquea antes de cifrarse (firewall en el lado LAN).

Tarea 16: usa tcpdump para localizar dónde mueren los paquetes

cr0x@gw-a:~$ sudo tcpdump -ni eth1 host 10.20.0.60
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:14:31.120331 IP 10.10.0.50 > 10.20.0.60: ICMP echo request, id 1923, seq 1, length 64

Significado: El gateway está recibiendo paquetes de la LAN destinados a la LAN remota. Bien.

Decisión: Ahora comprueba si salen por wg0. Si entran por eth1 pero nunca aparecen en wg0, tu política de reenvío o enrutamiento está mal.

cr0x@gw-a:~$ sudo tcpdump -ni wg0 host 10.20.0.60
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
10:14:31.120882 IP 10.10.0.50 > 10.20.0.60: ICMP echo request, id 1923, seq 1, length 64

Significado: El paquete se está enrutando hacia el túnel. Si el host remoto no responde, el problema está en el extremo lejano (enrutamiento de retorno, firewall, política del host).

Tarea 17: comprueba el camino inverso en Gateway B

cr0x@gw-b:~$ ip route get 10.10.0.50
10.10.0.50 dev wg0 src 10.99.0.2 uid 0
    cache

Significado: Gateway B sabe enviar tráfico de vuelta a la Oficina A por el túnel. Si dice “via eth1”, has creado enrutamiento asimétrico y tu firewall te castigará.

Decisión: Corrige AllowedIPs y rutas hasta que ambos lados acuerden el camino.

Tarea 18: busca problemas de MTU con pings “no fragmentar”

cr0x@host-a:~$ ping -M do -s 1380 -c 3 10.20.0.60
PING 10.20.0.60 (10.20.0.60) 1380(1408) bytes of data.
1388 bytes from 10.20.0.60: icmp_seq=1 ttl=63 time=25.4 ms
1388 bytes from 10.20.0.60: icmp_seq=2 ttl=63 time=24.9 ms
1388 bytes from 10.20.0.60: icmp_seq=3 ttl=63 time=25.2 ms

Significado: Paquetes grandes sobreviven sin fragmentación. Buena señal.

Decisión: Si ves “Frag needed”, baja el MTU de wg (p. ej., 1380–1420) o recorta MSS en los gateways. Haz esto antes de culpar al “ISP”.

Tarea 19: recorta TCP MSS si ves bloqueos en transferencias grandes

cr0x@gw-a:~$ sudo nft add table ip mangle
cr0x@gw-a:~$ sudo nft add chain ip mangle forward '{ type filter hook forward priority -150; policy accept; }'
cr0x@gw-a:~$ sudo nft add rule ip mangle forward oif "wg0" tcp flags syn tcp option maxseg size set 1360
cr0x@gw-a:~$ sudo nft list chain ip mangle forward
table ip mangle {
  chain forward {
    type filter hook forward priority -150; policy accept;
    oif "wg0" tcp flags syn tcp option maxseg size set 1360
  }
}

Significado: Nuevas conexiones TCP que salen hacia el túnel anunciarán un MSS más pequeño, evitando agujeros negros dependientes de PMTUD.

Decisión: Recorta sólo si lo necesitas. Es una solución pragmática, pero también una admisión de que la detección de MTU de camino no es fiable en tu entorno (a menudo por bloqueo de ICMP).

Tarea 20: asegúrate de que systemd vea wg-quick sano

cr0x@gw-a:~$ systemctl status wg-quick@wg0 --no-pager
● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
     Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; preset: enabled)
     Active: active (exited) since Tue 2025-12-09 10:01:12 UTC; 2h 8min ago
       Docs: man:wg-quick(8)
             man:wg(8)
    Process: 1234 ExecStart=/usr/bin/wg-quick up wg0 (code=exited, status=0/SUCCESS)

Significado: “active (exited)” es normal para servicios oneshot. La interfaz persiste en el kernel.

Decisión: Si falla, lee los logs del journal. No sigas reiniciando; corrige el error de configuración (formato de clave incorrecto, falta de dirección de interfaz, etc.).

Tres microrrelatos corporativos desde el campo

Microrrelato 1: el incidente causado por una suposición equivocada

Una empresa mediana se fusionó con otra más pequeña y necesitaba “un túnel rápido” para que finanzas alcanzara un sistema ERP.
La nueva VPN se montó durante el fin de semana. El lunes, el túnel estaba arriba, los handshakes recientes y el panel mostraba un verde tranquilizador.
Los usuarios aún no podían iniciar sesión en la app ERP. El equipo de red culpó inmediatamente a la aplicación. El equipo de aplicación culpó a la red.

La suposición equivocada: “Si el túnel WireGuard está arriba, el enrutamiento debe estar bien.” No lo estaba.
La Oficina A tenía una ruta estática hacia la Oficina B en el gateway. La Oficina B no.
Su gateway por defecto era un firewall gestionado donde nadie tenía permiso para agregar rutas, así que el tráfico de retorno salió al borde de Internet, encontró una regla de drop y desapareció.

La pista estuvo en tcpdump: los paquetes entraban en wg0 del gateway remoto, luego las respuestas nunca regresaban por el túnel.
La solución fue aburrida: agregar la ruta estática que faltaba en el borde de la Oficina B y apretar la política del firewall para que solo los puertos ERP necesarios cruzaran.
Después, escribieron una regla: nunca declarar “VPN funciona” hasta haber verificado el enrutamiento de retorno con ip route get en ambos gateways.

Lección: el éxito del handshake prueba cifrado; no prueba la entrega de paquetes y definitivamente no prueba enrutamiento simétrico.
Depura el camino como un SRE: un salto a la vez, una interfaz a la vez, con evidencia.

Microrrelato 2: la optimización que salió mal

Otra organización decidió que el túnel debía ser “lo más rápido posible”, así que subieron el MTU, quitaron el clamp de MSS y habilitaron offloads agresivos en las NIC.
Las pruebas de rendimiento se vieron bien en un escenario controlado. Luego contabilidad empezó a mover PDFs grandes por SMB y todo se congeló intermitentemente.
No lento. Congelado. Clásico.

La optimización: paquetes más grandes y menos ciclos de CPU. El contragolpe: un camino WAN real con un MTU efectivo menor y filtrado de ICMP.
La detección de MTU de camino falló silenciosamente. El resultado fue un agujero negro donde segmentos TCP grandes desaparecían.
Tráfico pequeño (pings, solicitudes HTTP pequeñas) funcionaba. Transferencias grandes morían a mitad de camino, y el helpdesk disfrutó del ticket especial: “A veces funciona.”

La solución fue dejar de intentar adelantarse a Internet.
Pusieron el MTU de wg en 1420, añadieron un clamp MSS conservador y mantuvieron los offloads por defecto.
El rendimiento se volvió estable, que es la única métrica de rendimiento que a los usuarios realmente les importa.

Lección: “rápido” que falla es más lento que “aburrido” que funciona. Mide después de tener corrección, no antes.

Microrrelato 3: la práctica aburrida que salvó el día

Una compañía con dos oficinas y un pequeño centro de datos corrió WireGuard por años sin dramas.
El secreto no fue una configuración mágica; fue la rutina.
Cada cambio en AllowedIPs, reglas de firewall o enrutamiento de oficina pasaba por un pequeño runbook: probar ping de IP del túnel, probar ping LAN-a-LAN, probar un puerto TCP y capturar la salida de wg show en el registro de cambio.

Un día, un ISP cambió el módem en la Oficina B y las reglas NAT públicas cambiaron.
El túnel dejó de handshakear. Esto pudo haber sido una sesión de señalar culpables de dos horas.
En su lugar, el ingeniero on-call siguió el playbook y encontró “sin handshake” en menos de un minuto, luego verificó que la alcanzabilidad UDP del puerto estaba muerta desde el exterior.

Como tenían documentada la configuración de reenvío del viejo módem, la replicaron en el nuevo equipo rápidamente.
Sin brujería de paquetes, sin escalado a vendors, sin heroísmos nocturnos.
La VPN volvió y la mayoría de la gente nunca supo que había estado caída—lo cual es el mayor cumplido que operaciones puede recibir.

Lección: haz el papeleo aburrido cuando estés calmado. Tu yo futuro es un narrador poco fiable bajo presión.

Libro de jugadas para diagnóstico rápido

Cuando un enlace WireGuard sitio a sitio falla, quieres responder una pregunta rápido:
¿es el cuello de botella transporte/cripto, enrutamiento o firewall/política?
Aquí está el orden que minimiza el thrash.

Primero: ¿hay handshake?

Ejecuta wg show en ambos gateways.
Si “latest handshake” es reciente en ambos lados, transporte y claves probablemente están bien.
Si no hay handshake:
- Verifica la alcanzabilidad UDP 51820 y NAT/reenvío de puertos.
- Confirma que los endpoints son correctos y que las IP públicas no cambiaron.
- Confirma que las claves coinciden con el par que crees que coinciden.

Segundo: ¿pueden los gateways alcanzar la IP wg del otro?

Haz ping a 10.99.0.2 desde Gateway A y a 10.99.0.1 desde Gateway B.
Si esto falla pero existe handshake, sospecha:
- AllowedIPs que no incluyen el /32 del túnel
- Reglas de forward que descartan ICMP o todo el reenvío
- Conflictos de routing policy

Tercero: ¿llega tráfico LAN al gateway y entra en wg0?

En Gateway A:
- tcpdump -ni eth1 host 10.20.0.60 mientras haces ping desde un host LAN
- tcpdump -ni wg0 host 10.20.0.60 al mismo tiempo
Interpretación:
- Visto en eth1, no en wg0: enrutamiento/política de forward en Gateway A.
- Visto en wg0 en A, no visto en wg0 en B: camino de transporte/endpoint/NAT.
- Visto en wg0 en B, respuestas que no regresan: enrutamiento de retorno o firewall en B o en el host destino.

Cuarto: persigue MTU solo después de lo básico

Si el ping funciona, el handshake TCP funciona, pero transferencias grandes se estancan: prueba pings DF y recorta MSS.
No “ajustes MTU” como primer movimiento. Así es como desperdicias una tarde y no aprendes nada.

Broma #2: los bugs de MTU son como vampiros—invítalos bloqueando ICMP y vivirán en tu red para siempre.

Errores comunes: síntomas → causa raíz → solución

1) Síntoma: “Latest handshake: (none)” en uno o ambos gateways

Causa raíz: Puerto UDP bloqueado, IP/puerto de endpoint equivocado, reenvío NAT faltante o clave pública del par incorrecta.
Solución: Permite UDP 51820 entrante en la interfaz pública, confirma el reenvío de puertos al gateway, verifica que las claves públicas y endpoints coincidan con la realidad y considera PersistentKeepalive=25 si estás detrás de NAT.

2) Síntoma: handshake funciona, pero los gateways no pueden hacer ping a la IP wg del otro

Causa raíz: Falta el /32 del túnel en AllowedIPs, o la política de forward descarta ICMP/reenvío.
Solución: Asegura que cada peer AllowedIPs incluya la otra IP del túnel (p. ej., 10.99.0.2/32) y permite el reenvío entre wg0 y la LAN.

3) Síntoma: hosts de oficina no pueden alcanzar la LAN remota, pero los gateways sí

Causa raíz: El router de la oficina carece de ruta estática hacia la subred remota vía el gateway WireGuard.
Solución: Añade rutas estáticas en los routers de oficina, no en hosts aleatorios, y verifica con ip route get desde un cliente.

4) Síntoma: conectividad unidireccional (A→B funciona, B→A falla)

Causa raíz: Enrutamiento asimétrico o tracking de estado del firewall que descarta paquetes de retorno.
Solución: Verifica rutas en ambos gateways y en ambos routers de oficina. Confirma que las reglas de forward permiten en ambas direcciones. Usa tcpdump en ambos extremos para demostrar dónde se detiene el tráfico de retorno.

5) Síntoma: ping funciona, TCP pequeño funciona, transferencias grandes cuelgan

Causa raíz: Desajuste de MTU y PMTUD roto, a menudo por filtrado de ICMP en el camino.
Solución: Baja el MTU de wg (empieza en 1420) y recorta MSS en SYNs que salgan hacia wg0. Confirma con pings DF.

6) Síntoma: caídas aleatorias cada pocos minutos, especialmente detrás de NAT

Causa raíz: Timeouts de inactividad de NAT que expiran mapping UDP.
Solución: Establece PersistentKeepalive=25 en el lado detrás de NAT (o en ambos si no estás seguro). Verifica que las marcas de handshake permanezcan frescas.

7) Síntoma: la LAN remota se vuelve alcanzable, pero DNS o AD se comportan extraño

Causa raíz: Hiciste NAT entre sitios y rompiste suposiciones de identidad, o olvidaste enrutar consultas DNS a los resolvers correctos.
Solución: Prefiere modo enrutado. Si debes NATear, documenta la traducción y ajusta expectativas de aplicación (ACLs, registros). Asegura el reenvío DNS y zonas condicionales alineadas con la nueva conectividad.

8) Síntoma: wireguard funciona hasta que reinicias, luego no

Causa raíz: Config no habilitada como servicio, reglas de firewall no persistidas o sysctl de reenvío no persistido.
Solución: Habilita wg-quick@wg0 y persiste nftables/sysctl adecuadamente. Reinicia en ventana de mantenimiento y verifica.

Endurecimiento, operaciones y medidas de fiabilidad

Mantén AllowedIPs mínimo e intencional

AllowedIPs no es solo “lo que puede pasar”. También influye en decisiones de enrutamiento.
Si accidentalmente reclamas una subred en el par equivocado, Linux enrutará felizmente el tráfico al túnel y pasarás horas “depurando la oficina equivocada”.
Limítalo a:

IP del túnel del par (/32)
Subred(es) LAN del par (p. ej., 10.20.0.0/24)

Prefiere modo enrutado; usa NAT solo como compromiso controlado

Si debes usar NAT por subredes solapadas, hazlo explícito y documenta el esquema de traducción.
Patrón típico: Oficina B aparece a Oficina A como 10.120.0.0/24 aunque en realidad sea 192.168.1.0/24.
Eso requiere reglas NAT y mapeo cuidadoso de DNS/servicios. Se puede hacer. También es deuda técnica.

Registro: captura la evidencia correcta

WireGuard por sí mismo no inunda logs, lo cual es bueno para tus discos y malo para tus suposiciones.
Registra en el límite del firewall donde se toman decisiones de política. Cuando llegue un ticket, quieres saber:
¿el paquete entró al gateway, entró al túnel, salió del túnel?

Monitorización: mide lo que importa

Edad del handshake (wg show)
Contadores de transferencia moviéndose (sent/received)
Pérdida de paquetes/latencia entre IPs wg
Comprobaciones de nivel de servicio a través del túnel (chequeos de puertos TCP para tus aplicaciones reales)

Gestión de cambios: trata los cambios VPN como cambios en producción

El túnel ahora es parte de tu red de producción. Cambios en él pueden tumbar nómina, inventario o autenticación.
Usa despliegues por fases: prueba desde los gateways primero, luego desde un cliente único, luego despliega rutas estáticas a toda la oficina.

Alta disponibilidad (opcional, pero hay que pensarlo)

WireGuard en sí no hace clustering. Aun así puedes construir redundancia:

Dos gateways por oficina con VRRP/keepalived para el next-hop LAN
Múltiples peers y enrutamiento selectivo (más complejo)
Reemplazo rápido: configs inmutables y redeploy rápido

Si eres pequeño, no sobreingenierices. Un único gateway bien gestionado con repuestos y un procedimiento de restauración probado vence a un diseño HA a medias.

Preguntas frecuentes

1) ¿Necesito una subred dedicada para el túnel como 10.99.0.0/24?

Sí. Dale a las interfaces WireGuard sus propias direcciones. Simplifica enrutamiento, monitorización y políticas de firewall.
Un /30 o /31 también funciona, pero /24 está bien y es legible.

2) ¿Qué hace exactamente AllowedIPs?

Dos cosas: define qué IPs de destino se enrutaran hacia un par, y define qué IPs de origen se aceptan de ese par.
Trátalo como una lista combinada de prefijos de enrutamiento y lista de control de acceso.

3) ¿Debería establecer PersistentKeepalive en ambos lados?

Establécelo en el lado detrás de NAT (o donde sospeches que los mappings UDP expiran). Si no lo sabes, ponerlo en ambos lados es aceptable.
Es un paquete periódico pequeño; el coste es trivial comparado con el tiempo de inactividad.

4) ¿Puedo ejecutar WireGuard en el router de oficina directamente?

Si el router lo soporta bien y puedes operarlo con seguridad, sí. Muchos equipos prefieren un gateway Linux porque es depurable y automatizable.
Escoge la plataforma que puedas operar a las 3 a.m., no la que se vea bonita en un diagrama.

5) ¿Por qué “handshake exitoso” no garantiza que el tráfico funcione?

Porque el handshake solo prueba que los pares pueden intercambiar mensajes autenticados.
Tu tráfico LAN aún puede fallar por rutas faltantes, reenvío IP deshabilitado, políticas de forward del firewall o agujeros negros MTU.

6) ¿Necesito NAT para una VPN WireGuard sitio a sitio?

No, si controlas el enrutamiento en ambos lados y las subredes LAN no se solapan.
NAT es un parche para restricciones (solapamiento, sin control de rutas), no es el valor por defecto.

7) ¿Cómo manejo subredes solapadas entre oficinas?

Mejor solución: renumerar uno de los sitios. Sí, es doloroso; también es la solución limpia.
Si no puedes renumerar, usa NAT con un prefijo traducido dedicado, actualiza expectativas de DNS y prepárate para comportamientos extraños de apps.

8) ¿Qué MTU debería usar?

Empieza con 1420. Si tienes PPPoE, LTE o ves síntomas de agujero negro, reduce más y/o recorta MSS.
Valida con pings DF y transferencias de aplicación reales.

9) ¿WireGuard puede ejecutar enrutamiento dinámico (OSPF/BGP) sobre el túnel?

WireGuard no provee protocolos de enrutamiento por sí mismo, pero puedes ejecutar OSPF/BGP a través de él como cualquier otro enlace IP.
Para dos oficinas y un par de subredes, las rutas estáticas suelen ser más simples y predecibles.

10) ¿Cuál es la forma más segura de rotar claves?

Añade una nueva clave de peer en paralelo (cuando sea posible), valida handshake y tráfico, luego elimina la clave vieja.
Evita “intercambiar claves en ambos lados a la vez” a menos que disfrutes de cortes coordinados.

Conclusión: pasos prácticos siguientes

Si quieres que esto funcione a la primera, constrúyelo por capas: transporte, IPs de túnel, enrutamiento, firewall y luego pruebas de aplicación.
No saltes directo a “debe ser DNS” antes de haber probado que los paquetes atraviesan wg0 en ambas direcciones.

Despliega las configs y confirma handshakes en ambos gateways.
Confirma que existen rutas para las subredes LAN remotas en ambos gateways.
Añade rutas estáticas en los routers de oficina para que los clientes realmente usen el túnel.
Cierra las reglas de reenvío a solo lo necesario y añade registro mínimo.
Ejecuta el libro de jugadas de diagnóstico rápido una vez mientras todo está sano y registra las salidas esperadas.