Qué hace una clave precompartida en IPsec, OpenVPN y WireGuard

Las palabras clave precompartida aparecen en la documentación de IPsec, OpenVPN y WireGuard, y describen tres objetos distintos. Uno es un secreto de autenticación, otro protege un canal de control y el tercero añade material a un handshake que ya tiene identidades. Tratarlos como intercambiables produce una conexión que falla en una etapa que nadie esperaba. Lea qué hace el campo en ese protocolo antes de copiar un valor en él.

Tres protocolos, tres significados

Cada protocolo define la tarea de la clave en su propia especificación, y las tareas no se solapan. Un secreto de autenticación demuestra que dos pares conocen el mismo valor. Una clave de canal de control protege la negociación que sigue. Un complemento de handshake cambia el calendario de claves sin cambiar quiénes son los pares.

Ninguno de esos papeles autentica a un usuario humano, y esa confusión es la que más tiempo cuesta. Una clave precompartida se aprovisiona en dispositivos o puertas de enlace antes del intercambio, así que todo portador parece idéntico al otro extremo. Esa propiedad es una ventaja para un enlace de sitio a sitio entre dos routers y un riesgo para un servicio de acceso remoto con empleados con nombre. Mantenga la credencial de la cuenta y el secreto criptográfico en columnas separadas del documento que describa el despliegue.

IPsec y OpenVPN usan la palabra de forma distinta

IKEv2 puede autenticar a un par con un secreto precompartido en lugar de certificados, y el valor debe coincidir en ambos extremos. Como el mismo secreto suele configurarse para un grupo de pares, cualquier portador puede suplantar a los demás, y el intercambio no gana confidencialidad hacia adelante de unas claves de identidad que nunca tuvo.

Las opciones tls-auth y tls-crypt de OpenVPN añaden una clave estática al canal de control, ya sea con una firma HMAC o cifrando la propia negociación. Esa clave no es una contraseña de usuario y no sustituye al certificado del cliente. Distinguir ambas cosas importa en el momento de la renovación, cuando un cambio de contraseña deja intacta la clave del canal de control.

La PSK de WireGuard añade, no identifica

Los pares de WireGuard ya tienen claves públicas y privadas Curve25519, y el handshake autentica esas identidades. Una clave precompartida opcional se mezcla en la clave de encadenamiento y aporta material simétrico por encima del intercambio de claves públicas.

No aporta identidad propia ni cuenta de usuario, así que un operador no puede distinguir a dos portadores por su PSK. Ambos extremos deben llevar el mismo valor o el handshake falla sin un error útil. Por eso la rotación tiene que planificarse en los dos lados a la vez y no como la edición de un solo archivo.

Revise la distribución, la rotación y la retirada

La distribución es el punto débil de todo diseño que usa un secreto en muchos lugares. Un valor pegado en una ventana de chat, guardado en un repositorio o reutilizado entre entornos acumula copias que nadie puede enumerar, y cada copia amplía el radio de daño sin ruido.

El texto Base64 no es cifrado. Un secreto guardado junto a un certificado público en el mismo directorio sigue siendo un secreto en claro.

openssl rand -base64 32
sudo wg show wg0 preshared-keys
sudo grep -R -n 'psk' /etc/ipsec.d/ 2>/dev/null

Rote según un calendario y después de cualquier exposición sospechada, actualizando cada par previsto antes de revocar el valor antiguo. Luego pruebe el enlace desde ambos extremos, porque una clave que no coincide falla en el handshake y se parece exactamente a un problema de cortafuegos.

Documente qué secreto protege qué etapa, para que un restablecimiento de contraseña nunca se confunda con la renovación de una clave criptográfica. Esa línea ahorra una hora cada vez que alguien audita el despliegue.