SSTP transporta PPP dentro de una conexión HTTPS, por eso parece tráfico web para cualquier cosa que esté en medio. TLS y HTTP establecen el canal exterior, después los mensajes de control de SSTP preparan el túnel y PPP aporta el comportamiento de la sesión. Un navegador que carga una página en la misma dirección solo ha completado parte de la primera etapa. Tratarlo como una prueba de VPN es la forma en que un proxy que funciona recibe la culpa de una discrepancia de protocolo.

Recorre las cuatro etapas en orden, y el fallo que ves caerá en una de ellas.

Etapa 1: TCP y TLS

El cliente abre una conexión TCP al puerto 443 y realiza un handshake TLS. La cadena de certificados debe coincidir con el nombre de host con el que se configuró el cliente. Una discrepancia de nombre aquí produce un fallo antes de que se intercambie ningún mensaje SSTP, y la especificación de SSTP da por hecho que este canal HTTPS exterior ya existe. Nada en las etapas posteriores puede compensar un fallo de confianza aquí.

Un servidor web genérico puede completar esta etapa a la perfección y aun así fallar en la siguiente. El éxito de TLS es una evidencia sobre el certificado, no sobre el protocolo que hay detrás.

Etapa 2: la petición HTTPS

SSTP hace su petición con un método específico, SSTP_DUPLEX_POST, y mantiene el intercambio abierto en lugar de devolver un documento. Un servidor o proxy configurado para peticiones de página normales puede aceptar la conexión y luego rechazar el método. Ese rechazo es el problema de compatibilidad que la gente suele describir como que el puerto 443 está bloqueado.

Lee el código de respuesta y el método en el registro del servidor. Un rechazo en esta etapa es un problema distinto de un tiempo de espera TCP, y ambos llevan a correcciones diferentes.

Etapa 3: mensajes de control

Una vez aceptada la petición, SSTP intercambia mensajes de control que negocian y preparan el túnel. Son mensajes de protocolo dentro del cuerpo HTTPS, no peticiones HTTP, así que un proxy que inspecciona y reescribe cuerpos puede romperlos mientras deja intactas las peticiones de página.

Aquí es donde un dispositivo de inspección profunda gana su reputación. Si las páginas cargan y la VPN falla, comprueba si el cuerpo se modifica en lugar de si el puerto está abierto.

Etapa 4: PPP toma el relevo

PPP aporta después el comportamiento de la sesión: negociación del enlace, autenticación y la configuración de la capa de red que sigue. La autenticación PPP es independiente de la comprobación TLS que el cliente ya ha superado. Un certificado de servidor que el cliente acepta no dice nada sobre si las credenciales del usuario son válidas o si la cuenta está autorizada.

Un certificado aceptado y un inicio de sesión rechazado no son contradictorios. Son etapas consecutivas con resultados independientes.

La autenticación tiene varios papeles

El cliente valida la identidad del servidor TLS contra su almacén de confianza y el nombre configurado. Luego PPP autentica al usuario o a la máquina, según el despliegue. El servidor puede añadir su propia política sobre quién puede conectarse y a qué puede llegar. Mantén el nombre de host coherente con la identidad del certificado, porque sustituirlo por una dirección cruda convierte una configuración que funciona en un fallo de comprobación de nombre.

Anota qué etapa informó del fallo. Certificado, método, mensaje de control, autenticación PPP, luego rutas: cinco lugares, cinco reparaciones.

Qué puede y qué no puede mostrar una prueba en el navegador

Cargar una página en la dirección demuestra resolución DNS, alcance TCP y que algo escucha que habla HTTP. No demuestra que el método se acepte, que el intercambio de control sobreviva o que la autenticación PPP esté configurada. Usa un cliente que implemente SSTP en lugar de convertir otro perfil cambiando el puerto.

Una vez levantada la sesión, las rutas, el DNS y el reenvío del lado del servidor siguen decidiendo a qué puede llegar el usuario. El túnel es un camino, no una autorización.

Artículos relacionados