El perfil bloqueado al servidor falla detrás de un proxy TLS: ¿qué generación?

Un usuario puede conectarse y otro no, a través del mismo portal, el mismo día. Ambos tienen perfiles bloqueados al servidor, ambos están en la misma compilación de Access Server, y la única diferencia es cuándo se generó su perfil. Ese es el patrón que vale la pena reconocer, porque "bloqueado al servidor" nombra una política y no una secuencia de conexión. Access Server ha entregado dos generaciones de ese artefacto, y un proxy inverso TLS está delante de solo una de sus rutas. Tres condiciones deciden en qué rama está usted.

Dos generaciones, dos secuencias de conexión

En el diseño más antiguo, vigente hasta la 2.8, el archivo importado es un pseudoperfil. OpenVPN Connect lo usa para autenticarse contra la API web de Access Server por HTTPS, recibe un perfil temporal bloqueado al usuario y un token de sesión, y solo entonces establece la VPN. Dos transportes se ejecutan en secuencia, y el primero es una petición web ordinaria.

El formato introducido con la 2.9 no realiza esa inicialización por conexión. Es un perfil nativo que pueden usar los OpenVPN clientes compatibles, no solo OpenVPN Connect. Descargarlo o importarlo por URL todavía puede implicar HTTPS — eso es un paso de publicación, no una obtención de un perfil temporal por conexión.

Una actualización no reescribe necesariamente los perfiles ya emitidos, así que una versión actual del servidor todavía puede estar entregando el artefacto antiguo. La compilación del servidor le dice qué es posible, no qué importó este usuario.

Tres condiciones que eligen su rama

La primera condición es la generación del artefacto. Pida el archivo, mire cómo se produjo y anote la versión del cliente que lo importó. Si no puede establecer la generación a partir del archivo, un perfil nuevo emitido para una cuenta de prueba le dirá qué produce el servidor hoy, que es una información distinta de la que tiene el usuario que falla.

La segunda es qué termina realmente su front-end. Un proxy inverso HTTP de capa siete que descarga el TLS no es el mismo objeto que un reenviador TCP de capa cuatro, y un reenviador UDP tampoco lo es. La disposición habitual de Access Server en el puerto 443 hace que el demonio OpenVPN TCP reconozca el tráfico del navegador y lo entregue a los servicios web, así que insertar un terminador HTTPS ajeno delante no conserva el tratamiento de protocolo de ese demonio. Compartir el número 443 no hace equivalentes dos diseños.

La tercera es dónde aterriza el fallo. Un fallo previo a la VPN y un fallo del canal de control se parecen en un cliente que solo dice "conectando", pero dejan pruebas en lugares distintos. Si el formato antiguo está en juego, la inicialización es candidata. Si el formato nuevo está en juego, un registro de acceso web vacío es esperable y no prueba nada en ningún sentido.

Cuando el artefacto es antiguo: la inicialización falla primero

Lea el error real del cliente en lugar de su estado final. Los campos interesantes son el error HTTPS, la identidad del servidor que el cliente esperaba, el destino al que fue la petición y si se completó la validación del certificado. Luego contrástelos con los registros del servicio web y del proxy en el lado del servidor.

Que un navegador llegue a la página de inicio de sesión no es prueba de que la autenticación por API de este cliente haya tenido éxito. Son peticiones distintas, con expectativas de certificado distintas y a menudo nombres de host distintos. Si el portal se sirve correctamente y el cliente sigue fallando, la discrepancia está en la ruta de inicialización, no en la contraseña del usuario.

No haga pasar la comparación desactivando la verificación TLS o relajando la política de autenticación. Eso convierte una discrepancia de configuración diagnosticable en una ruta que funciona pero no está verificada, y es exactamente el cambio que convierte una prueba temporal en un agujero permanente. La documentación de Access Server sobre perfiles de conexión describe ambas generaciones y el flujo del perfil temporal, y es la referencia que conviene consultar antes de suponer que un proxy tiene la culpa.

Cuando el artefacto es nuevo: lea el canal de control

Con un perfil de estilo 2.9, el cliente va directo al punto final nativo de la VPN. Investigue los puntos finales del perfil, el transporte en uso y el error del canal de control. Si el cliente nunca emite una petición HTTP, eso es coherente con el diseño y no es un síntoma.

Aquí también cambia de forma la cuestión del proxy. Una descarga HTTPS no puede romper un flujo solo TCP que nunca ve, pero todavía puede romper la descarga que publica el perfil, y un reenviador solo TCP no transportará UDP en absoluto. Compruebe qué transporte pide el perfil antes de concluir que el front-end es irrelevante.

El paso directo TLS para un solo flujo es una disposición estrecha. No proporciona reenvío UDP y no reproduce el comportamiento de reenvío de servicios del propio demonio en el 443. Si su front-end hace una de esas cosas, diga cuál, porque el remedio es distinto.

Remedios que se mantienen estrechos

La comprobación menos intrusiva es generar un perfil nuevo compatible para una cuenta de prueba y conectarse por el punto final nativo previsto con los mismos requisitos de autenticación. Si eso funciona y el perfil antiguo conservado no, ha separado el artefacto del servidor y del proxy en un solo paso.

La distribución de un perfil bloqueado al usuario elimina por completo la dependencia de la inicialización heredada, porque no hay ningún intercambio de perfil temporal que pueda fallar. Debe emitirse para el usuario previsto, nunca copiarse de un administrador, y cambia qué tiene autorizado a hacer el cliente, así que trátelo como una decisión de política y no como una solución alternativa.

Después arregle la disposición de publicación para que exista cada ruta necesaria: la ruta web para las descargas y el uso del portal, y la ruta nativa de la VPN en el transporte que los perfiles esperan. Mantenga el trabajo del proxy en una sola capa. Un túnel bloqueado al usuario que funciona demuestra que esa ruta funciona; no demuestra que toda disposición de proxy admita toda generación, y un fallo de inicialización antiguo no condena el formato más nuevo.

• Identifique la generación del artefacto antes de tocar el proxy.
• Establezca si el fallo ocurre antes del túnel o dentro de él.
• Confirme qué termina el front-end: HTTP, flujo TCP o UDP.
• Pruebe un perfil recién emitido contra el punto final nativo con la política sin cambios.