SSTP no Linux falha antes do login? Verifique as peças de execução

Você instala o plug-in SSTP, o botão de opção aparece no editor de rede, você preenche um gateway e um nome de usuário, e o perfil falha com um erro genérico antes mesmo de pedir uma senha. Nada nessa sequência é incomum, e nada nela prova que o software do túnel está instalado. Uma conexão SSTP é montada com peças fornecidas separadamente: um plug-in de VPN que o NetworkManager pode iniciar, o programa cliente SSTP que possui a sessão TLS e PPP, o daemon PPP por baixo, e um armazenamento de segredos que a conexão tem permissão para ler.

O que a entrada de menu acrescenta, e o que não acrescenta

O plug-in contribui com uma descrição de serviço que diz ao NetworkManager como iniciá-lo, e na maioria das distribuições um pequeno editor que desenha o formulário. Esse é todo o escopo da entrada de menu. O programa cliente vem de um pacote-fonte diferente, e o README do próprio plug-in diz a separação diretamente: é um plug-in, não um cliente.

O cliente então precisa de PPP, porque o SSTP transporta uma sessão PPP dentro de uma conexão TLS. Sem pppd o túnel pode completar o handshake TLS e mesmo assim morrer no primeiro quadro de controle, o que parece um problema de credenciais e não é. No Debian e no Ubuntu as peças chegam como network-manager-sstp, sstp-client e ppp, e instalar só a primeira é o motivo mais comum de um formulário aceitar todos os campos enquanto a conexão nunca termina.

A escolha da área de trabalho acrescenta mais uma separação. O Plasma edita perfis pelo plasma-nm, que precisa do próprio componente SSTP e lê a mesma descrição de serviço, então um editor sem entrada SSTP e uma CLI que cria perfis bem é uma metade de editor ausente, não um ambiente de execução quebrado.

Leia a primeira etapa que falha antes de reinstalar qualquer coisa

Uma tentativa de SSTP que falha passa por etapas em ordem fixa, e a etapa que falhou indica qual componente observar.

Iniciar o plug-in é a primeira, e uma falha aí gera uma mensagem sobre o serviço VPN, não sobre o servidor. Depois vem uma conexão TCP à porta 443; uma recusa ou um tempo esgotado aqui é um problema de alcance, não de TLS. Em seguida o handshake TLS e a verificação de identidade do servidor, depois a negociação PPP e a autenticação da conta, e por fim a atribuição de endereços e as rotas. Observe journalctl -f -u NetworkManager enquanto ativa o perfil uma vez, e leia a primeira linha específica em vez da última genérica.

Essa ordem explica uma leitura errada comum. Uma queixa de certificado é reportada antes de qualquer credencial ser enviada, então trocar a senha não pode ajudar; uma rejeição de autenticação PPP chega depois de um handshake bem-sucedido, então substituir o certificado também não ajuda. Guarde o primeiro erro e a etapa dele, e você tem um diagnóstico em vez de um sintoma.

Confiança no certificado e login na conta são portões separados

O handshake valida que o servidor é aquele que você queria alcançar, usando o emissor e o nome que configurou. Só depois a camada PPP oferece seu nome de usuário e senha ao método de autenticação do gateway. Duas verificações independentes, portanto, avaliadas em ordem fixa, com ajustes separados para cada uma. Nada digitado no campo de senha pode influenciar a primeira.

Um perfil que confia no emissor errado falha no primeiro portão com um erro de identidade. Um perfil que confia nele corretamente mas guarda uma senha antiga falha no segundo com uma rejeição de autenticação. Ambos parecem uma VPN que não vai conectar, e nenhum se resolve com o remédio do outro.

Obtenha o emissor e o nome do servidor esperados de quem administra o gateway em vez de adivinhar os valores padrão do editor, e anote o método de autenticação exigido. Se a organização precisa de um método que o plug-in não consegue expressar, a resposta honesta é um cliente aprovado que consiga, não um perfil com a validação desligada para fazer o erro desaparecer.

Deixe um único dono com o perfil e os segredos

Assim que o perfil existe, ative-o pelo NetworkManager e deixe esse gerenciador ser dono das rotas e mudanças de resolvedor resultantes. Iniciar um segundo cliente SSTP autônomo enquanto o NetworkManager já conduz a conexão dá a você dois conjuntos de rotas, duas configurações de DNS e uma sessão de depuração sem uma única fonte de verdade.

Segredos também têm dono. Uma conexão marcada para uso de todo o sistema guarda credenciais de forma diferente de uma limitada à sua sessão de usuário, e um perfil criado à mão em um arquivo de chaves pode não ser legível pelo agente de segredos que espera fornecer a senha interativamente. Verifique qual contexto o perfil espera antes de digitar de novo uma senha que nunca foi o problema. Ativar o mesmo perfil a partir de um terminal com nmcli é o teste mais rápido, porque um prompt que nunca aparece diz que o agente já não tinha nada a oferecer.

Verifique o túnel, as rotas e o resolvedor separadamente

Um indicador de conectado afirma apenas que o enlace subiu. Verifique o destino de que você realmente precisa, a rota que o transporta e o resolvedor em uso, um de cada vez; cada um pode estar errado enquanto os outros dois estão bem.

Para uma tentativa falha, capture a versão de cada componente e o texto do erro saneado. Compartilhe isso, não o perfil completo, porque o perfil pode conter o segredo pré-compartilhado e suas credenciais armazenadas.

Por fim, desconecte e reconecte, e reinicie uma vez. Se o perfil só funciona na primeira tentativa, o problema está no tratamento dos segredos ou na propriedade das rotas, e ambos são mais baratos de corrigir agora do que no meio de um dia de trabalho.