SSTP autentica primeiro o servidor e despois o usuario

Un cliente SSTP pode completar TLS e, aínda así, rexeitar o usuario un segundo despois. Esa secuencia non é un erro, é a pila de protocolos: primeiro a seguridade do transporte, despois a autenticación do usuario. Como as dúas etapas fallan con mensaxes distintos, tamén necesitan correccións distintas. Ler que etapa produciu o erro é a maior parte do diagnóstico.

Un certificado de confianza demostra o extremo; non di nada sobre a conta.

Que establece o aperto de mans TLS

O cliente valida o certificado presentado polo servidor contra o seu almacén de confianza, o nome de host solicitado, a xanela de validez e calquera política adicional que aplique a plataforma. Iso protexe a conexión co extremo previsto. Non demostra que unha conta concreta estea habilitada, non caducase ou teña permiso para o acceso remoto. Eses son preguntas separadas que máis tarde formula outro compoñente.

Por iso, quitar as comprobacións de certificado para chegar ao aviso de inicio de sesión é a reparación equivocada. Obtén un aviso de inicio de sesión nunha conexión que non pode verificar. Un erro de certificado pertence ao nome de host, ao reloxo, á cadea ou á configuración de confianza.

Que engaden SSTP e PPP por riba

SSTP funciona sobre HTTPS e leva PPP dentro, co seu propio intercambio de control arredor da conexión. Despois PPP executa as súas fases de enlace e autenticación, e o método de autenticación depende da política do servidor e da capacidade do cliente. PAP, CHAP, MS-CHAPv2 e EAP son todas opcións de autenticación PPP con propiedades moi distintas. A comprobación de usuario da VPN é esa fase PPP, non a capa TLS que hai debaixo.

Por tanto, un rexeitamento de usuario pode significar credenciais, unha restrición da conta ou un desaxuste de método.

A razón do lado do servidor é moito máis útil que restablecer cada segredo do perfil. Un evento de conta deshabilitada e un fallo de negociación de método parécense no cliente e non teñen nada en común no servidor.

Asigne o erro á etapa

Comprobe se a conexión chega a TLS, despois ao intercambio HTTP de SSTP e despois á fase PPP. Manteña as marcas de tempo dos rexistros aliñadas entre reintentos para que un fallo anterior non se confunda cun éxito posterior. Un cliente que rexistra dous intentos nunha xanela, doutro xeito, parecerá que fallou na última etapa á que chegou. Lea o primeiro erro relevante, non a última liña.

O mesmo aliñamento importa no lado do servidor, onde o rexistro de autenticación e o rexistro de transporte adoitan ser ficheiros separados con reloxos separados. Dous minutos de desfase abondan para que unha causa obvia pareza imposible.

Despois do inicio de sesión, a autorización segue separada

Un inicio de sesión correcto non concede todos os recursos privados. As rutas determinan que é alcanzable, o DNS determina que se resolve e cada servizo segue aplicando os seus propios permisos. Unha sesión que mostra conectado é unha afirmación sobre o túnel, non sobre o recurso compartido de ficheiros. Cando un usuario pode conectarse e non pode chegar a un host, a fase do túnel xa rematou.

É a mesma estratificación que mostrou o aperto de mans, un nivel máis arriba.

Manteña a recuperación da conta dentro do proceso admitido polo operador en lugar de cambiar a configuración de transporte como resposta a unha denegación explícita do usuario. Cambiar o transporte para arranxar unha conta deshabilitada é o tipo de reparación que parece funcionar cando a conta se volve habilitar por un motivo non relacionado.