O porto 443 responde, SSTP segue fallando: que etapa rompeu?

Completar un handshake TCP ao porto 443 mentres o túnel nunca se constrúe demostra unha cousa, e é unha cousa pequena. Algo está escoitando e disposto a aceptar unha conexión nesa dirección. Non identifica o servizo, o certificado que presentará nin que ocorre despois dos primeiros bytes.

Entre ese handshake e un túnel funcional hai catro etapas, e cada unha produce un erro distinto.

Un porto aberto describe só unha capa

Aceptar unha conexión TCP significa que un proceso posúe o socket e que a ruta permite o handshake. Non di nada sobre se ese proceso é un servidor SSTP, se ten un certificado válido para o nome do seu perfil ou se autorizará a súa conta. Un servidor web na mesma dirección responde perfectamente ao handshake e despois responde á súa solicitude SSTP cun erro HTTP. Todo o que está por riba dese handshake queda sen probar.

Trate a proba do porto como o filtro máis barato posible e non como un veredicto. O seu valor é que elimina unha categoría enteira de fallos, non que confirme todo o que está por riba.

Confundir as dúas cousas é a razón pola que a xente reinstala clientes tras unha proba que nunca examinou o problema real do cliente.

Separe as catro etapas con probas

As etapas son a accesibilidade do transporte, a validación TLS, o intercambio SSTP sobre HTTPS e a autenticación PPP dentro do túnel. Unha ruta que supera a primeira e falla na cuarta necesita unha corrección de credenciais; unha que falla na segunda necesita unha corrección de certificado ou de nome. Esas reparacións non teñen nada en común, e escoller a equivocada desperdicia a interrupción.

nc -vz vpn.example.net 443
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
curl -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/

O terceiro comando merece lerse con atención. Un 200 dunha páxina web corrente dille que hai un servizo web; non lle di que a solicitude SSTP vaia entenderse. Un 404 da mesma dirección é igual de pouco informativo sobre a VPN. Só o rexistro do cliente lle di a cal das catro etapas chegou.

Fíxese en que nome usou cada comando. O certificado selecciónase polo nome que envía, así que unha discrepancia entre o perfil e a proba é unha discrepancia que introduciu vostede. Escribir ese nome xunto ao resultado evita a confusión máis adiante.

Lea o éxito parcial na dirección correcta

Un intermediario pode permitir a navegación corrente e rexeitar o intercambio posterior, e por iso un proxy que funciona para sitios web aínda pode fallar para un túnel. O mesmo patrón aparece cando un certificado é válido para un nome de navegador pero non para o nome configurado no perfil: o navegador queda satisfeito e o cliente non, e ambos teñen razón sobre o que comprobaron.

Manteña activada a validación do servidor mentres diagnostica isto. Desactivala converte unha discrepancia de certificado nun handshake exitoso e oculta a única proba que explicaría o fallo.

Se o mesmo perfil funciona desde outra rede, a diferenza depende da ruta. Iso reduce a busca a intermediarios sen dicir cal, e segue sendo un paso útil adiante. Rexistre a rede que utilizou, porque a comparación non vale nada sen ela.

Logo probe a aplicación, non só a sesión

Unha vez que existe unha sesión, verifique a ruta prevista, a resolución de nomes e o permiso de servizo desde o cliente que os necesita. Un túnel conectado aínda pode ter un reenvío ausente no lado remoto ou unha ruta de retorno que nunca existiu, e eses fallos parecen exactamente un problema de aplicación para a persoa que espera.

Manteña cada conclusión ligada á etapa que a produciu. Chamar porto aberto a unha VPN funcional é como unha comprobación de certificado de cinco minutos se converte nun día de reinstalar software.