NetworkManager-ssh affiche connecté mais rien n’est routé
L’indicateur prouve seulement que la relation SSH gérée existe. Vérifiez si le greffon a créé un périphérique tunnel ou un ensemble de redirections, puis testez le chemin de l’application.
Le menu affiche la connexion SSH comme active, la clé d’hôte a été acceptée, et le navigateur n’atteint toujours rien de ce qu’il devait atteindre. Ce n’est pas une contradiction, car un profil NetworkManager-ssh peut produire deux résultats très différents à partir du même hôte et de la même clé : un périphérique tunnel qui transporte des paquets, ou un ensemble de redirections que seules certaines applications peuvent utiliser. L’indicateur signale que la relation SSH gérée existe. Il ne signale jamais lequel des deux vous avez obtenu.
Deux résultats derrière une entrée de menu
Les deux modes s’authentifient de la même manière, et c’est précisément pour cela qu’ils se confondent. Sélectionner le profil exactement de la même façon, avec les mêmes identifiants, peut vous laisser avec une interface par laquelle router ou avec une socket d’écoute dont une application doit être informée.
Commencez par décider quel résultat la tâche nécessite réellement. Une exigence d’accessibilité à tout un sous-réseau nécessite un périphérique. Un seul service sur un hôte distant nécessite une redirection, et construire un tunnel pour lui crée généralement plus de travail de routage que le problème ne le méritait.
Ce que chaque mode doit avoir avant de fonctionner
Le projet documente les deux modes, et les prérequis diffèrent assez pour qu’un prérequis manquant ressemble à une défaillance de protocole plutôt qu’à un choix de conception.
| Mode | What must exist | What still has to be true |
|---|---|---|
| Tunnel device | Compatible TUN/TAP arrangement on both ends, permission, addressing | A route policy that actually sends the intended prefixes into it |
| Forwarding only | A chosen SOCKS, local-forward or remote-forward listener | A permitted destination path on the far side |
Lisez attentivement la colonne de droite, car c’est là que se terminent la plupart de ces tickets. Même un périphérique tunnel parfaitement construit ne couvre que ce que le routage y envoie, et même une redirection parfaite n’aide que les applications à qui l’on a dit de l’utiliser.
L’interface factice n’est pas un tunnel
En mode redirection, le greffon documente une interface factice créée pour satisfaire le modèle de connexion. Elle existe pour que le gestionnaire ait quelque chose à quoi attacher l’état. Elle ne transporte pas de paquets applicatifs arbitraires vers le réseau distant, et rien dans sa présence n’implique que le routage IP a changé.
Les exemples de tunnel complet du projet concernent la prise en charge du périphérique tunnel d’OpenSSH, donc le mot tunnel dans une étiquette décrit une capacité, pas votre politique effective. Vérifiez ce que fera le noyau plutôt que le nom du profil.
nmcli connection show --active
ip -br link
ss -lntp | grep -E "1080|8080"Associez ensuite le résultat à l’application. Un programme qui comprend SOCKS doit être configuré pour utiliser le proxy. Un consommateur de redirection locale doit être dirigé vers son écouteur. Ni l’un ni l’autre ne découvre la redirection tout seul, et aucun des deux n’est aidé par un indicateur de connexion devenu vert.
Préparez le côté distant au lieu de le forcer
Un compte SSH ordinaire peut s’authentifier sans aucune autorisation de créer un périphérique tunnel distant. Le projet documente un chemin sans root où un administrateur crée au préalable le périphérique pour cet utilisateur, et le client choisit ensuite le numéro correspondant.
Une telle disposition nécessite une coordination avec la politique de tunnel du serveur et avec celui qui possède l’adressage sur le réseau distant. Créer le périphérique n’accorde pas en soi les routes des ressources, les autorisations de redirection ni un chemin de retour, et rien de tout cela n’arrive parce que la configuration d’exemple semblait convaincante.
Ce que vous ne devriez pas faire, c’est activer une redirection illimitée ou une connexion root distante pour faire fonctionner un exemple. Là où l’opérateur possède la configuration du réseau distant, utilisez la disposition prise en charge pour laisser ces commandes à ce propriétaire, et évitez un second assistant qui rétablit des adresses contradictoires lors de la déconnexion.
Contexte d’authentification, et quoi mettre dans le ticket
L’authentification a son propre contexte. Le greffon cherche un agent SSH associé à la session utilisateur et exige que l’hôte de destination soit connu, donc une clé qui fonctionne dans un terminal ne devient pas automatiquement visible pour le chemin d’authentification du gestionnaire. Faites enregistrer et vérifier la clé d’hôte par le processus approuvé plutôt que de désactiver la vérification.
Pour le support, notez quatre choses : le greffon et sa version, le mode sélectionné, l’identité distante visée et l’interface ou l’écouteur qui aurait dû apparaître. Testez ensuite directement le point d’entrée de l’application. Un indicateur connecté accompagné d’un test fonctionnel est une preuve ; un indicateur connecté seul est une affirmation sur SSH, pas sur le routage ou l’autorisation de ressource que vous cherchiez à obtenir.