O perfil bloqueado ao servidor falla detrás dun proxy TLS: que xeración?
Access Server 2.8 e 2.9 constrúen os perfís bloqueados ao servidor de xeito distinto. Decida que ruta rompe o seu proxy antes de cambiar o front-end.
Un usuario pode conectarse e outro non, polo mesmo portal, o mesmo día. Ambos teñen perfís bloqueados ao servidor, ambos están na mesma compilación de Access Server, e a única diferenza é cando se xerou o seu perfil. Ese é o patrón que paga a pena recoñecer, porque "bloqueado ao servidor" nomea unha política e non unha secuencia de conexión. Access Server entregou dúas xeracións dese artefacto, e un proxy inverso TLS está diante de só unha das súas rutas. Tres condicións deciden en que rama está vostede.
Dúas xeracións, dúas secuencias de conexión
No deseño máis antigo, vixente ata a 2.8, o ficheiro importado é un pseudoperfil. OpenVPN Connect úsao para autenticarse contra a API web de Access Server por HTTPS, recibe un perfil temporal bloqueado ao usuario e un token de sesión, e só entón establece a VPN. Dous transportes execútanse en secuencia, e o primeiro é unha petición web ordinaria.
O formato introducido coa 2.9 non realiza esa inicialización por conexión. É un perfil nativo que poden usar os OpenVPN clientes compatibles, non só OpenVPN Connect. Descargalo ou importalo por URL aínda pode implicar HTTPS — iso é un paso de publicación, non unha obtención dun perfil temporal por conexión.
| Older server-locked (≤2.8) | Newer server-locked (2.9+) | |
|---|---|---|
| Before the tunnel | Web API call with credentials | Nothing; the profile is already local |
| Client requirement | OpenVPN Connect | Any compatible client |
| What a TLS web proxy can break | The bootstrap, before any VPN attempt | Download only, not the connection |
| Expected HTTP log on connect | A request from the client | Often nothing at all |
Unha actualización non reescribe necesariamente os perfís xa emitidos, así que unha versión actual do servidor aínda pode estar entregando o artefacto antigo. A compilación do servidor dille que é posible, non que importou este usuario.
Tres condicións que elixen a súa rama
A primeira condición é a xeración do artefacto. Pida o ficheiro, mire como se produciu e anote a versión do cliente que o importou. Se non pode establecer a xeración a partir do ficheiro, un perfil novo emitido para unha conta de proba diralle que produce o servidor hoxe, que é unha información distinta da que ten o usuario que falla.
A segunda é que remata realmente o seu front-end. Un proxy inverso HTTP de capa sete que descarga o TLS non é o mesmo obxecto que un reenviador TCP de capa catro, e un reenviador UDP tampouco. A disposición habitual de Access Server no porto 443 fai que o daemon OpenVPN TCP recoñeza o tráfico do navegador e o entregue aos servizos web, así que inserir un terminador HTTPS alleo diante non conserva o tratamento de protocolo dese daemon. Compartir o número 443 non fai equivalentes dous deseños.
A terceira é onde aterra o fallo. Un fallo previo á VPN e un fallo da canle de control parécense nun cliente que só di "conectando", pero deixan probas en lugares distintos. Se o formato antigo está en xogo, a inicialización é candidata. Se o formato novo está en xogo, un rexistro de acceso web baleiro é esperable e non proba nada en ningún sentido.
Cando o artefacto é antigo: a inicialización falla primeiro
Lea o erro real do cliente en lugar do seu estado final. Os campos interesantes son o erro HTTPS, a identidade do servidor que o cliente esperaba, o destino ao que foi a petición e se se completou a validación do certificado. Despois contrásteos cos rexistros do servizo web e do proxy no lado do servidor.
Que un navegador chegue á páxina de inicio de sesión non é proba de que a autenticación por API deste cliente tivese éxito. Son peticións distintas, con expectativas de certificado distintas e a miúdo nomes de host distintos. Se o portal se serve correctamente e o cliente segue fallando, a discrepancia está na ruta de inicialización, non no contrasinal do usuario.
Non faga pasar a comparación desactivando a verificación TLS ou relaxando a política de autenticación. Iso converte unha discrepancia de configuración diagnosticable nunha ruta que funciona pero non está verificada, e é exactamente o cambio que converte unha proba temporal nun burato permanente. A documentación de Access Server sobre perfís de conexión describe ambas as xeracións e o fluxo do perfil temporal, e é a referencia que cómpre consultar antes de supor que un proxy ten a culpa.
Cando o artefacto é novo: lea a canle de control
Cun perfil de estilo 2.9, o cliente vai directo ao punto final nativo da VPN. Investigue os puntos finais do perfil, o transporte en uso e o erro da canle de control. Se o cliente nunca emite unha petición HTTP, iso é coherente co deseño e non é un síntoma.
Aquí tamén cambia de forma a cuestión do proxy. Unha descarga HTTPS non pode romper un fluxo só TCP que nunca ve, pero aínda pode romper a descarga que publica o perfil, e un reenviador só TCP non transportará UDP de ningún xeito. Comprobe que transporte pide o perfil antes de concluír que o front-end é irrelevante.
O paso directo TLS para un só fluxo é unha disposición estreita. Non fornece reenvío UDP e non reproduce o comportamento de reenvío de servizos do propio daemon no 443. Se o seu front-end fai unha desas cousas, diga cal, porque o remedio é distinto.
Remedios que se manteñen estreitos
A comprobación menos intrusiva é xerar un perfil novo compatible para unha conta de proba e conectarse polo punto final nativo previsto cos mesmos requisitos de autenticación. Se iso funciona e o perfil antigo conservado non, separou o artefacto do servidor e do proxy nun só paso.
A distribución dun perfil bloqueado ao usuario elimina por completo a dependencia da inicialización heredada, porque non hai ningún intercambio de perfil temporal que poida fallar. Debe emitirse para o usuario previsto, nunca copiarse dun administrador, e cambia que ten autorizado a facer o cliente, así que tráteo como unha decisión de política e non como unha solución alternativa.
Despois arranxe a disposición de publicación para que exista cada ruta necesaria: a ruta web para as descargas e o uso do portal, e a ruta nativa da VPN no transporte que os perfís esperan. Manteña o traballo do proxy nunha soa capa. Un túnel bloqueado ao usuario que funciona demostra que esa ruta funciona; non demostra que toda disposición de proxy admita toda xeración, e un fallo de inicialización antigo non condena o formato máis novo.
- Identifique a xeración do artefacto antes de tocar o proxy.
- Estableza se o fallo ocorre antes do túnel ou dentro del.
- Confirme que remata o front-end: HTTP, fluxo TCP ou UDP.
- Probe un perfil acabado de emitir contra o punto final nativo coa política sen cambios.