¿SSTP en Linux falla antes de iniciar sesión? Revise las piezas de ejecución

Instala el complemento SSTP, aparece el botón de opción en el editor de red, rellena una puerta de enlace y un nombre de usuario, y el perfil falla con un error genérico antes de pedir siquiera una contraseña. Nada en esa secuencia es inusual, y nada en ella demuestra que el software del túnel esté instalado. Una conexión SSTP se ensambla con piezas que se distribuyen por separado: un complemento de VPN que NetworkManager puede lanzar, el programa cliente SSTP que posee la sesión TLS y PPP, el demonio PPP debajo, y un almacén de secretos que la conexión tiene permiso para leer.

Qué aporta la entrada de menú y qué no

El complemento aporta una descripción de servicio que dice a NetworkManager cómo iniciarlo, y en la mayoría de las distribuciones un pequeño editor que dibuja el formulario. Ese es todo el alcance de la entrada de menú. El programa cliente viene de otro paquete fuente, y el propio README del complemento dice la separación directamente: es un complemento, no un cliente.

El cliente necesita después PPP, porque SSTP transporta una sesión PPP dentro de una conexión TLS. Sin pppd el túnel puede completar su apretón de manos TLS y aun así morir en la primera trama de control, lo que parece un problema de credenciales y no lo es. En Debian y Ubuntu las piezas llegan como network-manager-sstp, sstp-client y ppp, e instalar solo la primera es la razón más común de que un formulario acepte todos los campos mientras la conexión nunca termina.

La elección de escritorio añade otra separación. Plasma edita perfiles mediante plasma-nm, que necesita su propio componente SSTP y lee la misma descripción de servicio, así que un editor sin entrada SSTP y una CLI que crea perfiles sin problema es una mitad de editor ausente, no un entorno de ejecución roto.

Lea la primera etapa que falla antes de reinstalar nada

Un intento fallido de SSTP pasa por etapas en un orden fijo, y la etapa que falló le dice qué componente mirar.

Lanzar el complemento es la primera, y un fallo ahí produce un mensaje sobre el servicio VPN, no sobre el servidor. Después viene una conexión TCP al puerto 443; un rechazo o un tiempo de espera aquí es un problema de accesibilidad, no de TLS. Luego el apretón de manos TLS y la comprobación de identidad del servidor, después la negociación PPP y la autenticación de la cuenta, y por último la asignación de direcciones y las rutas. Observe journalctl -f -u NetworkManager mientras activa el perfil una vez, y lea la primera línea específica en lugar de la última genérica.

Ese orden explica una lectura errónea habitual. Una queja de certificado se notifica antes de enviar credencial ninguna, así que cambiar la contraseña no puede ayudar; un rechazo de autenticación PPP llega después de un apretón de manos correcto, así que sustituir el certificado tampoco ayuda. Quédese con el primer error y su etapa, y tendrá un diagnóstico en lugar de un síntoma.

La confianza en el certificado y el inicio de sesión son puertas separadas

El apretón de manos valida que el servidor es el que quería alcanzar, con el emisor y el nombre que configuró. Solo después la capa PPP ofrece su nombre de usuario y contraseña al método de autenticación de la puerta de enlace. Dos comprobaciones independientes, pues, evaluadas en un orden fijo, con ajustes separados para cada una. Nada de lo que se escriba en el campo de contraseña puede influir en la primera.

Un perfil que confía en el emisor equivocado falla en la primera puerta con un error de identidad. Un perfil que confía en él correctamente pero guarda una contraseña obsoleta falla en la segunda con un rechazo de autenticación. Ambos parecen una VPN que no se conectará, y ninguno se arregla con el remedio del otro.

Obtenga el emisor y el nombre de servidor esperados de quien administra la puerta de enlace en lugar de adivinar los valores predeterminados del editor, y anote el método de autenticación que exigen. Si la organización necesita un método que el complemento no puede expresar, la respuesta honesta es un cliente aprobado que sí pueda, no un perfil con la validación desactivada para hacer desaparecer el error.

Deje que un solo propietario tenga el perfil y los secretos

Una vez existe el perfil, actívelo mediante NetworkManager y deje que ese gestor posea las rutas y los cambios de resolución resultantes. Iniciar un segundo cliente SSTP autónomo mientras NetworkManager ya lleva la conexión le da dos conjuntos de rutas, dos configuraciones de DNS y una sesión de depuración sin una única fuente de verdad.

Los secretos también tienen dueño. Una conexión marcada para uso de todo el sistema guarda las credenciales de forma distinta que una limitada a su sesión de usuario, y un perfil creado a mano en un archivo de claves puede no ser legible por el agente de secretos que espera proporcionar la contraseña de forma interactiva. Compruebe qué contexto espera el perfil antes de volver a escribir una contraseña que nunca fue el problema. Activar el mismo perfil desde un terminal con nmcli es la prueba más rápida, porque un aviso que nunca aparece le dice que el agente ya no tenía nada que ofrecer.

Verifique el túnel, las rutas y el resolutor por separado

Un indicador de conectado solo afirma que el enlace subió. Compruebe el destino que realmente necesita, la ruta que lo transporta y el resolutor en uso, uno cada vez; cada uno puede estar mal mientras los otros dos están bien.

Para un intento fallido, capture la versión de cada componente y el texto del error saneado. Comparta eso, no el perfil completo, porque el perfil puede contener el secreto precompartido y sus credenciales guardadas.

Por último, desconecte y vuelva a conectar, y reinicie una vez. Si el perfil solo funciona al primer intento, el problema está en el manejo de secretos o en la propiedad de las rutas, y ambos son más baratos de arreglar ahora que a mitad de una jornada laboral.