O SSTP falha onde o HTTPS do navegador funciona: por que

O navegador abre o nome do anfitrião da VPN por HTTPS sem reclamar, e o cliente SSTP continua a recusar ligar-se. Nada nesse par é contraditório. O SSTP usa o TLS como transporte exterior e depois executa o seu próprio pedido e a carga PPP dentro dessa ligação, pelo que um carregamento de página bem-sucedido prova apenas uma coisa estreita: o anfitrião responde a um GET na porta 443. O cliente faz outra pergunta, e o servidor pode respondê-la mal.

A página carrega e o túnel não

As pessoas recorrem ao teste do navegador porque é rápido, e depois tomam o resultado como prova de que o servidor está acessível e configurado. É uma prova sobre um GET ao caminho que a barra de endereços abriu, nada mais. A conversa VPN começa após o mesmo handshake TLS, mas envia um método e um caminho que uma página web nunca usa. Por isso, uma resposta 200 para o navegador não diz nada sobre se o ponto final SSTP existe.

Separe as duas observações e a pesquisa encurta. O transporte e a cadeia de certificados funcionam, e algo na troca de protocolo acima deles não funciona. É uma investigação diferente da de uma porta avariada ou de um certificado expirado, e exige provas diferentes.

O que o cliente SSTP envia realmente

O cliente envia um pedido HTTP com o método SSTP_DUPLEX_POST para o caminho /sra_{GUID}/, e depois mantém o corpo da ligação aberto como um fluxo bidirecional que transporta tramas PPP. Um servidor conforme responde HTTP/1.1 200 e deixa de se comportar como servidor web. Qualquer outra coisa é uma assinatura: 405 ou 404 significa que o ponto final não existe, 301 ou 302 significa que algo redireciona o pedido, e um FIN imediato significa que um proxy ou servidor fechou o fluxo.

Por isso o alvo deve ser um servidor SSTP e não um servidor web com um certificado TLS aparafusado. O método, o caminho e o corpo de longa duração são requisitos do protocolo, pelo que um proxy inverso não os pode acrescentar apenas com configuração. Um proxy que reencaminha HTTPS comum na perfeição pode ainda recusar um método que não reconhece.

Onde um proxy ou servidor web quebra o fluxo

Um intermediário inspeciona a linha do pedido HTTP antes de reencaminhar qualquer coisa, e um método personalizado com um caminho invulgar pode falhar as suas regras. Alguns dispositivos servem uma página normal enquanto rejeitam ou interrompem o túnel, pelo que o cliente relata uma ligação que começa e depois morre em vez de uma recusa limpa. Outros aceitam o pedido e depois aplicam um tempo limite de corpo ou de inatividade que os keepalives PPP não sobrevivem. Ambos parecem iguais do lado do cliente, por isso a etapa que falhou importa mais do que o texto do erro.

Partilhar a porta 443 entre um sítio web e o SSTP é uma escolha de encaminhamento, não uma promessa de que cada salto trate as duas conversas da mesma forma. Se houver um balanceador de carga, uma firewall ou um terminador TLS no caminho, acrescente-o à lista de suspeitos antes de tocar na configuração da VPN.

Teste as etapas separadamente

Execute as verificações por ordem e pare na primeira falha, porque cada etapa elimina uma camada diferente. A sonda TLS abaixo separa a identidade do certificado de tudo o que o SSTP faz. Substitua o nome do anfitrião pelo seu ponto final e leia o subject e a cadeia que imprime.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com

Depois mapeie as provas restantes para as etapas em vez de adivinhar a partir do erro do cliente. A tabela abaixo é a lista de verificação para citar no ticket, com a assinatura que separa uma falha da seguinte.

Registe no ticket a última etapa que teve êxito em vez de escrever "não é possível ligar". A especificação MS-SSTP documenta o pedido e a troca PPP que se seguem ao handshake TLS, e é a referência para explicar porque um teste no navegador não pode substituir nenhum dos dois.

Primeiro a identidade, depois o PPP

A identidade TLS e a autenticação PPP são sequenciais, não alternativas, e confundi-las leva as pessoas à configuração errada do servidor. O cliente valida primeiro o certificado do servidor e o seu propósito previsto, depois o PPP negoceia o seu próprio estado e autentica o utilizador com um método de desafio-resposta ou EAP. Um problema de certificado produz um erro diferente de uma palavra-passe rejeitada, e nenhum dos dois erros descreve a etapa que o outro cobre.

Substituir o nome do anfitrião por um endereço, ou clicar para lá do aviso de certificado, remove a verificação que teria identificado a etapa em falha em vez de a corrigir. Mantenha o aviso e leia-o. Também não reponha uma palavra-passe PPP quando a troca HTTP nunca chegou ao comportamento SSTP, porque a credencial nunca foi pedida.