SSTP é PPP sobre HTTPS, não uma página web na porta 443

SSTP transporta PPP dentro de uma conexão HTTPS, por isso parece tráfego web para qualquer coisa no meio. TLS e HTTP estabelecem o canal externo, depois as mensagens de controle do SSTP preparam o túnel e o PPP fornece o comportamento da sessão. Um navegador que carrega uma página no mesmo endereço concluiu apenas parte do primeiro estágio. Tratar isso como um teste de VPN é a forma como um proxy que funciona é culpado por uma divergência de protocolo.

Percorra os quatro estágios em ordem, e a falha que você vê cairá em um deles.

Estágio 1: TCP e TLS

O cliente abre uma conexão TCP para a porta 443 e realiza um handshake TLS. A cadeia de certificados deve corresponder ao nome de host com que o cliente foi configurado. Uma divergência de nome aqui produz uma falha antes que qualquer mensagem SSTP seja trocada, e a especificação do SSTP presume que esse canal HTTPS externo já existe. Nada nos estágios posteriores pode compensar uma falha de confiança aqui.

Um servidor web comum pode concluir este estágio perfeitamente e ainda falhar no seguinte. O sucesso do TLS é uma evidência sobre o certificado, não sobre o protocolo por trás dele.

Estágio 2: a requisição HTTPS

O SSTP faz sua requisição com um método específico, SSTP_DUPLEX_POST, e mantém a troca aberta em vez de devolver um documento. Um servidor ou proxy configurado para requisições de página comuns pode aceitar a conexão e então rejeitar o método. Essa rejeição é o problema de compatibilidade que as pessoas costumam descrever como porta 443 bloqueada.

Leia o código de resposta e o método no log do servidor. Uma rejeição neste estágio é um problema diferente de um tempo limite TCP, e os dois levam a correções diferentes.

Estágio 3: mensagens de controle

Quando a requisição é aceita, o SSTP troca mensagens de controle que negociam e preparam o túnel. São mensagens de protocolo dentro do corpo HTTPS, não requisições HTTP, então um proxy que inspeciona e reescreve corpos pode quebrá-las enquanto as requisições de página permanecem intactas.

É aqui que um equipamento de inspeção profunda ganha sua reputação. Se as páginas carregam e a VPN falha, verifique se o corpo está sendo modificado em vez de se a porta está aberta.

Estágio 4: o PPP assume

O PPP então fornece o comportamento da sessão: negociação do enlace, autenticação e a configuração da camada de rede que se segue. A autenticação PPP é separada da verificação TLS que o cliente já passou. Um certificado de servidor que o cliente aceita não diz nada sobre se as credenciais do usuário são válidas ou se a conta está autorizada.

Um certificado aceito e um login rejeitado não são contraditórios. São estágios consecutivos com resultados independentes.

A autenticação tem vários papéis

O cliente valida a identidade do servidor TLS contra seu repositório de confiança e o nome configurado. Depois o PPP autentica o usuário ou a máquina, dependendo da implantação. O servidor pode adicionar sua própria política sobre quem pode conectar e até onde pode chegar. Mantenha o nome de host consistente com a identidade do certificado, porque substituí-lo por um endereço bruto transforma uma configuração que funciona em uma falha de verificação de nome.

Anote qual estágio relatou a falha. Certificado, método, mensagem de controle, autenticação PPP, depois rotas: cinco lugares, cinco correções.

O que um teste no navegador pode e não pode mostrar

Carregar uma página no endereço prova resolução de DNS, alcance TCP e que algo escuta e fala HTTP. Não prova que o método seja aceito, que a troca de controle sobreviva ou que a autenticação PPP esteja configurada. Use um cliente que implemente SSTP em vez de converter outro perfil mudando a porta.

Depois que a sessão sobe, rotas, DNS e encaminhamento do lado do servidor ainda decidem a que o usuário pode chegar. O túnel é um caminho, não uma autorização.