OpenVPN a través de un proxy HTTP: lea primero la respuesta CONNECT

Dirija un cliente VPN a un proxy HTTP corporativo y el primer dato útil es que el proxy no habla el protocolo de la VPN. Abre una conexión TCP normal a la dirección que usted indicó y luego se aparta, dejando que su cliente y el servidor realicen su propio intercambio por ese flujo. Todo lo que el cliente necesita, desde el tipo de transporte hasta el escucha del servidor, debe coincidir con esa disposición. Dos desajustes explican la mayoría de los fallos: un perfil UDP dirigido a un proxy CONNECT y una respuesta del proxy tomada por un error de la VPN.

Qué transporta el proxy y qué no

El proxy es solo un salto de transporte. No se convierte en el proxy de su navegador, no almacena en caché los sitios que visita por el túnel y no ve el tráfico interno salvo que alguien haya configurado la inspección a propósito. El túnel que abre es opaco para él por diseño.

Eso también significa que el proxy no puede arreglar un servidor que no tiene un escucha correspondiente. El permiso para llegar a un destino y un servicio que escucha en ese destino son hechos distintos, y solo el primero pertenece al administrador del proxy.

El portador debe ser TCP en ambos extremos

Un proxy CONNECT convencional solo retransmite un flujo de bytes , así que el cliente debe usar un transporte de flujo. Un fragmento de cliente para ese caso se ve así:

proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128

El lado del servidor necesita un escucha TCP real en el puerto indicado en la línea remote. Cambiar proto udp por proto tcp-client en un perfil crea un cliente que espera un flujo; no crea el flujo en el otro extremo. Si el mismo servidor también responde por UDP en ese puerto, es otro escucha, no un segundo modo del mismo.

Donde existe una instancia TCP separada, su dispositivo de túnel, su grupo de direcciones y su enrutamiento son recursos propios. Copiar una configuración que funciona y editar la palabra de transporte deja esos recursos apuntando a la instancia original, lo que produce una conexión que se autentica y luego no enruta nada.

Lea la respuesta del proxy antes del resultado de la VPN

El primer intercambio del cliente es una línea de solicitud que nombra el host y el puerto de destino. La respuesta a esa línea le dice si existe algún flujo de bytes, y llega antes de que se compruebe cualquier certificado o credencial:

CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194

Una respuesta de clase 200 a CONNECT significa que el flujo existe. No dice nada sobre si el certificado de la pasarela es de confianza, si la clave compartida coincide o si la cuenta de usuario es válida. Esas comprobaciones ocurren después, dentro del flujo, y fallan con los mensajes propios del cliente en lugar de con una línea de estado HTTP. Lea el registro del cliente para el primer OpenVPN evento tras el apretón de manos con el proxy, no para la última línea antes de que se cerrara la ventana.

Las credenciales del proxy y las de la VPN suelen ser identidades distintas en manos de equipos distintos. Un 407 no es una contraseña incorrecta de la cuenta de la VPN, y un certificado rechazado no es un problema de permisos del proxy.

Qué no expone CONNECT

Un túnel CONNECT explícito no es interceptación. El proxy reenvía bytes y no termina la sesión TLS de la VPN, así que la verificación del certificado del servidor por parte del cliente sigue teniendo sentido y debe permanecer activa. Desactivar la verificación para pasar un proxy resuelve un problema distinto del que usted tiene.

Existen disposiciones separadas en las que una organización termina e inspecciona TLS a propósito. Esas requieren su propia configuración de confianza y su propia decisión de política, y no son lo que pide una línea http-proxy corriente.

El costo de TCP dentro de TCP

Llevar el túnel sobre TCP mantiene el flujo exterior ordenado y con retransmisión, y el tráfico interior suele ser también TCP. Los dos mecanismos de recuperación no se coordinan, así que un solo segmento perdido puede detener todo lo que comparte ese flujo exterior hasta que se retransmita. Es un intercambio real por compatibilidad, no una actualización gratuita.

Use la ruta del proxy cuando la red no le deje alternativa, y prefiera una ruta UDP directa donde la política lo permita. En cualquier caso, tras un cambio confirme que el mismo proxy, el mismo destino y el mismo perfil llegan a la siguiente etapa; un navegador que carga una página en esa dirección ejerce otro protocolo y no demuestra nada sobre el túnel.