SSTP atrás de um proxy que inspeciona TLS: onde a sessão quebra

O navegador carrega a intranet corporativa, o certificado do proxy é confiável e, mesmo assim, o cliente SSTP cai perto do fim da conexão. Esse padrão aponta para a diferença entre uma requisição web e uma sessão em túnel, não para uma senha errada. Percorra a conexão desde o TCP para cima e anote o primeiro estágio que falha. O estágio, não o código de erro, diz se o proxy é a causa.

Comece onde o cliente para

O cliente passa por uma sequência fixa: conexão TCP à porta 443, handshake TLS, validação do certificado, a troca HTTP do SSTP, negociação e autenticação PPP e, depois, a configuração de IP. Uma falha em cada estágio deixa uma assinatura diferente, e confundi-las leva você à página de configuração errada.

Uma falha de TCP é um tempo esgotado ou um reset antes que qualquer byte TLS apareça. Uma falha de TLS é um alerta ou um tempo esgotado de handshake. Uma falha de certificado produz um aviso sobre a cadeia ou o nome. Uma falha de HTTP chega após um handshake bem-sucedido, muitas vezes como código de status ou fechamento imediato. Uma falha de PPP chega depois que o túnel está tecnicamente estabelecido, e por isso parece um problema de autenticação.

Leia o log do cliente para encontrar o último estágio bem-sucedido, não a primeira linha de erro. A linha de erro costuma relatar a consequência, enquanto a fronteira do estágio nomeia o componente que recusou.

O que o SSTP pede que a rede transporte

O SSTP roda sobre TLS na TCP 443 e então envia uma requisição HTTP chamada SSTP_DUPLEX_POST, definida na especificação do SSTP, para um caminho no formato /sra_{GUID}/. A requisição declara um comprimento de conteúdo efetivamente ilimitado e mantém o fluxo aberto nas duas direções por toda a vida da sessão. Os quadros PPP viajam dentro desse fluxo.

Por isso um proxy que lida com a navegação comum ainda pode falhar. Um GET ou um POST com corpo finito pode ser armazenado, inspecionado e encaminhado; um fluxo duplex com corpo que nunca termina, não. Um proxy que espera o corpo terminar espera para sempre, e o cliente acaba estourando o tempo.

A filtragem de métodos e a autenticação acrescentam seus próprios modos de falha. Se o proxy pede credenciais para a requisição, o cliente VPN pode não responder, embora o navegador responderia. Se ele remove ou reescreve o método, o gateway recusa a requisição antes de o PPP começar.

Por que a inspeção muda a identidade

Um proxy que inspeciona TLS encerra a conexão TLS do cliente e abre uma conexão separada até o gateway. Por isso o cliente valida o certificado do proxy, não o do gateway, e o gateway vê o proxy como seu par. Quando a organização distribui a própria raiz, tanto o navegador quanto o cliente VPN podem aceitar essa cadeia, então o handshake dá certo e o problema passa ao próximo estágio.

Uma validação bem-sucedida não significa que o proxy consiga carregar a sessão. Ele ainda precisa repassar um POST bidirecional ilimitado sem armazenamento e manter as duas conexões vivas por horas. Muitos produtos de inspeção são feitos para tráfego de requisição-resposta e tratam esse caso mal ou não tratam.

Também por isso adicionar uma raiz desconhecida ou desativar a verificação é o conserto errado. Isso muda qual certificado o cliente aceita; não faz nada quanto ao tratamento de fluxo que de fato quebrou a sessão.

Identifique o emissor antes de mudar configurações

Pergunte ao endpoint qual certificado ele apresenta e quem o assinou. Os comandos abaixo mostram a cadeia e o emissor sem iniciar uma sessão VPN:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

Se o emissor for uma CA pública, provavelmente a conexão não está sendo interceptada para este host e a falha está em outro lugar. Se o emissor for a CA da própria organização, a inspeção está ativa e o gateway é alcançado por meio de um proxy. Compare a impressão digital com a que a equipe de rede espera antes de concluir apenas pelo nome.

Um teste de navegador ao mesmo host prova apenas que o proxy aceita um GET. Ele não diz nada sobre o método SSTP, a URI da requisição ou a vida do corpo, então não trate uma página de intranet que funciona como prova de que o caminho do túnel é suportado.

Escolha o caminho suportado

Faça ao dono da rede uma pergunta concreta: o proxy permite um POST duplex sem armazenamento até este gateway na porta 443? Um sim leva a uma exceção no proxy ou a um desvio documentado para o host VPN. Um não significa que o caminho inspecionado não consegue carregar SSTP, e a correção suportada é outro caminho ou protocolo, não um ajuste no cliente.

As opções costumam incluir uma saída não inspecionada para o gateway VPN, um projeto de túnel dividido que envia só o tráfego corporativo pelo proxy, ou um protocolo alternativo que a organização suporta em outra porta. Cada uma pertence ao projeto de rede e cada uma deve ser testada com o mesmo dispositivo e perfil para que a comparação isole o caminho.

Documente o resultado: emissor, estágio que falhou, regra do proxy e caminho escolhido. A próxima pessoa que vir a mesma parada em 98 por cento poderá verificar um único fato em vez de repetir todo o percurso.