Canal de control y canal de datos en VPN: revise la capa correcta

El cliente dice conectado, el servidor ve un par y la aplicación sigue sin alcanzar nada. En ese punto la pregunta útil no es qué cifrado cambiar, sino qué canal falló. OpenVPN nombra dos funciones de forma explícita: un canal de control que negocia y gestiona la sesión, y un canal de datos que transporta el tráfico protegido. IKEv2 expresa una división parecida mediante la asociación IKE y la asociación CHILD. Realice las comprobaciones siguientes en orden, porque una corrección de la ruta de datos aplicada a un fallo de la ruta de control desperdicia una ventana de cambio.

Nombre el canal antes de depurarlo

El lado de control negocia el material de seguridad, autentica a los pares y gestiona la conexión. El lado de datos transporta el tráfico seleccionado una vez que existe el estado necesario.

Fallan de forma distinta. Un fallo de control suele dejarle sin ninguna sesión utilizable, o con una sesión que renegocia en bucle. Un fallo de datos deja una sesión que parece sana mientras los paquetes se descartan, se enrutan mal o se protegen con parámetros que el otro extremo no aceptará. La línea de registro que está leyendo le dice en cuál de los dos está, así que lea la etiqueta antes del texto del error.

Compruebe el intercambio de control

Confirme que el saludo se completa y que ambas partes coinciden en el transporte, la versión de TLS y el método de autenticación. Los registros de OpenVPN imprimen líneas separadas del canal de control y del canal de datos, y la línea de control es donde aparece una discrepancia de certificado, de versión de TLS o de tls-crypt.

Si el intercambio de control falla, mire el puerto accesible, la cadena de certificados y sus fechas de validez, el reloj del sistema, el solapamiento de cifrados entre cliente y servidor y cualquier clave tls-auth o tls-crypt. Una cadena de certificados grande también puede fallar en la MTU de la ruta antes de que se complete cualquier autenticación, lo que parece un tiempo de espera y no un error criptográfico.

Corrija los fallos de control con ajustes de control. Subir el cifrado de datos o relajar la política de autenticación de datos no completará un saludo que nunca superó el intercambio de certificados.

Compruebe el canal de datos por separado

Con la sesión activa, confirme el cifrado y el modo de datos negociados, la derivación de claves y el comportamiento de renovación de clave. En OpenVPN, la línea del canal de datos indica el cifrado y el tamaño de clave que realmente se inicializaron, y pueden diferir del primer cifrado del perfil.

Después compruebe qué instaló la sesión. Un PUSH_REPLY puede añadir rutas, un servidor DNS y una directiva redirect-gateway, y cualquiera de ellas puede enviar tráfico adonde la aplicación no puede usarlo. Para IKEv2, la pregunta equivalente es si los selectores de la asociación CHILD coinciden con las direcciones del flujo real.

tls-auth y tls-crypt pertenecen al canal de control. Autentican o cifran el saludo y no seleccionan el cifrado de datos de la aplicación. Si añade uno de ellos esperando un cambio en la ruta de datos, lo único que ha cambiado es el saludo.

Relacione los nombres con IKEv2 y OpenVPN

IKEv2 tiene una asociación de seguridad IKE y una o más asociaciones CHILD. La asociación IKE transporta los intercambios de control; la asociación CHILD transporta el tráfico protegido y sus selectores. Se negocian y se renuevan las claves con calendarios separados, así que una puede estar sana mientras la otra no lo está.

ESP no tiene dentro un canal de control al estilo de TLS. El protocolo de control es IKE, y ESP es la carga protegida. Llamar a ESP el canal de datos es una abreviatura laxa que se vuelve confusa al leer una captura de paquetes, porque la captura muestra los mensajes IKE y los paquetes ESP como protocolos distintos en el cable.

Mantenga la correspondencia explícita en sus notas: el canal de control de OpenVPN y el IKE SA son el lado de gestión, el canal de datos de OpenVPN y el CHILD SA son el lado del tráfico, y las implementaciones no son intercambiables aunque la división parezca similar.

Deje de cambiar el ajuste equivocado

Recorra la ruta en una sola dirección: intercambio de control, protección de datos, reenvío y después resolución de nombres. Deténgase en la primera etapa que falle y corrija solo esa etapa. Una sesión conectada con un ping que funciona hasta la puerta de enlace pero sin tráfico de la aplicación es un problema de reenvío o de selectores, no de saludo.

Escriba la evidencia de cada etapa por separado en el ticket: la línea de registro de control, los parámetros de datos negociados, las rutas instaladas y una petición real. Esa estructura evita que se debilite una comprobación de identidad que funciona para reparar un problema de enrutamiento posterior que nunca causó, y evita que se venda un cambio de cifrado de datos como solución de un error de certificado.

La documentación del protocolo OpenVPN es la referencia para la división entre control y datos; úsela cuando la interfaz de un proveedor emplee otras palabras para las mismas dos funciones.