WireGuard: cómo funciona el protocolo que crea el túnel de FortiSafe
Equipo FortiSafe ·
WireGuard es el protocolo que crea el túnel cifrado entre el dispositivo y el servidor de la VPN. FortiSafe lo eligió por hechos verificables: el código es lo bastante pequeño para auditarlo, la criptografía es actual, la seguridad del protocolo fue verificada formalmente por investigadores y forma parte del kernel Linux desde 2020. Abajo, cómo funciona por dentro.
Por qué elegimos WireGuard
- Código pequeño: según el artículo técnico de su autor, Jason A. Donenfeld, la implementación para Linux tiene menos de 4.000 líneas, lo que facilita auditarla y verificarla.
- Criptografía actual: Curve25519, ChaCha20-Poly1305, BLAKE2s y HKDF, detalladas en la tabla de abajo.
- Seguridad verificada formalmente: el protocolo tiene pruebas de seguridad hechas con herramientas como Tamarin y CryptoVerif, y la Curve25519 que usa proviene de implementaciones verificadas.
- Dentro del kernel Linux: WireGuard entró oficialmente en Linux 5.6, publicado el 29 de marzo de 2020.
- Simple de operar: cada extremo se identifica con una clave pública corta, al estilo de OpenSSH, y el propio protocolo crea y renueva las sesiones.
- El objetivo declarado por el autor es reemplazar a IPsec en la mayoría de los usos y a soluciones como OpenVPN, siendo más seguro, más rápido y más fácil de usar.
Enrutamiento por clave criptográfica
El principio de WireGuard es asociar la clave pública de cada extremo a las direcciones IP que puede usar dentro del túnel. El artículo técnico lo llama cryptokey routing, enrutamiento por clave criptográfica.
Al enviar un paquete, la interfaz busca qué clave corresponde a la IP de destino y cifra el paquete para esa clave. Al recibirlo, lo descifra y comprueba si la IP de origen dentro del paquete es una de las permitidas para la clave que lo cifró. Si no lo es, el paquete se descarta.
En la práctica, saber de dónde vino un paquete dentro del túnel es lo mismo que saber qué clave lo cifró.
El handshake: un viaje de ida y vuelta
- WireGuard usa el patrón Noise_IK del Noise Protocol Framework, y todo viaja por UDP.
- Primer mensaje, de quien inicia: una clave pública temporal (efímera), la clave pública fija de quien inicia, cifrada, y una marca de tiempo TAI64N, también cifrada, que impide reutilizar un mensaje grabado.
- Segundo mensaje, de quien responde: su clave efímera y una prueba cifrada de que los dos extremos llegaron al mismo estado.
- Los dos extremos derivan las claves de la sesión con HKDF. Quien responde solo empieza a enviar datos después de recibir el primer paquete cifrado con la sesión nueva, lo que confirma las claves.
- Sumando los campos descritos en el protocolo, el mensaje de inicio tiene 148 bytes y el de respuesta, 92.
- Propiedades del intercambio de claves listadas en la página oficial: secreto perfecto hacia adelante (perfect forward secrecy), ocultación de identidad, protección contra el reenvío de mensajes grabados y contra la suplantación con clave comprometida.
La criptografía de WireGuard
| Pieza | Para qué sirve | Especificación |
|---|---|---|
| Curve25519 | Intercambio de claves Diffie-Hellman (ECDH) entre los extremos | Claves de 32 bytes |
| ChaCha20-Poly1305 | Cifrar y autenticar cada paquete | Construcción AEAD de la RFC 7539 |
| XChaCha20-Poly1305 | Cifrar la cookie de la protección contra sobrecarga | Nonce aleatorio de 24 bytes |
| BLAKE2s | Hash y autenticación con clave (MAC) | RFC 7693 |
| HKDF | Derivar las claves de la sesión | RFC 5869 |
| SipHash24 | Claves de las tablas internas de búsqueda | — |
| Noise_IKpsk2 | Estructura del handshake | Noise Protocol Framework |
Claves que cambian todo el tiempo
Se crea una sesión nueva más o menos cada 2 minutos, por temporizadores y no por pedido de quien la usa. Quien obtenga las claves de una sesión no puede descifrar las anteriores.
Si no se crea ninguna sesión nueva en tres veces el tiempo máximo de una sesión, 9 minutos, las claves temporales y las de la sesión se borran de la memoria.
Los temporizadores del protocolo
| Constante | Valor | Qué hace |
|---|---|---|
| Rekey-After-Time | 120 segundos | Edad de la sesión a partir de la cual quien la inició pide una nueva |
| Reject-After-Time | 180 segundos | Una sesión más vieja que esto no envía ni recibe datos |
| Rekey-Attempt-Time | 90 segundos | Cuánto tiempo se intenta un nuevo handshake antes de desistir |
| Rekey-Timeout | 5 segundos | Intervalo mínimo entre dos mensajes de inicio de handshake |
| Keepalive-Timeout | 10 segundos | Quien recibió datos y no tiene nada que responder envía un paquete vacío después de este tiempo |
| Rekey-After-Messages | 2⁶⁰ mensajes | Cantidad de paquetes después de la cual se pide una sesión nueva |
| Reject-After-Messages | 2⁶⁴ − 2¹³ − 1 mensajes | Límite de paquetes de una sesión |
Silencio y protección contra sobrecarga
WireGuard no responde a mensajes que no se autentican. Quien recorre internet sin conocer la clave pública del servidor no recibe ninguna respuesta.
Cada mensaje de handshake lleva un código de autenticación, el mac1, calculado con la clave pública del servidor. Bajo carga, el servidor puede responder con una cookie en lugar de procesar el handshake: la cookie está ligada a la IP de quien la pidió, sale de un secreto que cambia cada dos minutos y viaja cifrada con XChaCha20-Poly1305.
Quien inicia repite el mensaje con un segundo código, el mac2, hecho con esa cookie. Así demuestra que controla esa IP antes de que el servidor gaste procesamiento en el intercambio de claves.
Cambiar de red sin cortarse
Cada extremo guarda la dirección de donde vino el último paquete autenticado correctamente y responde a ella. Si el celular sale del Wi-Fi y entra en 4G, el servidor pasa a responder a la dirección nueva en cuanto recibe el primer paquete válido.
Como las sesiones se crean y renuevan por temporizadores, no hay conexión que abrir o cerrar: la interfaz queda lista y el protocolo se encarga del resto.
Seguridad verificada formalmente
- Tamarin, verificación simbólica de Jason Donenfeld y Kevin Milner: corrección, acuerdo de claves fuerte y autenticidad, resistencia a la suplantación con clave comprometida y al ataque de clave compartida desconocida, secreto de las claves, secreto hacia adelante, unicidad de la sesión y ocultación de identidad.
- CryptoVerif, prueba computacional de Benjamin Lipp que cubre también los paquetes de datos: secreto de los mensajes, secreto hacia adelante, autenticación mutua y resistencia al reenvío del primer mensaje, entre otras.
- Modelo eCK, prueba computacional de Benjamin Dowling y Kenneth G. Paterson, hecha sobre una variante equivalente del protocolo.
- ProVerif, con el proyecto Noise Explorer, de Nadim Kobeissi y Karthikeyan Bhargavan, sobre el patrón IK de Noise.
- Curve25519 con implementaciones verificadas: HACL*, en 64 bits, y Fiat-Crypto, en 32 bits.
Del artículo al kernel Linux
WireGuard se presentó en un artículo en NDSS 2017, el simposio de seguridad de redes y sistemas distribuidos. La revisión más reciente del artículo técnico es del 1 de junio de 2020.
Linux 5.6, publicado el 29 de marzo de 2020, trajo WireGuard dentro del kernel. El sitio oficial ofrece aplicaciones para Linux, Windows, macOS, iOS y Android.
Es el protocolo que usa FortiSafe.
Fuentes
Páginas consultadas el 14 de septiembre de 2026.
- WireGuard — protocolo y criptografía (en inglés) — Primitivas criptográficas, handshake, propiedades del intercambio de claves y campos de los mensajes; los tamaños en bytes los sumó el equipo de FortiSafe.
- WireGuard — artículo técnico de Jason A. Donenfeld (en inglés) — Enrutamiento por clave, cambio de red, cookies, temporizadores y tamaño del código; revisión del 1 de junio de 2020.
- WireGuard — verificación formal (en inglés) — Pruebas en Tamarin, CryptoVerif, eCK y ProVerif e implementaciones verificadas de Curve25519.
- Kernel Newbies — Linux 5.6 (en inglés) — Publicación el 29 de marzo de 2020, con WireGuard en el kernel.
- WireGuard — sitio oficial — Sistemas con aplicación oficial.