SSTP autentica primer el servidor i després l'usuari

Un client SSTP pot completar TLS i, tot i així, rebutjar l'usuari un segon després. Aquesta seqüència no és un error, és la pila de protocols: primer la seguretat del transport, després l'autenticació de l'usuari. Com que les dues etapes fallen amb missatges diferents, també necessiten correccions diferents. Llegir quina etapa ha produït l'error és la major part del diagnòstic.

Un certificat de confiança demostra el punt final; no diu res sobre el compte.

Què estableix l'apretada de mans TLS

El client valida el certificat presentat pel servidor contra el seu magatzem de confiança, el nom d'amfitrió sol·licitat, la finestra de validesa i qualsevol política addicional que apliqui la plataforma. Això protegeix la connexió amb el punt final previst. No demostra que un compte concret estigui habilitat, no hagi caducat o tingui permís per a l'accés remot. Aquestes són preguntes separades que més tard fa un altre component.

Per això, treure les comprovacions de certificat per arribar a l'indicador d'inici de sessió és la reparació equivocada. Obteniu un indicador d'inici de sessió en una connexió que no podeu verificar. Un error de certificat pertany al nom d'amfitrió, al rellotge, a la cadena o a la configuració de confiança.

Què hi afegeixen SSTP i PPP

SSTP funciona sobre HTTPS i porta PPP a dins, amb el seu propi intercanvi de control al voltant de la connexió. Després PPP executa les seves fases d'enllaç i autenticació, i el mètode d'autenticació depèn de la política del servidor i de la capacitat del client. PAP, CHAP, MS-CHAPv2 i EAP són totes opcions d'autenticació PPP amb propietats molt diferents. La comprovació d'usuari de la VPN és aquesta fase PPP, no la capa TLS que hi ha a sota.

Per tant, un rebuig d'usuari pot significar credencials, una restricció del compte o un desajust de mètode.

La raó del costat del servidor és molt més útil que restablir cada secret del perfil. Un esdeveniment de compte desactivat i un error de negociació de mètode semblen iguals al client i no tenen res en comú al servidor.

Feu correspondre l'error amb l'etapa

Comproveu si la connexió arriba a TLS, després a l'intercanvi HTTP de SSTP i després a la fase PPP. Mantingueu les marques de temps dels registres alineades entre reintents perquè un error anterior no es confongui amb un èxit posterior. Un client que registra dos intents en una finestra, d'altra manera, semblarà que ha fallat a l'última etapa on ha arribat. Llegiu el primer error rellevant, no l'última línia.

La mateixa alineació importa al costat del servidor, on el registre d'autenticació i el registre de transport sovint són fitxers separats amb rellotges separats. Dos minuts de desviació n'hi ha prou per fer que una causa òbvia sembli impossible.

Després de l'inici de sessió, l'autorització continua sent separada

Un inici de sessió correcte no atorga tots els recursos privats. Les rutes determinen què és abastable, el DNS determina què es resol, i cada servei continua aplicant els seus propis permisos. Una sessió que mostra connectat és una afirmació sobre el túnel, no sobre el recurs compartit de fitxers. Quan un usuari es pot connectar i no pot arribar a un amfitrió, la fase del túnel ja ha acabat.

És la mateixa estratificació que va mostrar l'apretada de mans, un nivell més amunt.

Manteniu la recuperació del compte dins del procés suportat per l'operador en lloc de canviar la configuració del transport com a resposta a una denegació explícita de l'usuari. Canviar el transport per arreglar un compte desactivat és el tipus de reparació que sembla funcionar quan el compte es torna a habilitar per un motiu no relacionat.