WireGuard: el protocolo VPN que cabe en menos de 4.000 líneas

Un túnel WireGuard se levanta en menos de diez líneas de configuración y establece conexión en un solo intercambio de paquetes: nada que ver con las decenas de mensajes que negocia IPsec antes de cifrar el primer byte. Eso es lo que lo convirtió, en pocos años, en el protocolo VPN que Linus Torvalds llamó una obra de arte cuando lo revisó para el kernel.

Hoy WireGuard corre integrado en el kernel de Linux, en routers domésticos, en servidores de nube y en la mayoría de apps de VPN comercial que se venden como más rápidas. Esta guía explica cómo funciona por dentro, cómo configurarlo desde cero y cuándo conviene, o no, frente a las alternativas clásicas.

TL;DR

• Vas a entender qué hace distinto a WireGuard frente a OpenVPN e IPsec a nivel de diseño.- Vas a poder generar un par de claves Curve25519 y levantar un túnel punto a punto en minutos.- Vas a saber leer un archivo wg0.conf y explicar qué hace cada campo.- Vas a poder verificar con wg show si un peer completó el handshake.- Vas a entender por qué WireGuard no negocia cifrados: usa un único conjunto fijo de algoritmos.- Vas a poder decidir, con criterio técnico, cuándo usar WireGuard y cuándo IPsec o OpenVPN.

Qué es WireGuard y por qué importa

WireGuard es un protocolo de VPN que crea túneles cifrados punto a punto sobre UDP. A diferencia de OpenVPN o IPsec, que soportan decenas de combinaciones de cifrado configurables, WireGuard fija de antemano un único conjunto de algoritmos modernos: Curve25519 para el intercambio de claves, ChaCha20-Poly1305 para cifrar y autenticar, y BLAKE2s para hashing. Esa rigidez es intencional: menos opciones significa menos superficie para configurar mal un cifrado débil.

El propio sitio oficial de WireGuard señala que su implementación completa ocupa menos de 4.000 líneas de código, frente a las más de 100.000 líneas que suman OpenVPN e IPsec combinados. Ese tamaño reducido es lo que permitió auditarlo a fondo y, en marzo de 2020, incorporarlo al kernel mainline de Linux a partir de la versión 5.6.

El diseño resultó tan influyente que WireGuard dejó de ser solo una VPN más: hoy sirve de capa de transporte para productos que resuelven un problema distinto, el de coordinar redes de decenas o cientos de dispositivos sin que un humano edite AllowedIPs a mano.

El diseño: cryptokey routing

En vez de negociar rutas como IPsec, WireGuard asocia cada clave pública a un rango de direcciones IP permitidas (AllowedIPs). Esa tabla es, a la vez, la lista de control de acceso y la tabla de ruteo: si un paquete cifrado llega firmado con una clave que no está en la tabla, WireGuard lo descarta sin procesarlo.
Cada peer de WireGuard se identifica por una clave pública, no por una IP fija.

Cómo funciona por dentro

WireGuard construye su handshake sobre el Noise Protocol Framework, un conjunto de patrones criptográficos que también usan Signal y WhatsApp para intercambiar claves. El patrón específico que usa WireGuard se llama Noise_IKpsk2: permite que ambos peers se autentiquen entre sí y deriven una clave de sesión efímera en un solo intercambio de dos mensajes.

flowchart TD
    A["Laptop (Peer A)"] -->|"paquete cifrado UDP:51820"| B["Interfaz wg0"]
    B --> C["Motor criptografico Noise"]
    C --> D["Internet"]
    D --> E["Servidor (Peer B)"]
    E --> F["Interfaz wg0"]
    subgraph "Maquina local"
    A
    B
    C
    end

Cada mensaje del handshake incluye una nueva clave efímera, así que aunque un atacante comprometa una clave de sesión pasada, no puede descifrar tráfico futuro ni pasado: es la propiedad de forward secrecy. WireGuard renueva el handshake cada 120 segundos por defecto, así que la ventana de exposición de cada clave es corta.

sequenceDiagram
    participant A as Peer A
    participant B as Peer B
    A->>B: Initiation (clave efimera + estatica cifrada)
    B-->>A: Response (confirmacion + derivacion de claves)
    Note over A,B: ambos derivan las mismas claves de sesion
    A->>B: Paquete de datos cifrado con ChaCha20-Poly1305

💭 Clave: WireGuard no tiene modo de configuración de cifrado: los algoritmos están fijos en el protocolo. Si en el futuro aparece una debilidad criptográfica, el proyecto versiona el protocolo entero en vez de dejar un flag inseguro activable.

Ejemplos prácticos

Vamos de lo mínimo a un túnel funcional entre dos máquinas reales.

Paso 1: instalar y generar claves

# Debian/Ubuntu
sudo apt update && sudo apt install wireguard

# Generar el par de claves del servidor
wg genkey | tee /etc/wireguard/server_private.key | wg pubkey > /etc/wireguard/server_public.key
sudo chmod 600 /etc/wireguard/server_private.key

El comando wg genkey genera una clave privada Curve25519 de 32 bytes codificada en base64; wg pubkey deriva la clave pública correspondiente. Cada peer necesita su propio par.

Paso 2: configurar el túnel

# /etc/wireguard/wg0.conf en el servidor
[Interface]
PrivateKey = 
Address = 10.0.0.1/24
ListenPort = 51820

[Peer]
PublicKey = 
AllowedIPs = 10.0.0.2/32

# Levantar la interfaz
sudo wg-quick up wg0
sudo systemctl enable wg-quick@wg0

wg-quick up crea la interfaz de red wg0, asigna la IP y aplica las reglas de ruteo. El cliente necesita un bloque equivalente con las claves invertidas y un campo Endpoint apuntando a la IP pública del servidor.

Verificar que el túnel está activo

sudo wg show wg0

Si el handshake se completó, la salida muestra una línea latest handshake con un tiempo reciente. Si nunca aparece esa línea, el peer no está recibiendo paquetes: revisá el firewall y el campo Endpoint.

Cómo empezar paso a paso

• Instalar wireguard-tools en ambas máquinas (cliente y servidor).- Generar un par de claves por cada peer con wg genkey y wg pubkey.- Escribir wg0.conf en cada lado, cruzando las claves públicas.- Abrir el puerto UDP configurado (por defecto 51820) en el firewall del servidor.- Levantar la interfaz con wg-quick up wg0 y confirmar con wg show.

Casos de uso reales

WireGuard se usa hoy en escenarios muy distintos. El primero es la VPN personal: acceder a la red doméstica o cifrar el tráfico en wifi pública, un caso donde su arranque casi instantáneo, sin la negociación TLS de OpenVPN, se nota en la batería del teléfono.

El segundo es la malla de servidores: empresas que conectan máquinas en distintas nubes con un túnel WireGuard por par de nodos, en vez de depender del peering privado del proveedor. El tercero es la implementación en espacio de usuario: BoringTun, la versión en Rust de Cloudflare, corre WireGuard sin necesitar el módulo de kernel, útil en contenedores o sistemas donde no se puede tocar el kernel.

Un cuarto patrón, cada vez más común, es usar WireGuard para conectar funciones serverless o workers de borde con una base de datos que vive detrás de un firewall corporativo, evitando exponer el puerto de esa base de datos a toda la internet pública.
BoringTun permite correr WireGuard sin acceso al kernel, útil en contenedores.

WireGuard como base de otras herramientas

WireGuard resuelve el cifrado punto a punto, pero no resuelve por sí solo cómo descubrir peers, distribuir claves o atravesar NAT entre dos redes domésticas. Ahí es donde entran herramientas construidas encima del protocolo.

Tailscale y su versión autoalojada Headscale usan WireGuard como motor de cifrado, pero agregan un servidor de coordinación que distribuye las claves públicas automáticamente entre los dispositivos de una cuenta y usa relays cuando el NAT impide una conexión directa. El usuario nunca edita un wg0.conf a mano.

Netmaker y Nebula siguen una idea parecida: una red mesh completa, con un plano de control propio, que usa WireGuard únicamente como capa de cifrado de paquetes. La lección de diseño se repite en los tres proyectos: separar quién puede hablar con quién, el plano de control, de cómo se cifra el paquete, WireGuard, permite escalar de dos a miles de peers sin tocar el protocolo original.

Errores comunes y buenas prácticas

El error más frecuente es no configurar PersistentKeepalive cuando un peer está detrás de NAT: sin ese campo, el NAT cierra el mapeo de puertos tras un rato de inactividad y el túnel deja de recibir paquetes entrantes hasta que el cliente vuelve a iniciar tráfico.

• NAT sin keepalive: agregá PersistentKeepalive = 25 en el bloque [Peer] del lado que está detrás de NAT.- AllowedIPs mal calculado: si dos peers declaran el mismo rango, WireGuard enruta el tráfico al último que hizo handshake, generando conflictos silenciosos.- Reusar la clave privada: cada dispositivo debe tener su propio par de claves; compartir una clave privada entre dos peers rompe la autenticación cruzada.- Reloj desincronizado: el handshake usa timestamps para evitar repetición de paquetes; un reloj muy desfasado puede rechazar handshakes legítimos.- MTU mal ajustado: WireGuard agrega overhead de cabecera a cada paquete; en redes con un MTU ya ajustado, como ciertas VPN corporativas o túneles anidados, no bajar el MTU de la interfaz wg0 causa fragmentación silenciosa y conexiones que se sienten lentas o se cuelgan con paquetes grandes.

⚠️ Ojo: la clave privada nunca debe salir del dispositivo que la generó. A diferencia de un certificado TLS, no hay forma de revocar una clave WireGuard comprometida sin cambiar la configuración de todos los peers que confían en ella.

Comparativa con alternativas

ProtocoloCuándo usarloVentajaLimitaciónWireGuardTúneles punto a punto rápidos de configurar, VPN personales, malla entre servidoresCódigo mínimo, handshake de un intercambio, corre en el kernel de LinuxSin ofuscación nativa: un firewall puede identificar su patrón de tráfico UDPOpenVPNEntornos que necesitan atravesar proxies restrictivos o forzar el tráfico por el puerto 443Muy configurable, corre sobre TCP o UDP, ecosistema TLS maduroBase de código mucho mayor: más superficie de ataque y de bugsIPsec/IKEv2Integraciones corporativas con hardware de red y VPN de sistema operativo ya existentesSoporte nativo en routers, móviles y sistemas operativos sin instalar nadaConfiguración compleja, negociación de fases más lenta que un handshake Noise

Profundizando

El patrón Noise_IKpsk2 que usa WireGuard incluye, opcionalmente, una clave precompartida (PresharedKey) además del par de claves Curve25519. Esa capa extra no reemplaza la criptografía de curva elíptica: se combina con ella para dar resistencia adicional ante un eventual quiebre futuro de Curve25519, incluido un ataque con computación cuántica suficientemente madura.

flowchart LR
    K["Clave publica del peer"] --> R["Tabla de ruteo criptografico"]
    R --> IP["Rango de IPs permitidas (AllowedIPs)"]
    IP --> D["Decision: aceptar o descartar paquete"]

El artículo original que documenta el diseño completo es el whitepaper técnico de Jason Donenfeld, publicado junto al código fuente. Ahí se detalla también el mecanismo de cookie reply: si el servidor recibe demasiadas solicitudes de handshake, responde con una cookie que el cliente debe reenviar, una defensa barata contra ataques de denegación de servicio que evita hacer cómputo criptográfico costoso por cada paquete falso.

Otro detalle poco conocido es el roaming: como WireGuard identifica peers por clave pública y no por IP de origen, un cliente puede cambiar de red, de wifi a datos móviles por ejemplo, sin cerrar el túnel. El servidor simplemente actualiza el Endpoint asociado a esa clave pública en cuanto recibe un paquete válido desde la nueva IP.

Los timers del protocolo también son ajustables pero no arbitrarios: el handshake se reintenta si no hay respuesta en unos segundos, y si un peer no envía ni recibe tráfico en un rato, la clave de sesión expira y el próximo paquete dispara un handshake nuevo. Esto significa que un túnel WireGuard inactivo no consume CPU en criptografía hasta que hay tráfico real que cifrar, a diferencia de protocolos que mantienen sesiones vivas con pings de keepalive constantes por diseño.

💡 Tip: para medir el rendimiento real de un túnel en tu propia red, corré iperf3 entre los dos peers con el túnel arriba y compará contra el mismo test sin VPN: es la única forma confiable de saber cuánto overhead agrega en tu hardware específico.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: levantá dos máquinas virtuales locales (o dos contenedores LXC), instalá wireguard-tools en ambas y conectalas siguiendo los pasos de esta guía antes de tocar un servidor en producción.

Preguntas frecuentes

¿WireGuard es más seguro que OpenVPN?

No es que uno sea más seguro en abstracto: WireGuard reduce la superficie de ataque al tener menos código y menos opciones de configuración, lo que baja la probabilidad de un error humano. OpenVPN, bien configurado con cifrados modernos, también es seguro, pero su flexibilidad exige más cuidado al configurarlo.

¿Necesito abrir un puerto en el firewall?

Sí, el puerto UDP que declares en ListenPort (51820 por convención) debe estar accesible en el servidor. El cliente no necesita abrir ningún puerto entrante si es quien inicia la conexión.

¿WireGuard oculta que estoy usando una VPN?

No de forma nativa. El tráfico UDP de WireGuard tiene un patrón reconocible y algunos firewalls corporativos o estatales pueden bloquearlo por eso. Para ofuscación existen envoltorios de terceros que no forman parte del protocolo original.

¿Funciona en Windows y macOS?

Sí, existen clientes oficiales de WireGuard para Windows, macOS, Android, iOS y BSD, además del soporte nativo en el kernel de Linux.

¿Qué pasa si cambio de red mientras estoy conectado?

El túnel se mantiene: WireGuard identifica al peer por su clave pública, no por la IP de origen, así que el roaming entre redes no rompe la conexión.

¿Cómo reviso si el túnel está activo?

Con sudo wg show wg0: si aparece un latest handshake reciente, el túnel está funcionando.

Referencias

• WireGuard.com: sitio oficial del proyecto, con el conteo de líneas de código y la nota de inclusión en el kernel de Linux.- Whitepaper de WireGuard: paper técnico de Jason Donenfeld que documenta el protocolo completo.- Noise Protocol Framework: especificación del framework criptográfico sobre el que se construye el handshake de WireGuard.- BoringTun en GitHub: implementación en espacio de usuario de WireGuard escrita en Rust por Cloudflare.- WireGuard en Wikipedia: contexto histórico, cronología de adopción y comparación con protocolos previos.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.