SSTP falla onde o HTTPS do navegador ten éxito: por que
SSTP execútase dentro de TLS no porto 443, pero non é unha petición web. Proba TCP, a identidade TLS, o intercambio SSTP e a autenticación PPP como etapas separadas.
O navegador abre o nome de host da VPN por HTTPS sen queixarse, e o cliente SSTP segue negándose a conectarse. Nada desa parella é contraditorio. SSTP usa TLS como transporte exterior e despois executa a súa propia petición e a carga PPP dentro desa conexión, así que unha carga de páxina correcta demostra só unha cousa moi concreta: o host responde a un GET no porto 443. O cliente fai outra pregunta, e o servidor pode respondela mal.
A páxina carga e o túnel non
A xente recorre á proba do navegador porque é rápida, e despois toma o resultado como proba de que o servidor é accesible e está configurado. É unha proba sobre un GET ao camiño que abrise a barra de enderezos, nada máis. A conversa VPN comeza tras o mesmo handshake TLS, pero envía un método e un camiño que unha páxina web nunca usa. Por iso unha resposta 200 para o navegador non di nada sobre se existe o punto final SSTP.
Separe as dúas observacións e a busca acúrtase. O transporte e a cadea de certificados funcionan, e algo no intercambio de protocolo por riba non funciona. É unha investigación distinta da dun porto roto ou un certificado caducado, e necesita probas distintas.
Que envía realmente o cliente SSTP
O cliente envía unha petición HTTP co método SSTP_DUPLEX_POST ao camiño /sra_{GUID}/, e despois mantén aberto o corpo da conexión como un fluxo bidireccional que transporta tramas PPP. Un servidor conforme responde HTTP/1.1 200 e deixa de comportarse como un servidor web. Calquera outra cousa é unha sinatura: 405 ou 404 significa que o punto final non está, 301 ou 302 significa que algo redirixe a petición, e un FIN inmediato significa que un proxy ou servidor pechou o fluxo.
Por iso o obxectivo debe ser un servidor SSTP e non un servidor web cun certificado TLS atafegado. O método, o camiño e o corpo de longa duración son requisitos do protocolo, así que un proxy inverso non pode engadilos só coa configuración. Un proxy que reenvía HTTPS normal á perfección pode rexeitar un método que non recoñece.
Onde un proxy ou servidor web rompe o fluxo
Un intermediario inspecciona a liña de petición HTTP antes de reenviar nada, e un método personalizado cun camiño inusual pode incumprir as súas regras. Algúns dispositivos serven unha páxina normal mentres rexeitan ou interrompen o túnel, así que o cliente informa dunha conexión que comeza e logo morre en lugar dun rexeitamento limpo. Outros aceptan a petición e despois aplican un tempo de espera de corpo ou de inactividade que os keepalives PPP non sobreviven. Ambos se ven igual desde o lado do cliente, por iso a etapa que fallou importa máis que o texto do erro.
Compartir o porto 443 entre un sitio web e SSTP é unha decisión de encamiñamento, non unha promesa de que cada salto trate as dúas conversas igual. Se hai un balanceador de carga, unha devasa ou un terminador TLS no camiño, engádeo á lista de sospeitosos antes de tocar a configuración da VPN.
Proba as etapas por separado
Executa as comprobacións en orde e detente no primeiro fallo, porque cada etapa descarta unha capa distinta. A sonda TLS de abaixo separa a identidade do certificado de todo o que fai SSTP. Substitúe o nome de host polo teu punto final e le o asunto e a cadea que imprime.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comDespois asigna as probas restantes ás etapas en lugar de adiviñar a partir do erro do cliente. A táboa de abaixo é a lista de comprobación para citar no ticket, coa sinatura que separa un fallo do seguinte.
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
Rexistra no ticket a última etapa que tivo éxito en lugar de escribir "non se pode conectar". A especificación MS-SSTP documenta a petición e o intercambio PPP que seguen o handshake TLS, e é a referencia de por que unha proba no navegador non pode substituír ningunha das dúas.
Primeiro a identidade, logo PPP
A identidade TLS e a autenticación PPP son secuenciais, non alternativas, e confundilas leva a xente á configuración de servidor equivocada. O cliente valida primeiro o certificado do servidor e o seu propósito previsto, logo PPP negocia o seu propio estado e autentica o usuario cun método de desafío-resposta ou EAP. Un problema de certificado produce un erro distinto ao dun contrasinal rexeitado, e ningún dos dous erros describe a etapa que cobre o outro.
Cambiar o nome de host por un enderezo, ou saltar o aviso de certificado, elimina a comprobación que tería identificado a etapa fallida en lugar de corrixila. Mantén o aviso e léoo. Tampouco restablezas un contrasinal PPP cando o intercambio HTTP nunca chegou ao comportamento SSTP, porque a credencial nunca se pediu.