SSTP é PPP sobre HTTPS, non unha páxina web no porto 443

SSTP transporta PPP dentro dunha conexión HTTPS, por iso parece tráfico web para calquera cousa que estea no medio. TLS e HTTP establecen a canle exterior, despois as mensaxes de control de SSTP preparan o túnel e PPP achega o comportamento da sesión. Un navegador que carga unha páxina no mesmo enderezo só completou parte da primeira etapa. Tratalo como unha proba de VPN é a forma en que un proxy que funciona recibe a culpa dunha discrepancia de protocolo.

Percorre as catro etapas en orde, e o fallo que ves caerá nunha delas.

Etapa 1: TCP e TLS

O cliente abre unha conexión TCP ao porto 443 e realiza un handshake TLS. A cadea de certificados debe coincidir co nome de host co que se configurou o cliente. Unha discrepancia de nome aquí produce un fallo antes de que se intercambie ningunha mensaxe SSTP, e a especificación de SSTP dá por feito que esta canle HTTPS exterior xa existe. Nada nas etapas posteriores pode compensar un fallo de confianza aquí.

Un servidor web xenérico pode completar esta etapa perfectamente e aínda así fallar na seguinte. O éxito de TLS é unha evidencia sobre o certificado, non sobre o protocolo que hai detrás.

Etapa 2: a petición HTTPS

SSTP fai a súa petición cun método específico, SSTP_DUPLEX_POST, e mantén o intercambio aberto en lugar de devolver un documento. Un servidor ou proxy configurado para peticións de páxina normais pode aceptar a conexión e logo rexeitar o método. Ese rexeitamento é o problema de compatibilidade que a xente adoita describir como que o porto 443 está bloqueado.

Le o código de resposta e o método no rexistro do servidor. Un rexeitamento nesta etapa é un problema distinto dun tempo de espera TCP, e os dous levan a correccións diferentes.

Etapa 3: mensaxes de control

Unha vez aceptada a petición, SSTP intercambia mensaxes de control que negocian e preparan o túnel. Son mensaxes de protocolo dentro do corpo HTTPS, non peticións HTTP, así que un proxy que inspecciona e reescribe corpos pode rompelas mentres deixa intactas as peticións de páxina.

Aquí é onde un dispositivo de inspección profunda gaña a súa reputación. Se as páxinas cargan e a VPN falla, comproba se o corpo se modifica en lugar de se o porto está aberto.

Etapa 4: PPP toma o relevo

PPP achega despois o comportamento da sesión: negociación da ligazón, autenticación e a configuración da capa de rede que segue. A autenticación PPP é independente da comprobación TLS que o cliente xa superou. Un certificado de servidor que o cliente acepta non di nada sobre se as credenciais do usuario son válidas ou se a conta está autorizada.

Un certificado aceptado e un inicio de sesión rexeitado non son contradictorios. Son etapas consecutivas con resultados independentes.

A autenticación ten varios papeis

O cliente valida a identidade do servidor TLS contra o seu almacén de confianza e o nome configurado. Logo PPP autentica o usuario ou a máquina, segundo o despregamento. O servidor pode engadir a súa propia política sobre quen pode conectarse e a que pode chegar. Mantén o nome de host coherente coa identidade do certificado, porque substituílo por un enderezo cru converte unha configuración que funciona nun fallo de comprobación de nome.

Anota que etapa informou do fallo. Certificado, método, mensaxe de control, autenticación PPP, logo rutas: cinco lugares, cinco reparacións.

Que pode e que non pode mostrar unha proba no navegador

Cargar unha páxina no enderezo demostra resolución DNS, alcance TCP e que algo escoita que fala HTTP. Non demostra que o método se acepte, que o intercambio de control sobreviva ou que a autenticación PPP estea configurada. Usa un cliente que implemente SSTP en lugar de converter outro perfil cambiando o porto.

Unha vez levantada a sesión, as rutas, o DNS e o reenvío do lado do servidor seguen decidindo a que pode chegar o usuario. O túnel é un camiño, non unha autorización.