Temps d’espera de SSTP o error de certificat: com distingir-los

SSTP falla de dues maneres que des de la cadira de l’usuari semblen iguals, i la reparació de cadascuna és en una capa diferent. Un temps d’espera vol dir que un intercanvi necessari no es va acabar mai; un error de certificat vol dir que el material d’identitat va arribar i es va rebutjar. Tractar el segon com el primer us envia a tallafocs i contrasenyes que mai no eren el problema. L’evidència que els distingeix és al registre del propi client, si el llegiu abans de canviar res.

Dos fracassos, dos intercanvis diferents

SSTP porta un túnel dins d’una sessió amb forma d’HTTPS, i per això sobreviu en xarxes que no permeten res més que el 443. El client completa un handshake TLS, envia una petició HTTP amb un mètode específic del protocol, i després el túnel corre dins d’aquest flux. Un fracàs en qualsevol d’aquests passos atura la connexió, i només els darrers impliquen credencials.

Aquest ordre és el diagnòstic. Si el handshake TLS no es completa mai, no s’ha enviat cap credencial, així que restablir la contrasenya no pot ajudar. Si el handshake es completa i després s’encalla, la identitat s’ha acceptat i alguna cosa del camí de la petició l’ha rebutjada. Si el handshake falla amb un missatge de validació, el servidor ha respost i al client no li ha agradat el que ha sentit. Tres resultats, tres capes.

La línia del registre normalment diu en quin dels tres sou, i per això val la pena capturar-la abans del primer canvi.

Un temps d’espera vol dir que una etapa no es va acabar mai

Comenceu per la resolució de noms i l’abastabilitat TCP, perquè un temps d’espera allà sembla idèntic a un temps d’espera més endavant. Un comprovador de ports que informa que el 443 és obert només demostra que un oient ha acceptat una connexió, i res més enllà.

El següent sospitós és el camí i no l’amfitrió. Els proxys i els tallafocs conscients d’aplicacions de vegades rebutgen el mètode de petició que fa servir SSTP, o deixen caure un flux que roman obert durant hores, i tots dos comportaments semblen un temps d’espera des del client. Una pàgina HTTPS genèrica servida pel mateix amfitrió es carrega perfectament mentre el mètode del túnel es rebutja, i per això navegar al punt final demostra tan poc. Proveu-ho des d’una xarxa sense el proxy per separar aquests dos casos.

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

Un temps d’espera abans de cap resposta de l’altre extrem no diu res sobre el compte, i canviar la contrasenya en aquell moment només afegeix una variable.

Un error de certificat vol dir que la identitat es va rebutjar

Aquí el servidor sí que ha respost, així que la xarxa funciona i la pregunta es trasllada a la identitat. Compareu el nom amb què el client marca amb els noms que el certificat afirma realment, i després reviseu les dates de validesa i la cadena emissora.

Una CA privada en què el client no confia produeix la mateixa classe d’error que un certificat caducat, i també un rellotge que va hores erròniament. Marcar l’adreça en cru crea una discordança nova, perquè un certificat afirma noms i no adreces. En un desplegament gestionat, obteniu la configuració de confiança prevista del seu administrador en lloc d’acceptar una arrel substituta que ofereixi una pàgina d’error. La validació es manté activa mentre arregleu la causa.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

Mantingueu intacta l’etapa TLS reeixida un cop passi, perquè desfer-la després amaga quin canvi va arreglar realment el túnel.

On es confonen les dues

Tots dos fracassos es presenten com una connexió que no s’aixeca, i tots dos arriben després que l’usuari hagi canviat alguna cosa no relacionada. Aquesta coincidència és el que fa que la reparació equivocada sembli plausible durant un temps.

Dos hàbits els mantenen separats. Captureu el registre del client abans de tocar la configuració, perquè es conservi el primer estat. Canvieu una capa per intent, perquè el resultat següent pertanyi a una variable coneguda. Un comprovador de ports i un navegador són observacions parcials i no la seqüència completa, i cap dels dos substitueix l’informe del propi client. Cap dels dos hàbits no costa res, i tots dos escurcen la investigació.

La qüestió del certificat i la de l’abastabilitat estan documentades per separat per una raó.

Torneu a provar amb el client real i després aneu cap endins

Un cop la correcció concreta és al lloc, torneu-ho a provar amb el client SSTP real i el perfil autèntic, no amb una pestanya del navegador.

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

Si la sessió es connecta i els recursos encara fallen, el túnel ja no és el sospitós: passeu a l’encaminament, el DNS i l’accés als serveis. Aquesta és una altra investigació amb altres evidències. Conservar les etapes TLS i d’autenticació que funcionen evita que es converteixi en una repetició de la primera. Escriviu al tiquet l’etapa que va fallar, perquè altrament la persona següent tornarà a començar per dalt.