Tunnels et ports
Comprendre les redirections de port SSH, remplir le formulaire de Hawser, et savoir pourquoi aucun tunnel ne démarre dans cette version.
À quoi sert une redirection de port
Une redirection de port ouvre un port sur votre Mac et fait passer tout ce qui y arrive dans la connexion SSH, jusqu'à une machine que seul le serveur distant sait joindre. Pour vos outils locaux, le service distant a l'air d'être sur votre poste.
Le cas qui motive la plupart des installations : une base PostgreSQL sur un serveur, configurée pour n'écouter que sur 127.0.0.1. Elle n'est donc joignable que depuis le serveur lui-même, ce qui est le bon réglage. Vous voulez pourtant l'ouvrir dans TablePlus ou pgAdmin depuis votre poste. Une redirection locale règle la question : votre outil se connecte à 127.0.0.1 sur un port choisi, le trafic ressort chiffré par SSH, et la base reste fermée au monde extérieur. Aucun port à ouvrir dans le pare-feu du serveur.
Les mêmes trois mécanismes couvrent la plupart des besoins quotidiens :
- Atteindre une base de données, un Redis ou un panneau d'administration lié à
localhostsur le serveur. - Montrer à un collègue, depuis l'extérieur, un service qui tourne sur votre machine.
- Faire sortir le trafic d'un navigateur par le serveur, pour tester un site comme s'il était vu depuis ce réseau.
Ce que cette version fait, et ne fait pas
Trois pièces existent : la vue Tunnels, un formulaire de création complet et validé, et un moteur de redirection de ports écrit en natif. La liaison entre le formulaire et le moteur n'est pas faite. Concrètement, vous pouvez décrire un tunnel dans Hawser, pas le démarrer.
La suite de cette page décrit ce qui est en place et se laisse documenter : la sémantique des trois types, les champs du formulaire, les messages de validation. La dernière section donne la marche à suivre pour monter un tunnel aujourd'hui, en dehors de Hawser. L'inventaire complet des fonctions manquantes se trouve dans Limites et dépannage.
Les trois types, et lequel choisir
| Type | Qui écoute | Pour quoi |
|---|---|---|
| Local (L) | Votre Mac | Atteindre un service distant depuis un outil local. Le cas de la base de données. |
| Remote (R) | Le serveur distant | Rendre accessible depuis le serveur un service qui tourne sur votre Mac. Démonstration, webhook de test. |
| SOCKS5 (D) | Votre Mac | Faire sortir tout le trafic d'une application par le serveur, sans redirection port par port. |
Local (L) demande trois informations : le port que Hawser ouvre chez vous, puis l'hôte et le port à joindre depuis le serveur. L'hôte distant est le plus souvent 127.0.0.1, c'est-à-dire le serveur lui-même ; ce peut aussi être une autre machine que seul le serveur voit, par exemple un serveur de base de données sur un réseau privé.
Remote (R) fonctionne dans l'autre sens. C'est le serveur SSH qui ouvre le port d'écoute. Beaucoup de serveurs refusent par défaut de l'exposer ailleurs que sur leur propre bouclage : le réglage GatewayPorts du serveur décide. En cas de refus, le moteur remonte protocol error: tcpip_forward: suivi du détail donné par le serveur.
SOCKS5 (D) ouvre un port local qui parle le protocole SOCKS5. Chaque destination demandée par le client devient un canal SSH. Vous réglez ensuite votre navigateur, ou macOS, pour utiliser ce proxy. Le moteur en implémente un sous-ensemble volontaire : méthode sans authentification uniquement, commande CONNECT uniquement, cibles IPv4, IPv6 et noms de domaine. Ni BIND, ni UDP ASSOCIATE, ni authentification par mot de passe.
Créer un tunnel dans l'interface
Le coffre doit être ouvert, et il doit contenir au moins un hôte de protocole SSH. Sinon le menu de sélection reste vide et rien ne peut être validé. Voir Ajouter un serveur.
- Dans le rail de gauche, cliquez sur Tunnels. Le titre de l'en-tête passe à « Tunnels » et la barre de recherche disparaît, cette vue n'étant pas filtrable.
- Cliquez sur + Tunnel, en haut à droite. La palette de commandes offre le même chemin : ⌘K, puis « tunnel », puis l'entrée
New tunnel. Il n'y a pas de raccourci clavier dédié aux tunnels. - Dans Type, choisissez
Local (L),Remote (R)ouSOCKS5 (D). La valeur par défaut estLocal (L). - Dans Via connexion SSH, choisissez l'hôte qui portera le tunnel. Le menu ne liste que les hôtes de protocole SSH, par leur nom. Il n'y a pas d'option vide, et il n'est pas rafraîchi si vous ajoutez un hôte pendant que la fenêtre est ouverte.
- Renseignez Port local, puis Remote host et Remote port.
- Cliquez sur Démarrer.
Port local vaut 8080 par défaut, Remote port vaut 80, tous deux bornés entre 1 et 65535. Remote host est vide au départ, avec 127.0.0.1 en texte d'aide. Quand vous choisissez SOCKS5 (D), les deux champs distants disparaissent : un proxy dynamique n'a pas de destination fixe.
Quatre contrôles s'exécutent avant tout accès réseau. Chacun affiche un bandeau rouge et interrompt l'action :
| Message | Cause |
|---|---|
Choose an SSH connection | Aucun hôte sélectionné. En pratique : le coffre ne contient aucun hôte SSH. |
Local port must be between 1 and 65535 | Port local vide, non numérique ou hors bornes. |
Remote host required | Champ Remote host vide, sur un tunnel L ou R. |
Remote port must be between 1 and 65535 | Port distant vide, non numérique ou hors bornes, sur un tunnel L ou R. |
Démarrer, arrêter, retrouver
Au clic sur Démarrer, le bouton se désactive et affiche un indicateur d'activité, le temps du traitement. Un second clic pendant ce délai est ignoré. Puis vient le bandeau Tunnels not implemented in this build. La fenêtre reste ouverte, rien n'est créé.
La liste prévoit une ligne par tunnel, au format <type>-forward : <port local> → <hôte>:<port>, avec le nom de l'hôte porteur en sous-titre et un bouton Stop rouge. Ce rendu n'est jamais atteint, la liste restant vide.
Côté natif, le moteur sait fermer proprement. À la déconnexion d'une session SSH, il demande au serveur d'annuler les redirections distantes, pour ne pas laisser un port occupé sur un bastion, puis arrête les tâches d'écoute. Ce comportement existe mais reste inobservable tant qu'aucun tunnel ne démarre.
Quand le port local est déjà pris
C'est le premier obstacle réel d'une redirection locale. Vous demandez le port 5432 alors qu'une instance PostgreSQL tourne déjà sur votre Mac, et l'ouverture du port échoue.
Hawser ne vérifie pas la disponibilité du port. La seule validation porte sur les bornes 1 à 65535. Le conflit n'apparaît qu'au moment où le moteur tente d'ouvrir l'écoute, sous la forme de l'erreur système brute : I/O error: Address already in use (os error 48). Un port inférieur à 1024 donne I/O error: Permission denied, ces ports étant réservés à l'administrateur.
Ces deux messages ne sont atteignables par aucun chemin de l'interface aujourd'hui : l'erreur 501 survient avant. Ils sont documentés ici pour que vous les reconnaissiez, y compris quand ils viennent de la commande ssh décrite plus bas.
lsof -nP -iTCP:5432 -sTCP:LISTENL'autorisation système n'est pas en cause. Hawser demande explicitement le droit d'ouvrir un port d'écoute local, sur les deux canaux de distribution, avec la redirection de ports comme justification. macOS ne bloque rien ici.
Écoute locale et exposition au réseau
Le moteur applique une garde par défaut sur les types Local (L) et SOCKS5 (D) : le port d'écoute ne peut être ouvert que sur une adresse de bouclage. Sont acceptés le mot localhost et toute adresse IP de bouclage, soit 127.0.0.0/8 et ::1. Sont refusés 0.0.0.0, ::, une adresse de votre réseau local, et tout nom DNS, même s'il pointe aujourd'hui vers 127.0.0.1 : une résolution peut changer sans prévenir. Le refus se lit refusing to bind local-forward on non-loopback host suivi de l'hôte demandé.
La garde ne s'applique pas au type Remote (R) : dans ce sens, c'est le serveur SSH qui ouvre le port, et c'est sa configuration qui décide de son exposition.
En attendant : monter le tunnel depuis le Terminal
Tant que la vue Tunnels n'est pas raccordée, la commande ssh livrée avec macOS fait le travail. Elle est indépendante de Hawser : le tunnel n'apparaîtra dans aucune vue de l'application, et se ferme quand vous fermez la fenêtre du Terminal.
Les deux autres formes suivent la même logique : ssh -N -R 8080:127.0.0.1:3000 admin@serveur fait écouter le serveur sur son port 8080 et renvoie vers votre port 3000 ; ssh -N -D 1080 admin@serveur ouvre un proxy SOCKS5 local sur le port 1080.
Hawser peut au moins fournir les alias : ⌘K, puis « Exporter en config OpenSSH », produit un fichier nommé ssh_config contenant les lignes Host, HostName, User et Port de vos hôtes SSH. À vous de reporter son contenu dans ~/.ssh/config. Ce fichier ne contient ni IdentityFile, ni clé, ni mot de passe.