SSTP autentica primero al servidor y después al usuario

Un cliente SSTP puede completar TLS y, aun así, rechazar al usuario un segundo después. Esa secuencia no es un error, es la pila de protocolos: primero la seguridad del transporte, después la autenticación del usuario. Como las dos etapas fallan con mensajes distintos, también necesitan correcciones distintas. Leer qué etapa produjo el error es la mayor parte del diagnóstico.

Un certificado de confianza demuestra el extremo; no dice nada sobre la cuenta.

Qué establece el apretón de manos TLS

El cliente valida el certificado presentado por el servidor contra su almacén de confianza, el nombre de host solicitado, la ventana de validez y cualquier política adicional que aplique la plataforma. Eso protege la conexión con el extremo previsto. No demuestra que una cuenta concreta esté habilitada, no haya caducado o tenga permiso para el acceso remoto. Esas son preguntas separadas que más tarde plantea otro componente.

Por eso, quitar las comprobaciones de certificado para llegar al aviso de inicio de sesión es la reparación equivocada. Obtiene un aviso de inicio de sesión en una conexión que no puede verificar. Un error de certificado pertenece al nombre de host, al reloj, a la cadena o a la configuración de confianza.

Qué añaden SSTP y PPP por encima

SSTP funciona sobre HTTPS y lleva PPP dentro, con su propio intercambio de control alrededor de la conexión. Después PPP ejecuta sus fases de enlace y autenticación, y el método de autenticación depende de la política del servidor y de la capacidad del cliente. PAP, CHAP, MS-CHAPv2 y EAP son todas opciones de autenticación PPP con propiedades muy distintas. La comprobación de usuario de la VPN es esa fase PPP, no la capa TLS que hay debajo.

Por tanto, un rechazo de usuario puede significar credenciales, una restricción de la cuenta o un desajuste de método.

La razón del lado del servidor es mucho más útil que restablecer cada secreto del perfil. Un evento de cuenta deshabilitada y un fallo de negociación de método se parecen en el cliente y no tienen nada en común en el servidor.

Asigne el error a la etapa

Compruebe si la conexión llega a TLS, luego al intercambio HTTP de SSTP y luego a la fase PPP. Mantenga las marcas de tiempo de los registros alineadas entre reintentos para que un fallo anterior no se confunda con un éxito posterior. Un cliente que registra dos intentos en una ventana, de lo contrario, parecerá que falló en la última etapa a la que llegó. Lea el primer error relevante, no la última línea.

La misma alineación importa en el lado del servidor, donde el registro de autenticación y el registro de transporte suelen ser archivos separados con relojes separados. Dos minutos de desfase bastan para que una causa obvia parezca imposible.

Tras el inicio de sesión, la autorización sigue separada

Un inicio de sesión correcto no concede todos los recursos privados. Las rutas determinan qué es alcanzable, el DNS determina qué se resuelve y cada servicio sigue aplicando sus propios permisos. Una sesión que muestra conectado es una afirmación sobre el túnel, no sobre el recurso compartido de archivos. Cuando un usuario puede conectarse y no puede llegar a un host, la fase del túnel ya ha terminado.

Es la misma estratificación que mostró el apretón de manos, un nivel más arriba.

Mantenga la recuperación de la cuenta dentro del proceso admitido por el operador en lugar de cambiar la configuración de transporte como respuesta a una denegación explícita del usuario. Cambiar el transporte para arreglar una cuenta deshabilitada es el tipo de reparación que parece funcionar cuando la cuenta se vuelve a habilitar por un motivo no relacionado.