Tempo limite de SSTP ou erro de certificado: como distingui-los

Uma conexão SSTP falha de duas maneiras que parecem iguais da cadeira do usuário, e o reparo de cada uma fica em uma camada diferente. Um tempo limite significa que uma troca necessária nunca terminou; um erro de certificado significa que o material de identidade chegou e foi rejeitado. Tratar o segundo como o primeiro leva a firewalls e senhas que nunca foram o problema. A evidência que os distingue está no log do próprio cliente, se você o ler antes de mudar qualquer coisa.

Duas falhas, duas trocas diferentes

O SSTP carrega um túnel dentro de uma sessão em formato HTTPS, por isso sobrevive em redes que não permitem nada além da 443. O cliente conclui o handshake TLS, envia uma requisição HTTP com um método específico do protocolo, e então o túnel corre dentro desse fluxo. Uma falha em qualquer dessas etapas interrompe a conexão, e apenas as posteriores envolvem credenciais.

Essa ordem é o diagnóstico. Se o handshake TLS nunca se completa, nenhuma credencial foi enviada, então redefinir a senha não pode ajudar. Se o handshake se completa e depois trava, a identidade foi aceita e algo no caminho da requisição a recusou. Se o handshake falha com uma mensagem de validação, o servidor respondeu e o cliente não gostou do que ouviu. Três resultados, três camadas.

A linha do log costuma dizer em qual dos três você está, por isso vale capturá-la antes da primeira mudança.

Um tempo limite significa que uma etapa nunca terminou

Comece pela resolução de nomes e pelo alcance TCP, porque um tempo limite ali parece idêntico a um tempo limite mais adiante. Um verificador de portas que informa a 443 aberta prova apenas que um ouvinte aceitou uma conexão, e nada além disso.

O próximo suspeito é o caminho e não o host. Proxies e firewalls cientes de aplicações às vezes recusam o método de requisição que o SSTP usa, ou descartam um fluxo que permanece aberto por horas, e ambos os comportamentos parecem um tempo limite do lado do cliente. Uma página HTTPS comum servida pelo mesmo host carrega perfeitamente enquanto o método do túnel é recusado, por isso navegar até o endpoint prova tão pouco. Teste a partir de uma rede sem o proxy para separar esses dois casos.

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

Um tempo limite antes de qualquer resposta do par não diz nada sobre a conta, e trocar a senha nesse momento só acrescenta uma variável.

Um erro de certificado significa que a identidade foi rejeitada

Aqui o servidor respondeu de fato, então a rede funciona e a pergunta passa para a identidade. Compare o nome com que o cliente disca com os nomes que o certificado realmente declara, e depois verifique as datas de validade e a cadeia emissora.

Uma CA privada em que o cliente não confia produz a mesma classe de erro que um certificado expirado, e também um relógio adiantado ou atrasado em horas. Discar o endereço bruto cria uma nova divergência, porque um certificado declara nomes e não endereços. Em uma implantação gerenciada, obtenha a configuração de confiança prevista do administrador dela em vez de aceitar uma raiz substituta oferecida por uma página de erro. A validação permanece ligada enquanto você corrige 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

Mantenha o estágio TLS bem-sucedido intacto depois que ele passar, porque desfazê-lo mais tarde esconde qual mudança realmente consertou o túnel.

Onde os dois se confundem

As duas falhas aparecem como uma conexão que não sobe, e ambas chegam depois que o usuário mudou algo não relacionado. É essa coincidência que faz o reparo errado parecer plausível por um tempo.

Dois hábitos os mantêm separados. Capture o log do cliente antes de tocar na configuração, para que o primeiro estado fique preservado. Mude uma camada por tentativa, para que o próximo resultado pertença a uma variável conhecida. Um verificador de portas e um navegador são observações parciais e não a sequência completa, e nenhum deles substitui o relatório do próprio cliente. Nenhum dos hábitos custa nada, e ambos encurtam a investigação.

A questão do certificado e a do alcance estão documentadas separadamente por uma razão.

Teste de novo com o cliente real e depois avance para dentro

Depois que a correção específica estiver no lugar, tente novamente com o cliente SSTP real e o perfil verdadeiro, não com uma aba do navegador.

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

Se a sessão conecta e os recursos ainda falham, o túnel não é mais o suspeito: passe para roteamento, DNS e acesso a serviços. Essa é outra investigação com outras evidências. Manter os estágios TLS e de autenticação que funcionam evita que ela vire uma repetição da primeira. Escreva no tíquete o estágio que falhou, porque senão a próxima pessoa começa de novo pelo topo.