Dónde está TLS dentro de OpenVPN y qué cambia la forma

OpenVPN sí usa TLS, y la gente suele extender eso a una afirmación que no puede sostener: que un túnel por tanto parece un navegador que visita un sitio. La primera parte es cierta. La segunda no. Aquí TLS pertenece a un canal de control que viaja dentro del propio contenedor de OpenVPN, junto a un canal de carga con una criptografía completamente distinta, así que quien inspecciona los bytes iniciales ve OpenVPN.

Dos conversaciones en un sobre

Piense en una sesión como dos conversaciones que comparten un sobre. Una valida certificados y deriva material de clave. La otra cifra lo que usted envía en realidad, usando lo que produjo la primera.

El sobre es el protocolo. Cada paquete empieza con una cabecera pequeña que nombra su tipo, y esa cabecera llega antes que cualquier otra cosa.

Qué llega realmente primero

Por ese orden, lo primero en el cable no es un registro TLS. Es la cabecera de OpenVPN, seguida del contenido del canal que anuncie la cabecera. Un ClientHello existe ahí dentro, solo que no en el byte cero. No hace falta descifrar nada para notar la diferencia, porque la forma sola la delata.

Los valores por defecto también cuentan. El flujo es UDP al 1194 salvo que el perfil elija TCP. En ambos casos el aspecto exterior es un túnel y no una petición web.

Tres maneras honestas de cambiar la forma

Un terminador TLS como stunnel acepta TLS en un puerto en cada extremo y entrega el flujo descifrado a OpenVPN localmente, así que la red ve TLS hacia ese puerto. Un protocolo que es TLS desde el primer byte se comporta de otra manera: el intercambio compatible con AnyConnect que implementa ocserv se parece al acceso remoto corporativo que muchas redes ya esperan. SSTP, que viene con Windows, tiene la misma propiedad en otro producto.

En Linux, la opción -w de SSH transporta un enlace punto a punto dentro de una sesión SSH, lo que resulta útil cuando SSH es el único protocolo permitido. Es la más barata de las cuatro si SSH ya funciona desde esa red, y la menos útil si no.

Qué no cambia ninguna de ellas

Ninguna de estas cambia a qué puede llegar el túnel. No hacen accesible una dirección bloqueada, no autentican a nadie y no deciden rutas.

Un envoltorio también le cuesta un componente. Dos escuchas y dos archivos de configuración significan dos lugares para un fallo, y ambos se ven idénticos desde el asiento del usuario. Presupueste eso antes de adoptar uno. La sesión sigue siendo un único flujo cifrado de larga duración hacia un destino, y su volumen y su tiempo siguen visibles.

Primero diagnostique, luego elija

Así que diagnostique primero. El UDP descartado se responde con modo TCP, y una firma reconocida se responde con otro protocolo o un envoltorio. Elegir una herramienta antes de conocer el bloqueo es como la gente acaba manteniendo tres capas que fallan todas por la misma razón.

Una red que solo permite puertos web reduce la elección a un protocolo basado en TLS en el 443. Aplicar las tres a la vez da una pila que nadie puede depurar, así que cambie una cosa y vuelva a probar el mismo flujo.

Si no se aplica ninguna, la respuesta exacta es que esta red no transportará un túnel para usted. Eso es un hallazgo y no un fracaso del esfuerzo. Recorrer más opciones no revierte una decisión de política tomada más arriba.

Un límite se alza delante de todo esto. El permiso para ejecutar un túnel en la red de otra persona es una cuestión de política, decidida aparte de si el mecanismo funciona. Estos hechos explican lo que ve un observador y no conceden permiso.