Tunnel de ports

Cet article présente la fonction « Tunnel de ports » du panneau — mapper le port applicatif d'un serveur tunnelisé sans IP publique vers un port public du serveur du panneau, pour le rendre accessible de l'extérieur.

En une phrase

Votre serveur est caché dans un réseau interne (sans IP publique), il y fait tourner un site ou une application, et personne à l'extérieur ne peut y accéder. Le tunnel de ports consiste à « ouvrir un port public sur le serveur du panneau et à acheminer les accès extérieurs, via un tunnel chiffré, jusqu'au port applicatif de votre serveur interne ». Résultat : un visiteur qui ouvre IP du serveur du panneau:port accède à l'application de votre serveur interne.

Présentation de la fonctionnalité

Pour un serveur sans IP publique raccordé via « Tunnel et maintenance », les applications qu'il héberge (Navidrome pour la musique, Nextcloud pour le stockage, Memos pour les notes, par exemple) ne sont pas accessibles de l'extérieur. Le tunnel de ports mappe ces ports applicatifs vers un port du serveur du panneau (qui a une IP publique), pour que les utilisateurs externes y accèdent via « IP du serveur du panneau:port ».

Cas d'usage

• Une application Web tourne sur le serveur tunnelisé et vous voulez y accéder de l'extérieur
• Exposer le service d'un appareil du réseau interne sur l'Internet public
• Donner un point d'entrée public à un site, une API ou un panneau hébergé sur un appareil sans IP publique

Principe (circulation des données)

utilisateur externe → port public du serveur du panneau (ex. :9117) → tunnel chiffré → port applicatif du serveur tunnelisé (ex. :9117)

Le trafic externe atteint d'abord le serveur du panneau (seul endroit disposant d'une IP publique), puis passe par un tunnel inverse chiffré jusqu'à l'appareil du réseau interne, et arrive enfin sur le port applicatif réellement à l'écoute sur l'appareil.

Canal unifié (pour tous les appareils, sans choix manuel) :

Le panneau utilise uniformément le tunnel inverse 4433 : à la création d'un tunnel, aucun choix manuel du canal sous-jacent n'est nécessaire.

> Complément : la gestion système des appareils Android/Termux (exécution de commandes, terminal, fichiers) passe par le canal stable SocketIO ; le tunnel de ports, lui, utilise uniformément le tunnel inverse 4433. Chacun son rôle, sans interférence.

Comment l'utiliser

1. Vérifiez que l'appareil cible est déjà raccordé via « Tunnel et maintenance » (Agent en ligne)

2. Ouvrez « Tunnel de ports » et cliquez sur « Ajouter un tunnel »

3. Sélectionnez le serveur tunnelisé (Agent) et renseignez :

• Port d'écoute : le port public du serveur du panneau (pour l'accès externe), par exemple 9117
• Port cible : le port applicatif sur le serveur tunnelisé, par exemple 8080

4. Une fois créé, l'extérieur peut accéder à http://IP du serveur du panneau:port d'écoute

Exemple

Supposons que le serveur du panneau ait l'IP publique 203.0.113.10 et qu'un Raspberry Pi de votre réseau interne fasse tourner Navidrome (écoute 4533) :

• Port d'écoute : 4533
• Port cible : 4533
• Après création, un utilisateur externe ouvre http://203.0.113.10:4533 pour atteindre Navidrome sur le Raspberry Pi

Limites de ressources

Au-delà, les nouvelles connexions sont automatiquement refusées, sans impact sur les tunnels déjà en service.

Points d'attention

1. Pare-feu cloud : le pare-feu cloud / le groupe de sécurité du serveur du panneau doit laisser passer le port d'écoute correspondant, sinon l'accès externe est impossible.

2. Version de l'Agent : rediriger un port autre que SSH (autre que 22) exige que le serveur tunnelisé ait une version récente de l'Agent (les anciennes versions ne redirigent que le port 22). Pour rediriger d'autres ports, réinstallez l'Agent.

3. Agent en ligne : le tunnel dépend de la présence de l'Agent. Si l'Agent passe hors ligne, le tunnel est interrompu puis rétabli automatiquement à la reconnexion.

4. Reprise automatique après redémarrage du panneau : après un redémarrage du service du panneau, les tunnels sont automatiquement rétablis (déclenché par la reconnexion de l'Agent).

5. Le service cible sous Android doit gérer la concurrence : si le service ciblé sur Android (comme python3 -m http.server) est mono-thread avec keep-alive activé, une connexion non fermée bloque les requêtes suivantes. Privilégiez un service cible multi-thread, ou assurez-vous que les connexions se ferment rapidement.

Documentation associée

• Tunnel et maintenance — raccorder d'abord au panneau les appareils sans IP publique
• Redirection de ports — la redirection de ports classique pour les serveurs avec IP publique (voir la différence ci-dessous)

Tunnel de ports vs Redirection de ports (que choisir)

En une phrase : sans IP publique, utilisez le tunnel ; avec IP publique, utilisez la redirection.