SSTP sous Linux échoue avant la connexion ? Vérifiez les composants d'exécution

Vous installez le greffon SSTP, la case d'option apparaît dans l'éditeur réseau, vous saisissez une passerelle et un nom d'utilisateur, et le profil échoue avec une erreur générique avant même de demander un mot de passe. Rien dans cette séquence n'est inhabituel, et rien n'y prouve que le logiciel du tunnel est installé. Une connexion SSTP s'assemble à partir de pièces livrées séparément : un greffon VPN que NetworkManager peut lancer, le programme client SSTP qui possède la session TLS et PPP, le démon PPP en dessous, et un magasin de secrets que la connexion est autorisée à lire.

Ce que l'entrée de menu apporte, et ce qu'elle n'apporte pas

Le greffon apporte une description de service qui indique à NetworkManager comment le lancer, et sur la plupart des distributions un petit éditeur qui dessine le formulaire. C'est toute la portée de l'entrée de menu. Le programme client vient d'un paquet source différent, et le README du greffon lui-même dit la séparation franchement : c'est un greffon, pas un client.

Le client a ensuite besoin de PPP, car SSTP transporte une session PPP dans une connexion TLS. Sans pppd le tunnel peut terminer sa poignée de main TLS et mourir quand même à la première trame de contrôle, ce qui ressemble à un problème d'identifiants sans en être un. Sous Debian et Ubuntu les pièces arrivent sous les noms network-manager-sstp, sstp-client et ppp, et n'installer que la première est la raison la plus fréquente qu'un formulaire accepte tous les champs alors que la connexion ne se termine jamais.

Le choix du bureau ajoute une séparation de plus. Plasma modifie les profils via plasma-nm, qui a besoin de son propre composant SSTP et lit la même description de service, donc un éditeur sans entrée SSTP et une CLI qui crée des profils sans problème, c'est une moitié d'éditeur manquante, pas un environnement d'exécution cassé.

Lisez la première étape qui échoue avant de réinstaller quoi que ce soit

Une tentative SSTP échouée traverse des étapes dans un ordre fixe, et l'étape qui a échoué vous indique quel composant regarder.

Le lancement du greffon est la première, et un échec là produit un message sur le service VPN, pas sur le serveur. Vient ensuite une connexion TCP au port 443 ; un refus ou un délai ici est un problème de joignabilité, pas de TLS. Puis la poignée de main TLS et la vérification de l'identité du serveur, ensuite la négociation PPP et l'authentification du compte, et enfin l'attribution d'adresse et les routes. Surveillez journalctl -f -u NetworkManager pendant que vous activez le profil une fois, et lisez la première ligne précise plutôt que la dernière générique.

Cet ordre explique une mauvaise lecture courante. Une plainte de certificat est signalée avant l'envoi du moindre identifiant, donc changer le mot de passe ne peut pas aider ; un rejet d'authentification PPP arrive après une poignée de main réussie, donc remplacer le certificat n'aide pas non plus. Gardez la première erreur et son étape, et vous avez un diagnostic plutôt qu'un symptôme.

La confiance dans le certificat et la connexion au compte sont deux portes distinctes

La poignée de main valide que le serveur est celui que vous vouliez joindre, à l'aide de l'émetteur et du nom que vous avez configurés. Ce n'est qu'ensuite que la couche PPP présente votre nom d'utilisateur et votre mot de passe à la méthode d'authentification de la passerelle. Deux contrôles indépendants, donc, évalués dans un ordre fixe, avec des réglages distincts pour chacun. Rien de ce qui est tapé dans le champ du mot de passe ne peut influencer le premier.

Un profil qui fait confiance au mauvais émetteur échoue à la première porte avec une erreur d'identité. Un profil qui lui fait confiance correctement mais stocke un mot de passe périmé échoue à la seconde avec un rejet d'authentification. Les deux ressemblent à un VPN qui ne se connectera pas, et aucun n'est réparé par le remède de l'autre.

Obtenez l'émetteur et le nom de serveur attendus auprès de qui exploite la passerelle plutôt que de deviner les valeurs par défaut de l'éditeur, et notez la méthode d'authentification qu'ils exigent. Si l'organisation a besoin d'une méthode que le greffon ne peut pas exprimer, la réponse honnête est un client approuvé qui le peut, pas un profil dont la validation est désactivée pour faire disparaître l'erreur.

Laissez un seul propriétaire tenir le profil et les secrets

Une fois le profil créé, activez-le via NetworkManager et laissez ce gestionnaire posséder les routes et les changements de résolveur qui en résultent. Lancer un second client SSTP autonome alors que NetworkManager gère déjà la connexion vous donne deux jeux de routes, deux configurations DNS et une session de débogage sans source de vérité unique.

Les secrets ont aussi un propriétaire. Une connexion marquée pour un usage à l'échelle du système stocke les identifiants différemment d'une connexion limitée à votre session utilisateur, et un profil créé à la main dans un fichier de clés peut ne pas être lisible par l'agent de secrets qui s'attend à fournir le mot de passe de façon interactive. Vérifiez quel contexte le profil attend avant de retaper un mot de passe qui n'a jamais été le problème. Activer le même profil depuis un terminal avec nmcli est le test le plus rapide, car une invite qui n'apparaît jamais vous dit que l'agent n'avait déjà rien à offrir.

Vérifiez le tunnel, les routes et le résolveur séparément

Un indicateur « connecté » affirme seulement que la liaison est montée. Vérifiez la destination dont vous avez réellement besoin, la route qui la transporte et le résolveur utilisé, une à la fois ; chacune peut être fausse alors que les deux autres sont correctes.

Pour une tentative échouée, relevez la version de chaque composant et le texte d'erreur expurgé. Partagez-les, pas le profil complet, car le profil peut contenir le secret pré-partagé et vos identifiants stockés.

Enfin, déconnectez et reconnectez, puis redémarrez une fois. Si le profil ne fonctionne qu'à la première tentative, le problème tient à la gestion des secrets ou à la propriété des routes, et les deux sont moins coûteux à corriger maintenant qu'au milieu d'une journée de travail.