Tiempo de espera de SSTP o error de certificado: cómo distinguirlos

Una conexión SSTP falla de dos maneras que desde la silla del usuario se ven iguales, y la reparación de cada una está en una capa distinta. Un tiempo de espera significa que un intercambio necesario nunca terminó; un error de certificado significa que llegó material de identidad y se rechazó. Tratar el segundo como el primero le envía a cortafuegos y contraseñas que nunca fueron el problema. La evidencia que los distingue está en el registro del propio cliente, si lo lee antes de cambiar algo.

Dos fallos, dos intercambios diferentes

SSTP lleva un túnel dentro de una sesión con forma de HTTPS, por eso sobrevive en redes que no permiten nada más que el 443. El cliente completa un handshake TLS, envía una petición HTTP con un método específico del protocolo, y luego el túnel corre dentro de ese flujo. Un fallo en cualquiera de esos pasos detiene la conexión, y solo los últimos implican credenciales.

Ese orden es el diagnóstico. Si el handshake TLS nunca se completa, no se envió ninguna credencial, así que restablecer la contraseña no puede ayudar. Si el handshake se completa y luego se atasca, la identidad se aceptó y algo en la ruta de la petición la rechazó. Si el handshake falla con un mensaje de validación, el servidor respondió y al cliente no le gustó lo que oyó. Tres resultados, tres capas.

La línea del registro suele indicar en cuál de los tres está, por eso vale la pena capturarla antes del primer cambio.

Un tiempo de espera significa que una etapa nunca terminó

Empiece por la resolución de nombres y el alcance TCP, porque un tiempo de espera ahí se ve idéntico a un tiempo de espera más adelante. Un comprobador de puertos que informa que el 443 está abierto solo demuestra que un oyente aceptó una conexión, y nada más allá.

El siguiente sospechoso es la ruta y no el host. Los proxys y los cortafuegos conscientes de aplicaciones a veces rechazan el método de petición que usa SSTP, o descartan un flujo que permanece abierto durante horas, y ambos comportamientos parecen un tiempo de espera desde el cliente. Una página HTTPS genérica servida por el mismo host se carga perfectamente mientras se rechaza el método del túnel, por eso navegar al extremo demuestra tan poco. Pruebe desde una red sin el proxy para separar esos dos casos.

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

Un tiempo de espera antes de cualquier respuesta del par no dice nada sobre la cuenta, y cambiar la contraseña en ese momento solo añade una variable.

Un error de certificado significa que la identidad se rechazó

Aquí el servidor sí respondió, así que la red funciona y la pregunta pasa a la identidad. Compare el nombre con el que marca el cliente con los nombres que el certificado afirma realmente, y luego revise las fechas de validez y la cadena emisora.

Una CA privada en la que el cliente no confía produce la misma clase de error que un certificado caducado, y también un reloj que va varias horas mal. Marcar la dirección en crudo crea una nueva discrepancia, porque un certificado afirma nombres y no direcciones. En una implementación gestionada, obtenga la configuración de confianza prevista de su administrador en lugar de aceptar una raíz sustituta que ofrezca una página de error. La validación sigue activa mientras arregla 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

Mantenga intacta la etapa TLS exitosa una vez que pase, porque deshacerla después oculta qué cambio arregló realmente el túnel.

Dónde se confunden las dos

Ambos fallos se presentan como una conexión que no levanta, y ambos llegan después de que el usuario haya cambiado algo no relacionado. Esa coincidencia es lo que hace que la reparación equivocada parezca plausible durante un tiempo.

Dos hábitos los mantienen separados. Capture el registro del cliente antes de tocar la configuración, para que se conserve el primer estado. Cambie una capa por intento, para que el siguiente resultado pertenezca a una variable conocida. Un comprobador de puertos y un navegador son observaciones parciales y no la secuencia completa, y ninguno sustituye al informe del propio cliente. Ninguno de los hábitos cuesta nada, y ambos acortan la investigación.

La cuestión del certificado y la del alcance están documentadas por separado por una razón.

Vuelva a probar con el cliente real y luego avance hacia dentro

Una vez que la corrección concreta está en su sitio, reintente con el cliente SSTP real y el perfil auténtico, no con una pestaña del navegador.

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

Si la sesión conecta y los recursos siguen fallando, el túnel ya no es el sospechoso: pase al enrutamiento, el DNS y el acceso a servicios. Esa es otra investigación con otras evidencias. Conservar las etapas TLS y de autenticación que funcionan evita que se convierta en una repetición de la primera. Escriba en el tique la etapa que falló, porque de lo contrario la siguiente persona empezará otra vez por arriba.