Como verificar se um cliente VPN suporta realmente SSTP

Chamar um produto de cliente VPN não diz nada sobre se ele fala SSTP, e a porta 443 no endereço prova ainda menos. O SSTP executa TLS sobre TCP 443, depois uma troca de controlo SSTP, depois PPP para a própria ligação, com validação de certificado e um método de autenticação PPP por cima. Um cliente só suporta o protocolo quando a implementação indicada, na versão instalada, conclui cada uma dessas camadas segundo os requisitos do seu servidor. Faça as verificações abaixo por ordem e pare na primeira que falhar, porque é essa que vale a pena resolver.

Alinhe a implementação, a versão e a plataforma

Comece pela plataforma, pela aplicação e pela compilação instalada, porque um único nome de fabricante pode estar sobre duas implementações completamente diferentes. Os tipos de VPN integrados e os clientes de terceiros não são a mesma coisa, e um plug-in pode mostrar uma etiqueta de adaptador que não descreve o protocolo por baixo. A documentação da versão atual não descreve a compilação que está a correr na máquina à sua frente. Leia a página específica da versão e compare-a com o que o cliente declara sobre si próprio.

No Windows o tipo de túnel vem da plataforma e não da interface gráfica, por isso pergunte à plataforma. Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress mostra Sstp quando o cliente nativo tentar o protocolo, e a referência de tipos de ligação lista-o entre os tipos de túnel integrados. No Linux não existe nenhum cliente SSTP nativo, por isso a questão passa a ser se uma implementação separada como sstpc do pacote sstp-client está instalada e atualizada.

Leia o formato do perfil antes da etiqueta

Os perfis não são intermutáveis, e o ficheiro que lhe entregaram resolve normalmente a questão mais depressa do que qualquer lista de funcionalidades. As diretivas OpenVPN, as chaves WireGuard e as definições de ligação SSTP descrevem três protocolos sem relação, e nenhuma caixa de importação transforma um no outro. Partilhar a porta TCP 443 não traduz nada, porque SSTP, OpenVPN sobre TLS e um serviço HTTPS comum podem ocupar a mesma porta e não ter nada em comum por cima.

Se o ficheiro for um .ovpn ou uma configuração WireGuard, a resposta já está clara: não se pede a esse cliente que fale SSTP. Importá-lo num cliente que só faz SSTP falha na fase do perfil, muito antes de começar qualquer negociação do protocolo.

O que o TLS não prova sobre a implementação

Um handshake TLS concluído prova que o servidor tem um certificado, e não prova nada sobre se o seu cliente confia na cadeia emissora ou se o nome lá dentro corresponde. A validação tem de ser bem-sucedida contra o servidor pretendido, incluindo qualquer CA privada operada pela organização, e um cliente que oferece ignorar erros de certificado removeu a verificação em vez de ter ganho suporte do protocolo. A validação da cadeia e a correspondência do nome são dois testes separados, e uma pilha que passa um pode falhar no outro. Ambos pertencem aos critérios de aceitação, não ao anexo de resolução de problemas.

Depois confirme o método de autenticação PPP, porque uma implementação com EAP-TLS precisa de um cliente que consiga apresentar um certificado dentro do PPP, enquanto um método baseado em palavra-passe precisa de suporte para essa troca. Um endereço de servidor e uma palavra-passe não descrevem o requisito real da organização, sobretudo quando há um segundo fator ou uma verificação do dispositivo à frente. Pergunte que método o servidor impõe antes de assumir que o cliente o consegue satisfazer.

Siga a sessão por quatro etapas

Observe a ligação a atravessar quatro fronteiras: TCP e TLS até ao servidor, a troca de controlo SSTP, a negociação PPP e depois o recurso de que realmente precisa. Um registo que para após o TLS descreve uma avaria diferente de um que para dentro do PPP, e os dois levam a responsáveis diferentes. O carregamento da página web do anfitrião pelo navegador prova apenas que algo respondeu na 443, que é o falso positivo mais comum nesta área. Se essa página carregar enquanto o cliente continua a falhar, o problema está acima do TLS e o servidor web não é o suspeito.

Termine com um recurso privado real e uma consulta de nome, porque uma sessão que se estabelece e não transporta nada parece igual a uma funcional na maioria das janelas de estado. Um único pedido bem-sucedido ao recurso de que precisa resolve uma questão que o ícone não consegue.

Quando falta suporte, mude o plano

Se o cliente não consegue falar SSTP, obtenha uma alternativa aprovada ou peça ao proprietário do servidor um protocolo suportado por ambos os extremos. Apagar as opções não reconhecidas até uma importação funcionar produz um perfil que não liga a nada, o que é um caminho mais lento para o mesmo beco sem saída. Um instalador de origem desconhecida que anuncia compatibilidade universal acrescenta um caminho de confiança não aprovado à máquina e substitui muitas vezes o cliente da plataforma por algo que a organização não consegue atualizar. Nenhuma das duas manobras é uma correção, e ambas são mais difíceis de desfazer do que o problema original.

Trate a questão da compatibilidade separadamente do desempenho e da escolha do ponto final, porque um servidor próximo é inútil quando o cliente não consegue falar o seu protocolo. O ajuste da latência não repara uma etapa que nunca termina.