13. WireGuard

13.1 Diseño y objetivos

WireGuard utiliza un enfoque orientado a claves públicas estáticas: cada nodo posee una clave privada y comparte su clave pública con los pares autorizados. No hay negociación compleja como en IKE; la seguridad se basa en un conjunto reducido y bien estudiado de algoritmos:

• ChaCha20 para cifrado simétrico.
• Poly1305 para autenticación de mensajes.
• Curve25519 para intercambio de claves.
• BLAKE2s para hashing.
• SipHash y HKDF para derivaciones adicionales.

Este set fijo evita la complejidad de seleccionar algoritmos compatibles y facilita auditorías de seguridad.

13.2 Arquitectura y funcionamiento

WireGuard opera en la capa 3, encapsulando paquetes IP dentro de UDP (puerto por defecto 51820). Su funcionamiento básico es:

1. Dos nodos intercambian sus claves públicas y definen qué redes (AllowedIPs) se enrutan por el túnel.
2. Cuando un nodo envía tráfico hacia un prefijo permitido, WireGuard cifra el paquete, agrega un encabezado mínimo y lo envía mediante UDP al peer.
3. El receptor valida la etiqueta de tiempo/nonce para evitar repetidos, descifra el paquete y lo entrega a la interfaz virtual.
4. Si no hay tráfico, WireGuard permanece silencioso hasta que sea necesario reanudar la comunicación (keepalive opcional).

No existe un plano de control independiente: toda la configuración se realiza editando archivos o mediante comandos sencillos.

13.3 Ventajas frente a protocolos tradicionales

Además, su código base reducido (< 4000 líneas en el kernel) facilita revisiones, algo difícil de lograr con implementaciones históricas de IPsec o SSL VPN.

13.4 Casos de uso

• Acceso remoto moderno: organizaciones que migran desde IPsec para simplificar la experiencia del usuario.
• DevOps y nubes: WireGuard se integra en Kubernetes, Terraform o scripts de Ansible para crear overlays seguros.
• VPN personales: proveedores comerciales y usuarios particulares lo emplean para proteger la navegación.
• IoT y edge: su eficiencia en CPU lo hace ideal para routers pequeños o sensores industriales.

13.5 Ejemplo de configuración

El siguiente bloque muestra dos archivos básicos (/etc/wireguard/wg0.conf) para un túnel entre la sede central y un servidor en la nube.

# Nodo A (sede central)
[Interface]
PrivateKey = YKJ1+vF0YyE0t...
Address = 10.20.0.1/24
ListenPort = 51820

[Peer]
PublicKey = j1L6mLyqC9n2...
AllowedIPs = 10.20.0.2/32
Endpoint = nube.example.com:51820
PersistentKeepalive = 25

# Nodo B (nube)
[Interface]
PrivateKey = j1L6mLyqC9n2...
Address = 10.20.0.2/24

[Peer]
PublicKey = YKJ1+vF0YyE0t...
AllowedIPs = 10.20.0.1/32, 192.168.50.0/24
Endpoint = sede.example.com:51820

Para activar la interfaz en Linux se ejecuta sudo wg-quick up wg0. En Windows se usa la aplicación oficial que importa archivos .conf con la misma sintaxis.

13.6 Automatización y monitoreo

WireGuard aporta herramientas nativas como wg para consultar el estado de los peers, bytes transferidos y última conexión. En PowerShell también se puede obtener el listado de túneles instalados:

Get-WireGuardTunnel |
  Select-Object Name, Status, ListenPort, LastHandshake |
  Format-Table -AutoSize

El comando forma parte del paquete oficial de WireGuard para Windows e informa si un túnel está activo y cuándo fue el último handshake, útil para auditorías.

13.7 Buenas prácticas

• Rotar periódicamente las claves privadas y distribuirlas mediante canales seguros.
• Limitar AllowedIPs para evitar que un peer enrute tráfico no autorizado.
• Usar DNS internos y split tunneling cuando solo ciertos servicios deban atravesar el VPN.
• Registrar métricas (handshake, bytes) en sistemas de observabilidad para detectar caídas o abuso.
• Habilitar PersistentKeepalive en clientes detrás de NAT para mantener el túnel operativo.