Pasos del handshake de VPN: qué ocurre antes de que fluya el tráfico

Pulsar Conectar inicia cuatro tareas separadas que tienen éxito o fallan de forma independiente. El cliente debe llegar a un listener, acordar quién es el par, derivar claves y luego entregar un túnel funcional al resto del sistema. La mayoría de las conexiones fallidas se diagnostican en la tarea equivocada. Por eso el primer error importa más que el tercer reintento.

Llegue primero al listener

Antes de que se intercambie cualquier identidad, el cliente resuelve un nombre, elige una ruta y abre un transporte hacia un puerto. Un portal cautivo que responde a todo, un puerto cerrado y un nombre de host incorrecto fallan aquí, y ninguno de ellos es un problema de autenticación. Cambiar una contraseña no puede arreglar ninguno de los tres. Lea la primera línea del error antes de tocar las credenciales.

Un tiempo de espera agotado, el rechazo de un certificado y una cuenta rechazada son tres fallos distintos con tres comprobaciones distintas. Ordenarlos primero es lo que evita que un problema de red se depure como un problema de credenciales.

Demuestre el par y luego derive las claves

Cada protocolo necesita una forma de reconocer el servidor previsto, ya sea mediante una clave pública configurada o una cadena de certificados. El inicio de sesión del usuario es adicional a esa comprobación, no un sustituto de ella. Un servidor que acepta su contraseña no ha demostrado nada sobre su propia identidad. Por eso un secreto compartido escrito en un cliente no sustituye la verificación de quién respondió.

El intercambio deriva después las claves de tráfico a partir de las propias entradas del protocolo, y la contraseña de inicio de sesión generalmente no es la clave que se estampa en cada paquete. El material de identidad de larga duración y las claves de sesión de corta duración tienen vidas y trabajos distintos. De eso trata la confidencialidad hacia adelante.

Mantenga la verificación activada mientras investiga, porque un túnel que se conecta después de desactivar una comprobación no ha demostrado nada excepto que la comprobación hacía algo. Anote qué cambió y vuelva a dejarlo como estaba antes de la siguiente prueba.

Tres protocolos, tres conversaciones

En un despliegue de OpenVPN basado en TLS, el canal de control negocia los parámetros de seguridad mientras el canal de datos transporta el tráfico del túnel, así que una opción del canal de datos y un problema de certificado viven en lugares distintos. IKEv2 autentica a ambos participantes y luego establece asociaciones de seguridad IPsec con sus propias vidas. WireGuard deriva las claves mediante su intercambio basado en Noise y mantiene la máquina de estados deliberadamente pequeña. Saber cuál de los tres ejecuta decide qué registro vale la pena leer.

Clientes de aspecto similar no implican mensajes intercambiables por debajo, y un campo de configuración que existe en un producto puede no tener equivalente en otro. Copiar un perfil entre ellos es una suposición y no una migración.

Qué no hace el handshake

Las rutas, la resolución de nombres y la política de destino permanecen todas después. Un sitio interno puede quedar inalcanzable porque falta la ruta de su subred, aunque el par se autenticó correctamente y el túnel está activo. Tratar eso como cifrado débil le envía a buscar en la capa equivocada, y normalmente termina con un cambio de cifrado que no arregla nada.

La renovación de claves y la reconexión también se parecen en la mayoría de las pantallas de estado, y ninguna de las dos le dice si se bloqueó el tráfico ordinario durante la interrupción. Solo la política de fallo del cliente responde a esa pregunta, así que lea la política y no el icono.

Trabaje las etapas en el orden anterior y deténgase en la primera que produzca un error. Cada etapa posterior hereda el estado de las anteriores, así que un fallo en la tercera etapa no dice nada sobre la cuarta.

ip -brief address show tun0
ip route get 10.60.7.15
resolvectl query intranet.corp.internal