El perfil bloquejat al servidor falla darrere d'un proxy TLS: quina generació?
L'Access Server 2.8 i 2.9 construeixen els perfils bloquejats al servidor de maneres diferents. Decidiu quin camí trenca el vostre proxy abans de canviar el front-end.
Un usuari es pot connectar i un altre no, a través del mateix portal, el mateix dia. Tots dos tenen perfils bloquejats al servidor, tots dos són a la mateixa compilació de l'Access Server, i l'única diferència és quan es va generar el seu perfil. Aquest és el patró que val la pena reconèixer, perquè "bloquejat al servidor" designa una política i no una seqüència de connexió. L'Access Server ha lliurat dues generacions d'aquest artefacte, i un proxy invers TLS només és davant d'un dels seus camins. Tres condicions decideixen en quina branca sou.
Dues generacions, dues seqüències de connexió
En el disseny més antic, vigent fins a la 2.8, el fitxer importat és un pseudo-perfil. L'OpenVPN Connect l'utilitza per autenticar-se contra l'API web de l'Access Server per HTTPS, rep un perfil temporal bloquejat a l'usuari i un testimoni de sessió, i només després estableix la VPN. Dos transports funcionen en seqüència, i el primer és una petició web ordinària.
El format introduït amb la 2.9 no fa aquesta inicialització per connexió. És un perfil natiu que poden utilitzar els OpenVPN clients compatibles, no només l'OpenVPN Connect. Descarregar-lo o importar-lo per URL encara pot implicar HTTPS — això és un pas de publicació, no una obtenció d'un perfil temporal per connexió.
| 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 |
Una actualització no reescriu necessàriament els perfils ja emesos, així que una versió actual del servidor encara pot estar lliurant l'artefacte antic. La compilació del servidor us diu què és possible, no què ha importat aquest usuari.
Tres condicions que trien la vostra branca
La primera condició és la generació de l'artefacte. Demaneu el fitxer, mireu com es va produir i anoteu la versió del client que el va importar. Si no podeu establir la generació a partir del fitxer, un perfil nou emès per a un compte de prova us dirà què produeix el servidor avui, que és una informació diferent de la que té l'usuari que falla.
La segona és què acaba realment el vostre front-end. Un proxy invers HTTP de capa set que descarrega el TLS no és el mateix objecte que un reenviador TCP de capa quatre, i un reenviador UDP tampoc ho és. La disposició habitual de l'Access Server al port 443 fa que el dimoni OpenVPN TCP reconegui el trànsit del navegador i el lliuri als serveis web, així que inserir un terminador HTTPS aliè al davant no preserva el tractament de protocol d'aquest dimoni. Compartir el número 443 no fa equivalents dos dissenys.
La tercera és on recau la fallada. Una fallada abans de la VPN i una fallada del canal de control semblen iguals en un client que només diu "connectant", però deixen proves en llocs diferents. Si el format antic està en joc, la inicialització és una candidata. Si el format nou està en joc, un registre d'accés web buit és esperable i no prova res en cap sentit.
Quan l'artefacte és antic: la inicialització falla primer
Llegiu l'error real del client en lloc del seu estat final. Els camps interessants són l'error HTTPS, la identitat del servidor que el client esperava, la destinació a la qual va anar la petició i si la validació del certificat es va completar. Després compareu-los amb els registres del servei web i del proxy al costat del servidor.
Que un navegador arribi a la pàgina d'inici de sessió no és prova que l'autenticació per API d'aquest client hagi reeixit. Són peticions diferents, amb expectatives de certificat diferents i sovint noms d'amfitrió diferents. Si el portal se serveix correctament i el client encara falla, el desacord és al camí d'inicialització, no a la contrasenya de l'usuari.
No feu passar la comparació desactivant la verificació TLS o relaxant la política d'autenticació. Això converteix una discrepància de configuració diagnosticable en un camí que funciona però no està verificat, i és exactament el canvi que converteix una prova temporal en un forat permanent. La documentació de l'Access Server sobre perfils de connexió descriu les dues generacions i el flux del perfil temporal, i és la referència que cal consultar abans de suposar que un proxy té la culpa.
Quan l'artefacte és nou: llegiu el canal de control
Amb un perfil d'estil 2.9, el client va directament al punt final natiu de la VPN. Investigueu els punts finals del perfil, el transport en ús i l'error del canal de control. Si el client no emet mai una petició HTTP, això és coherent amb el disseny i no és un símptoma.
Aquí també canvia de forma la qüestió del proxy. Una descàrrega HTTPS no pot trencar un flux només TCP que no veu mai, però encara pot trencar la descàrrega que publica el perfil, i un reenviador només TCP no transportarà UDP de cap manera. Comproveu quin transport demana el perfil abans de concloure que el front-end és irrellevant.
El pas directe TLS per a un sol flux és una disposició estreta. No ofereix reenviament UDP i no reprodueix el comportament de reenviament de serveis del propi dimoni al 443. Si el vostre front-end fa una d'aquestes coses, digueu quina, perquè el remei és diferent.
Remedis que es mantenen estrets
La comprovació menys intrusiva és generar un perfil nou compatible per a un compte de prova i connectar-se pel punt final natiu previst amb els mateixos requisits d'autenticació. Si això funciona i el perfil antic conservat no, heu separat l'artefacte del servidor i del proxy en un sol pas.
La distribució d'un perfil bloquejat a l'usuari elimina completament la dependència de la inicialització heretada, perquè no hi ha cap intercanvi de perfil temporal que pugui fallar. S'ha d'emetre per a l'usuari previst, mai copiar d'un administrador, i canvia què té autoritzat a fer el client, així que tracteu-ho com una decisió de política i no com una solució alternativa.
Després arregleu la disposició de publicació perquè existeixi cada camí necessari: el camí web per a les descàrregues i l'ús del portal, i el camí natiu de la VPN en el transport que els perfils esperen. Manteniu la feina del proxy en una sola capa. Un túnel bloquejat a l'usuari que funciona demostra que aquest camí funciona; no demostra que cada disposició de proxy admeti cada generació, i una fallada d'inicialització antiga no condemna el format més nou.
- Identifiqueu la generació de l'artefacte abans de tocar el proxy.
- Establiu si la fallada passa abans del túnel o dins seu.
- Confirmeu què acaba el front-end: HTTP, flux TCP o UDP.
- Proveu un perfil acabat d'emetre contra el punt final natiu amb la política sense canvis.