Qué es WireGuard: cómo funciona y cómo nació

Antes de WireGuard, las opciones habituales eran IPsec y OpenVPN. IPsec es una gran familia de estándares con infinidad de parámetros, y conectar equipos de fabricantes distintos tiene fama de ser un dolor de cabeza. OpenVPN funciona en espacio de usuario y depende de una enorme biblioteca TLS: es flexible, pero lento. En ambos casos el código es tan extenso que casi nadie puede auditarlo de principio a fin.

WireGuard plantea lo contrario: hacer una sola cosa y hacerla bien. En el sistema aparece como una tarjeta de red virtual (por ejemplo wg0). Le asignas tu clave privada y las claves públicas de unos cuantos pares; lo que envíes por ella sale cifrado y lo que llega se descifra y sale por ella. Todo lo demás (rutas, cortafuegos, asignación de direcciones) se deja a las herramientas que el sistema ya tiene.

También tiene muy claro lo que no hace a propósito: no negocia algoritmos, no gestiona usuarios ni contraseñas, no asigna direcciones y no disfraza el tráfico. Esas funciones se consideran fuente de vulnerabilidades o se dejan a herramientas de nivel superior.

En WireGuard cada dispositivo tiene un par de claves, y la pública es su identidad, igual que en SSH: cada lado escribe en su configuración la clave pública del otro y con eso queda establecida la confianza, sin certificados ni usuario y contraseña.

Para cada par se define una lista de “direcciones permitidas” (AllowedIPs) que actúa en los dos sentidos. Al enviar, el paquete se cifra con la clave pública del par en cuyo rango cae la dirección de destino y se le envía a él. Al recibir, tras descifrar se comprueba que la dirección de origen esté en el rango de ese par; si no, el paquete se descarta. Es el llamado enrutamiento por clave criptográfica (cryptokey routing): la tabla de rutas y el control de acceso se funden en una sola tabla.

Por eso, si pones 0.0.0.0/0 como dirección permitida de un par, le estás entregando todo el tráfico: es lo que se suele llamar VPN global. Si solo pones un rango de la red interna, únicamente el acceso a ese rango pasa por el túnel.

Antes de comunicarse por primera vez, dos dispositivos hacen un handshake: el que inicia envía un paquete, el otro responde con otro, y con esa única ida y vuelta ambos obtienen claves de sesión válidas solo durante un tiempo. El handshake se basa en el marco de protocolos Noise: las claves de larga duración sirven para autenticarse mutuamente y las claves temporales garantizan el secreto perfecto hacia adelante (forward secrecy), de modo que aunque la clave privada se filtre en el futuro, el tráfico grabado antes no se puede descifrar.

Las claves de sesión se renuevan automáticamente cada pocos minutos, sin que el usuario lo note y sin ninguna “reconexión”.

Los algoritmos son fijos: Curve25519 para el intercambio de claves, ChaCha20-Poly1305 para cifrar los datos y BLAKE2s como hash. Al no haber negociación, tampoco hay ataques de degradación: nadie puede convencer a las partes de usar un algoritmo más débil. Si algún día uno de ellos se rompe, la solución es publicar una nueva versión del protocolo que lo sustituya entero, no añadir una opción.

Además se puede añadir una clave precompartida, que se combina con el mecanismo de clave pública como defensa ante la amenaza que los futuros ordenadores cuánticos suponen para los algoritmos de clave pública.

• Solo UDP: WireGuard cifra cada paquete por separado y lo envía dentro de un paquete UDP. No usar TCP es deliberado: meter TCP dentro de TCP hace que las dos capas retransmitan y, cuando hay pérdida de paquetes, se frenan mutuamente.
• Silencio ante desconocidos: a ningún paquete sin autenticar se le responde. Para quien escanea puertos, ese puerto parece cerrado y no hay forma de saber que hay un WireGuard detrás.
• Itinerancia: WireGuard no reconoce “conexiones”, solo claves públicas. Si el par cambia de dirección (el móvil pasa de la wifi a los datos móviles), en cuanto llega su siguiente paquete autenticado, las respuestas se envían a la nueva dirección. Por eso el túnel no se cae al cambiar de red.
• Silencio: si no hay nada que enviar, el túnel no genera tráfico, y por eso consume muy poca batería en el móvil. Solo cuando un dispositivo está detrás de un router y tiene que estar siempre localizable hace falta activar el keepalive periódico (PersistentKeepalive), que envía un paquete pequeño cada pocas decenas de segundos para mantener la asignación en el router.

• Funciona en el kernel: en Linux, WireGuard es un módulo del kernel y los paquetes no tienen que copiarse de ida y vuelta entre el kernel y un programa de usuario; OpenVPN tradicionalmente funciona en espacio de usuario y cada paquete da un rodeo extra.
• Algoritmos aptos para cualquier CPU: ChaCha20 no depende de instrucciones de aceleración específicas, lo que le da ventaja sobre todo en chips sin instrucciones AES, como los de móviles y routers.
• Handshake corto: con una ida y vuelta ya se pueden enviar datos, así que establecer la conexión casi no tiene espera.
• Poco código: el camino es corto y las optimizaciones se concentran en los pasos críticos.
• Ojo: todo esto se refiere al coste del protocolo y de su implementación. La velocidad real en una conexión internacional depende mucho más de la pérdida de paquetes de la línea y de cómo trate el operador el tráfico UDP.

• Hacia 2015: Jason A. Donenfeld empieza a desarrollar WireGuard y lo publica; al principio es un módulo independiente del kernel de Linux.
• 2017: el artículo que describe su diseño se presenta en NDSS, una conferencia de seguridad de redes, y el protocolo pasa después por varias verificaciones formales independientes. Por esas fechas, proveedores de VPN como Mullvad empiezan a ofrecer conexión por WireGuard.
• 2018: Linus Torvalds, creador de Linux, elogia su código en la lista de correo y dice que, comparado con OpenVPN e IPsec, es una obra de arte; la frase lo hace famoso entre los desarrolladores.
• 2019: Cloudflare publica BoringTun, una implementación en espacio de usuario escrita en Rust, y usa WireGuard en su WARP; NordVPN lanza NordLynx, basado en WireGuard; y Tailscale arranca también en esta época con WireGuard como plano de datos.
• Marzo de 2020: WireGuard entra en la rama principal del kernel con Linux 5.6 y se publica la versión 1.0. Desde entonces las distribuciones Linux principales lo traen de serie, sin instalar módulos aparte. Ese mismo año OpenBSD también lo incorpora a su kernel.
• 2021: llega WireGuardNT, una implementación en modo kernel para Windows con un rendimiento claramente superior a la anterior en espacio de usuario; poco después FreeBSD también tiene la suya en el kernel.
• Hoy: hay clientes oficiales para Windows, macOS, Linux, iOS y Android; sistemas de routers y NAS como OpenWrt y Synology lo traen integrado, y la gran mayoría de las VPN comerciales lo ofrecen como protocolo predeterminado u opcional.

• No reparte las claves: cada vez que añades un dispositivo, hay que escribir su clave pública en la configuración de los demás. Con muchos dispositivos se vuelve inmanejable, y precisamente por eso existen herramientas como Tailscale.
• No asigna direcciones dinámicamente: la dirección interna de cada par está fijada en la configuración; no existe el mecanismo de OpenVPN de “te conectas y recibes una dirección”. Las VPN comerciales que lo usan tienen que añadir su propia capa por fuera.
• Dudas sobre privacidad: el servidor tiene que recordar la última dirección pública de cada par para poder responderle. Los proveedores de VPN que prometen no guardar registros suelen necesitar un tratamiento adicional (por ejemplo, borrado periódico o doble traducción de direcciones).
• Solo UDP: en redes que bloquean o limitan el UDP no funciona o va muy lento. Para que vaya por TCP o por el puerto 443 hay que envolverlo en otra herramienta.
• Sin camuflaje: los paquetes de handshake y de datos tienen un formato y una longitud característicos y son fáciles de identificar. Su objetivo de diseño es la seguridad y la sencillez, no resistir la censura.
• Sin sistema de cuentas: el protocolo no conoce usuarios, contraseñas ni fechas de caducidad; solo reconoce claves públicas.

• Tamaño del código: el núcleo de WireGuard tiene unos pocos miles de líneas; OpenVPN con la biblioteca TLS de la que depende y las distintas implementaciones de IPsec rondan los cientos de miles.
• Transporte: WireGuard solo usa UDP; OpenVPN admite ambos y puede ir por TCP 443, mezclado en el puerto del tráfico HTTPS; IPsec usa su propio número de protocolo y UDP 500 / 4500.
• Configuración: en WireGuard, unas pocas líneas por par; el archivo de configuración de OpenVPN tiene muchas opciones pero es muy flexible; IPsec es el más complicado.
• Rendimiento: en una red limpia, WireGuard suele ser el más rápido y el que menos batería gasta; las versiones recientes de OpenVPN también tienen aceleración en el kernel (DCO) y la diferencia se está acortando.
• Funciones: autenticación con usuario y contraseña, envío dinámico de direcciones y rutas, funcionamiento por TCP… OpenVPN lo trae todo de serie; WireGuard depende de un sistema externo para cubrirlo.
• Compatibilidad: OpenVPN tiene una larga historia y casi cualquier router antiguo, NAS o dispositivo embebido lo admite; WireGuard ya está extendido en los sistemas de los últimos años, pero en equipos viejos puede no estar.

• Tailscale: añade a WireGuard inicio de sesión, reparto de claves, atravesar NAT y relés, y lo convierte en una red entre dispositivos que se monta sola; consulta Cómo funciona Tailscale. Headscale es una implementación de código abierto de su servidor de control.
• Netmaker, NetBird, Firezone y similares: también productos de red entre dispositivos o de confianza cero que usan WireGuard como plano de datos y añaden su propio plano de gestión.
• Cloudflare WARP: un cliente WireGuard para el público general que envía el tráfico a la red de Cloudflare.
• Versiones propias de VPN comerciales: NordLynx y otras, que añaden por fuera de WireGuard una capa de asignación de direcciones y tratamiento de privacidad.
• Variantes como AmneziaWG: modifican las cabeceras y el relleno para ocultar los rasgos fijos de WireGuard en redes con inspección estricta; no son compatibles con los clientes WireGuard estándar.

• Que funcione depende ante todo del UDP: muchas conexiones de banda ancha y redes móviles limitan el UDP de gran volumen. Se nota en que va rápido al conectar y se vuelve lento al rato, o en tirones claros en las horas punta de la noche.
• La conexión directa hacia el extranjero es fácil de identificar: el handshake de WireGuard tiene un patrón fijo y en los enlaces internacionales puede detectarse e interferirse. Se nota en que el handshake no se completa o en que el tráfico se corta tras un tiempo de uso. Es la consecuencia directa de que el protocolo no tenga camuflaje.
• Conectar dispositivos que están todos dentro de China (oficina y casa, móvil y NAS) no pasa por enlaces internacionales y normalmente no tiene ese problema; solo influyen la limitación de UDP y si se logra la conexión directa a través de NAT.
• Por eso es más adecuado para conectar dispositivos entre sí y para el acceso remoto. Para salir al extranjero de forma estable durante mucho tiempo hace falta combinarlo con un método con camuflaje o que vaya por TCP / TLS; la comparación entre protocolos está en Comparativa de protocolos VPN.

La sección Privada de LeoTun usa Tailscale, cuyo plano de datos es WireGuard: los túneles entre tus dispositivos y hacia los nodos de salida de cada región los cifra y transporta él. No tienes que generar claves ni escribir configuraciones: al iniciar sesión con tu cuenta del sitio, el cliente lo hace todo. Cómo usarla en Qué es la conexión Privada (Tailscale); el acceso está en la página de Privada.

Además de Privada, la misma cuenta incluye métodos que no dependen del UDP: Cisco (AnyConnect) va por TLS, OpenVPN puede ir por TCP y Hiddify (Hysteria2) está pensado para líneas con pérdida de paquetes. Si en tu red Privada va lenta o inestable, basta con cambiar de método; consulta Qué método de conexión usar en cada caso.