A porta 443 responde, o SSTP continua a falhar: que etapa se rompeu?

Concluir um handshake TCP para a porta 443 enquanto o túnel nunca é construído prova uma coisa, e é uma coisa pequena. Algo está à escuta e disposto a aceitar uma ligação nesse endereço. Não identifica o serviço, o certificado que vai apresentar, nem o que acontece depois dos primeiros bytes.

Quatro etapas separam esse handshake de um túnel funcional, e cada uma produz um erro diferente.

Uma porta aberta descreve apenas uma camada

Aceitar uma ligação TCP significa que um processo é dono do socket e que o caminho permite o handshake. Não diz nada sobre se esse processo é um servidor SSTP, se tem um certificado válido para o nome no seu perfil ou se vai autorizar a sua conta. Um servidor web no mesmo endereço responde ao handshake na perfeição e depois responde ao seu pedido SSTP com um erro HTTP. Tudo o que está acima desse handshake fica por testar.

Trate o teste da porta como o filtro mais barato possível e não como um veredito. O seu valor é eliminar uma categoria inteira de falhas, não confirmar tudo o que está acima.

Confundir as duas coisas é a razão pela qual as pessoas reinstalam clientes depois de um teste que nunca examinou o problema real do cliente.

Separe as quatro etapas com provas

As etapas são a acessibilidade do transporte, a validação TLS, a troca SSTP sobre HTTPS e a autenticação PPP dentro do túnel. Um caminho que passa a primeira e falha a quarta precisa de uma correção das credenciais; um que falha a segunda precisa de uma correção do certificado ou do nome. Essas reparações não têm nada em comum, e escolher a errada desperdiça a interrupção.

nc -vz vpn.example.net 443
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
curl -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/

O terceiro comando merece uma leitura atenta. Um 200 de uma página web comum diz-lhe que existe um serviço web; não diz que o pedido SSTP será compreendido. Um 404 do mesmo endereço é igualmente pouco informativo sobre a VPN. Só o registo do cliente lhe diz a qual das quatro etapas chegou.

Repare em que nome usou cada comando. O certificado é escolhido pelo nome que envia, por isso uma discrepância entre o perfil e o teste é uma discrepância que introduziu. Escrever esse nome ao lado do resultado evita a confusão mais tarde.

Leia o sucesso parcial na direção certa

Um intermediário pode permitir a navegação comum e recusar a troca posterior, e é por isso que um proxy que funciona para sites ainda pode falhar para um túnel. O mesmo padrão aparece quando um certificado é válido para um nome de navegador mas não para o nome configurado no perfil: o navegador fica satisfeito e o cliente não, e ambos têm razão quanto ao que verificaram.

Mantenha a validação do servidor ativa enquanto diagnostica isto. Desativá-la transforma uma discrepância de certificado num handshake bem-sucedido e esconde a única prova que teria explicado a falha.

Se o mesmo perfil funcionar a partir de outra rede, a diferença depende do caminho. Isso reduz a procura aos intermediários sem dizer qual, e continua a ser um passo útil em frente. Registe a rede que utilizou, porque a comparação não vale nada sem ela.

Depois teste a aplicação, não apenas a sessão

Assim que existir uma sessão, verifique a rota pretendida, a resolução de nomes e a permissão do serviço a partir do cliente que delas precisa. Um túnel ligado pode ainda ter um encaminhamento em falta no lado remoto ou uma rota de retorno que nunca existiu, e essas falhas parecem exatamente um problema de aplicação para a pessoa que espera.

Mantenha cada conclusão ligada à etapa que a produziu. Chamar porta aberta a uma VPN funcional é como uma verificação de certificado de cinco minutos se transforma num dia de reinstalar software.