Las capas de SSTP explicadas: qué sigue revelando el paquete interno

Dos hechos sobre SSTP se fusionan en la mayoría de las explicaciones, y es esa fusión la que vuelve confusas las capturas. El paquete de la aplicación sobrevive dentro del canal protegido, y la conexión TCP que transporta ese canal conserva sus propias direcciones en todo momento. Por el cable viaja un portador más su carga, nunca un sustituto de ninguno de los dos. Recorra la pila de fuera hacia dentro y etiquete cada frontera al cruzarla.

Empiece por el portador exterior

Lo primero en el cable es una conexión TCP corriente al puerto 443, con direcciones reales que los enrutadores reenvían. Esa conexión es la que sobrevive a la traducción de direcciones de red y la que un proveedor de acceso puede contar. Proteger la carga útil no elimina el portador, y no oculta el volumen ni el tiempo.

Todo lo que viene después de este punto se transporta en lugar de enrutarse. El portador sigue funcionando aunque el intercambio interno falle.

Siga la encapsulación hacia dentro

Dentro del canal protegido hay un intercambio de control SSTP, luego una sesión PPP y luego el paquete de red que el cliente quiere que se entregue. Cada capa tiene su propia negociación, sus propios mensajes de error y su propia máquina de estados. Por eso un fallo puede parecer un fallo de TLS desde un punto de vista y un fallo de PPP desde otro. Leer las capas en orden indica qué máquina de estados se detuvo.

Una sola captura rara vez muestra toda la pila. Las cabeceras externas solo son visibles fuera del punto final, y las internas solo tras la desencapsulación. Esa asimetría viene de dónde está usted, no del protocolo.

El diagrama siguiente agrupa las capas para que se pueda hablar de ellas. No es una disposición de bytes, no promete un registro por paquete y no dice nada sobre cuántas operaciones criptográficas realiza una implementación.

outer IP header
  TCP to port 443
    TLS record layer
      SSTP control and data packets
        PPP frames
          inner IP packet
            application transport and payload

Etiquete al observador antes de leer una captura

Dos capturas de una misma sesión responden preguntas distintas, y la interfaz donde se tomaron decide cuáles. En la ruta de acceso ve el portador y los registros TLS, y puede medir tamaños e intervalos sin ver una dirección interna. En el punto final, tras la desencapsulación, el paquete interno es tráfico corriente bajo la política privada de reenvío.

Escriba la interfaz y la dirección en cada captura antes de interpretarla. Un rastro tomado en un adaptador físico nunca mostrará las direcciones de la aplicación interna como campos externos normales, y leer esa ausencia como un fallo de cifrado es un error común. Un rastro tomado desde dentro del túnel no muestra ningún portador, así que no puede responder una pregunta sobre la visión del proveedor. La misma disciplina se aplica a los registros del punto final, que anotan el orden de la negociación y no los contenidos.

Conserve las comprobaciones que el diagrama no puede demostrar

El orden de las capas no establece que un despliegue valide el certificado del servidor, negocie una versión de TLS compatible o autorice la cuenta. Cada una de ellas es una decisión de configuración que falla con independencia de la encapsulación.

Compruébelas con un cliente que informe de lo que ha negociado en lugar de razonar a partir de un dibujo. Empiece con el saludo TLS, luego el intercambio SSTP, luego PPP, y deténgase en la primera etapa que informe de un error. El primer comando imprime la cadena y la versión negociada, y el segundo enumera los saludos presentes en una captura.

openssl s_client -connect vpn.corp.internal:443 -servername vpn.corp.internal
tshark -r sstp.pcap -Y "tls.handshake.type == 1"