Tempo de espera de SSTP ou erro de certificado: como distinguilos

Unha conexión SSTP falla de dous xeitos que desde a cadeira do usuario parecen iguais, e a reparación de cada un está nunha capa distinta. Un tempo de espera significa que un intercambio necesario nunca rematou; un erro de certificado significa que chegou material de identidade e rexeitouse. Tratar o segundo como o primeiro lévao a cortalumes e contrasinais que nunca foron o problema. A evidencia que os distingue está no rexistro do propio cliente, se o le antes de cambiar algo.

Dous fallos, dous intercambios diferentes

SSTP leva un túnel dentro dunha sesión con forma de HTTPS, por iso sobrevive en redes que non permiten nada máis ca o 443. O cliente completa un handshake TLS, envía unha solicitude HTTP cun método específico do protocolo, e despois o túnel corre dentro dese fluxo. Un fallo en calquera deses pasos detén a conexión, e só os últimos implican credenciais.

Esa orde é o diagnóstico. Se o handshake TLS nunca se completa, non se enviou ningunha credencial, así que restablecer o contrasinal non pode axudar. Se o handshake se completa e despois atasca, aceptouse a identidade e algo no camiño da solicitude rexeitouna. Se o handshake falla cunha mensaxe de validación, o servidor respondeu e ao cliente non lle gustou o que oíu. Tres resultados, tres capas.

A liña do rexistro adoita indicar en cal dos tres está, por iso paga a pena capturala antes do primeiro cambio.

Un tempo de espera significa que unha etapa nunca rematou

Comece pola resolución de nomes e a accesibilidade TCP, porque un tempo de espera alí parece idéntico a un tempo de espera máis adiante. Un comprobador de portos que informa que o 443 está aberto só demostra que un oínte aceptou unha conexión, e nada máis alá.

O seguinte sospeitoso é o camiño e non o host. Os proxies e os cortalumes conscientes de aplicacións ás veces rexeitan o método de solicitude que usa SSTP, ou descartan un fluxo que permanece aberto durante horas, e ambos os comportamentos parecen un tempo de espera desde o cliente. Unha páxina HTTPS xenérica servida polo mesmo host cárgase perfectamente mentres se rexeita o método do túnel, por iso navegar ao extremo demostra tan pouco. Proba desde unha rede sen o proxy para separar eses dous casos.

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

Un tempo de espera antes de calquera resposta do par non di nada sobre a conta, e cambiar o contrasinal nese momento só engade unha variable.

Un erro de certificado significa que a identidade foi rexeitada

Aquí o servidor si respondeu, así que a rede funciona e a pregunta trasládase á identidade. Compare o nome co que marca o cliente cos nomes que o certificado afirma realmente, e despois revise as datas de validez e a cadea emisora.

Unha CA privada na que o cliente non confía produce a mesma clase de erro que un certificado caducado, e tamén un reloxo que vai horas mal. Marcar o enderezo en bruto crea unha nova discordancia, porque un certificado afirma nomes e non enderezos. Nunha implantación xestionada, obteña a configuración de confianza prevista do seu administrador en lugar de aceptar unha raíz substituta que ofreza unha páxina de erro. A validación segue activa mentres arranxa a 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

Manteña intacta a etapa TLS exitosa unha vez que pase, porque desfacela despois oculta que cambio arranxou realmente o túnel.

Onde se confunden as dúas

Ambos os fallos preséntanse como unha conexión que non levanta, e ambos chegan despois de que o usuario cambiase algo non relacionado. Esa coincidencia é o que fai que a reparación equivocada pareza plausible durante un tempo.

Dous hábitos os manteñen separados. Capture o rexistro do cliente antes de tocar a configuración, para que se conserve o primeiro estado. Cambie unha capa por intento, para que o seguinte resultado pertenza a unha variable coñecida. Un comprobador de portos e un navegador son observacións parciais e non a secuencia completa, e ningún substitúe o informe do propio cliente. Ningún dos hábitos custa nada, e ambos acurtan a investigación.

A cuestión do certificado e a da accesibilidade están documentadas por separado por unha razón.

Volve probar co cliente real e despois avanza cara a dentro

Unha vez que a corrección concreta está no seu sitio, ténteo de novo co cliente SSTP real e o perfil auténtico, non cunha lapela do navegador.

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

Se a sesión conecta e os recursos seguen fallando, o túnel xa non é o sospeitoso: pase ao encamiñamento, o DNS e o acceso a servizos. Eso é outra investigación con outras evidencias. Conservar as etapas TLS e de autenticación que funcionan evita que se converta nunha repetición da primeira. Escriba no ticket a etapa que fallou, porque doutro xeito a seguinte persoa empezará outra vez polo alto.