SSTP en Linux falla antes de iniciar sesión? Revise as pezas de execución

Instala o complemento SSTP, aparece o botón de opción no editor de rede, enche unha pasarela e un nome de usuario, e o perfil falla cun erro xenérico antes de pedir sequera un contrasinal. Nada nesa secuencia é inusual, e nada nela demostra que o software do túnel estea instalado. Unha conexión SSTP ensámblase con pezas que se distribúen por separado: un complemento de VPN que NetworkManager pode lanzar, o programa cliente SSTP que posúe a sesión TLS e PPP, o demo PPP por baixo, e un almacén de segredos que a conexión ten permiso para ler.

Que engade a entrada de menú e que non

O complemento achega unha descrición de servizo que lle di a NetworkManager como inicialo, e na maioría das distribucións un pequeno editor que debuxa o formulario. Ese é todo o alcance da entrada de menú. O programa cliente vén doutro paquete fonte, e o propio README do complemento di a separación directamente: é un complemento, non un cliente.

O cliente necesita despois PPP, porque SSTP transporta unha sesión PPP dentro dunha conexión TLS. Sen pppd o túnel pode completar o aperto de mans TLS e aínda así morrer na primeira trama de control, o que parece un problema de credenciais e non o é. En Debian e Ubuntu as pezas chegan como network-manager-sstp, sstp-client e ppp, e instalar só a primeira é a razón máis común de que un formulario acepte todos os campos mentres a conexión nunca remata.

A elección de escritorio engade outra separación. Plasma edita perfís mediante plasma-nm, que necesita o seu propio compoñente SSTP e le a mesma descrición de servizo, así que un editor sen entrada SSTP e unha CLI que crea perfís ben é unha metade de editor ausente, non un contorno de execución roto.

Lea a primeira etapa que falla antes de reinstalar calquera cousa

Un intento fallido de SSTP pasa por etapas nunha orde fixa, e a etapa que fallou dille que compoñente mirar.

Lanzar o complemento é a primeira, e un fallo alí produce unha mensaxe sobre o servizo VPN, non sobre o servidor. Despois vén unha conexión TCP ao porto 443; un rexeitamento ou un tempo de espera aquí é un problema de accesibilidade, non de TLS. Logo o aperto de mans TLS e a comprobación de identidade do servidor, despois a negociación PPP e a autenticación da conta, e por último a asignación de enderezos e as rutas. Observe journalctl -f -u NetworkManager mentres activa o perfil unha vez, e lea a primeira liña específica en lugar da última xenérica.

Esa orde explica unha lectura errónea habitual. Unha queixa de certificado notifícase antes de enviar credencial ningunha, así que cambiar o contrasinal non pode axudar; un rexeitamento de autenticación PPP chega despois dun aperto de mans correcto, así que substituír o certificado tampouco axuda. Quede co primeiro erro e a súa etapa, e terá un diagnóstico en lugar dun síntoma.

A confianza no certificado e o inicio de sesión son portas separadas

O aperto de mans valida que o servidor é o que quería acadar, co emisor e o nome que configurou. Só despois a capa PPP ofrece o seu nome de usuario e contrasinal ao método de autenticación da pasarela. Dúas comprobacións independentes, pois, avaliadas nunha orde fixa, con axustes separados para cada unha. Nada do que se escriba no campo do contrasinal pode influír na primeira.

Un perfil que confía no emisor equivocado falla na primeira porta cun erro de identidade. Un perfil que confía nel correctamente pero garda un contrasinal obsoleto falla na segunda cun rexeitamento de autenticación. Ambos parecen unha VPN que non se conectará, e ningún se arranxa co remedio do outro.

Obteña o emisor e o nome de servidor esperados de quen administra a pasarela en lugar de adiviñar os valores predeterminados do editor, e anote o método de autenticación que esixen. Se a organización necesita un método que o complemento non pode expresar, a resposta honesta é un cliente aprobado que si poida, non un perfil coa validación desactivada para facer desaparecer o erro.

Deixe que un único propietario teña o perfil e os segredos

Unha vez existe o perfil, actíveo mediante NetworkManager e deixe que ese xestor posúa as rutas e os cambios de resolutor resultantes. Iniciar un segundo cliente SSTP autónomo mentres NetworkManager xa leva a conexión dálle dous conxuntos de rutas, dúas configuracións de DNS e unha sesión de depuración sen unha única fonte de verdade.

Os segredos tamén teñen dono. Unha conexión marcada para uso de todo o sistema garda as credenciais de forma distinta que unha limitada á súa sesión de usuario, e un perfil creado a man nun ficheiro de chaves pode non ser lexible polo axente de segredos que espera fornecer o contrasinal de forma interactiva. Comprobe que contexto espera o perfil antes de volver escribir un contrasinal que nunca foi o problema. Activar o mesmo perfil desde un terminal con nmcli é a proba máis rápida, porque un aviso que nunca aparece dille que o axente xa non tiña nada que ofrecer.

Comprobe o túnel, as rutas e o resolutor por separado

Un indicador de conectado só afirma que a ligazón subiu. Comprobe o destino que realmente necesita, a ruta que o transporta e o resolutor en uso, un cada vez; cada un pode estar mal mentres os outros dous están ben.

Para un intento fallido, capture a versión de cada compoñente e o texto do erro saneado. Comparta iso, non o perfil completo, porque o perfil pode conter o segredo precompartido e as súas credenciais gardadas.

Por último, desconecte e volva conectar, e reinicie unha vez. Se o perfil só funciona ao primeiro intento, o problema está no manexo dos segredos ou na propiedade das rutas, e ambos son máis baratos de arranxar agora que a metade dunha xornada laboral.