J’ai créé un service de tunnel SSH qui attribue une URL HTTPS permanente à un serveur local sans configuration du routeur
(natnest.site)Lien du service : https://natnest.site
Code source du client : https://github.com/litdemon/natnest-client
Bonjour. J’ai créé NatNest, un service basé sur des tunnels SSH inversés qui expose un serveur local vers l’extérieur.
run local server 8080
natnest 8080 → https://yourname.natnest.site
Pourquoi je l’ai créé
J’ai un Mac mini à la maison, sur lequel je fais tourner Ollama.
Je voulais aussi l’utiliser à l’extérieur, mais la configuration du port forwarding était un obstacle à chaque fois.
Je passais par la page d’administration du routeur pour ouvrir un port et m’en servir.
Puis, en utilisant Dialogflow de Google, j’ai eu besoin d’enregistrer un Webhook (fulfillment).
HTTPS était obligatoire, et il a fallu préparer un domaine et un certificat, lancer Nginx, puis créer et raccorder un reverse proxy.
D’autres développeurs devaient faire exactement le même travail que moi dans la même situation. Il fallait l’expliquer, et puis je me suis dit :
« Pourquoi ne pas le créer directement ? » C’est ainsi qu’est né NatNest.
Je n’ai pas seulement créé le client. NatNest est un ensemble composé de plusieurs serveurs et composants, comme Nginx + Lua, Redis, une base de données, un serveur API, un tunnel-server (serveur SSH), etc.
En le développant, j’ai découvert qu’il existait déjà des services équivalents avec ngrok et Cloudflare Tunnel...
Comment ça fonctionne ?
Quand le client (CLI) établit un tunnel SSH inversé vers le serveur, celui-ci enregistre dans Redis le mapping sous-domaine → port interne. Ensuite, lorsqu’une requête arrive de l’extérieur sur https://yourname.natnest.site, OpenResty (Nginx + Lua) interroge Redis et la proxy vers le port du tunnel SSH correspondant.
Requête externe → [Nginx + Lua] → consultation Redis → port du tunnel SSH → serveur local
Le client maintient la connexion SSH grâce à un processus watchdog en arrière-plan, ce qui permet une reconnexion automatique en moins de 5 secondes même si vous fermez le terminal ou si le réseau est brièvement interrompu.
Quelle différence avec ngrok / Cloudflare Tunnel ?
NatNest : URL permanente, auto-hébergement, visualiseur de logs de webhook
Ngrok Free : URL permanente (❌), pas d’auto-hébergement, visualiseur de logs de webhook (Pro et plus)
Cloudflare Tunnel : URL permanente (❌), Pro et plus, aucun (❌)
C’est une solution pensée pour les personnes qui, comme moi, veulent « une URL permanente gratuite, avec des données hébergées sur leur propre serveur ».
Le plus grand avantage, c’est
de disposer d’une solution capable de fournir un service similaire à ngrok,
et de pouvoir appliquer immédiatement les bonnes idées proposées dans les commentaires ci-dessous avec beaucoup d’agilité.
C’est vraiment une première étape pour intégrer les fonctionnalités que les développeurs veulent réellement.
État actuel et limites en toute transparence
À partir de la version v0.5.1, les fonctionnalités suivantes sont disponibles :
- liaison avec un compte Google (OAuth Device Flow) + génération automatique de clé SSH
- sous-domaine permanent + renouvellement automatique du HTTPS wildcard Let’s Encrypt
- dashboard web (liste des tunnels actifs, logs de webhook en temps réel)
- binaires client pour Linux (amd64·arm64), macOS et Windows
Il reste aussi des points à améliorer :
- l’automatisation CI/CD des builds Windows n’est pas terminée (build manuel actuellement)
- le serveur est un serveur unique exploité depuis mon domicile, donc il y a de la latence
- j’exploite le service seul, donc il est difficile de garantir une stabilité de niveau service (SLA)
Pour l’essayer
Linux / macOS
curl -fsSL https://natnest.site/install.sh | bash
natnest setup # liaison avec un compte Google
natnest 8080 # expose le port local 8080 vers l’extérieur
C’est la première fois que je le rends public, donc si vous avez des retours d’expérience ou des idées du type « ce serait bien d’avoir cette fonctionnalité », je vous serais vraiment reconnaissant de les laisser en commentaire.
4 commentaires
La commande d’installation et le lien GitHub en haut de la page d’accueil renvoient une erreur 404.
Merci pour votre commentaire. J’ai appliqué la correction.
Le problème plus important semble être ce changement de design qui, à première vue, donne clairement l’impression d’avoir été fait par une IA.
https://github.com/anderspitman/awesome-tunneling
Awesome Tunneling - liste d’alternatives à ngrok
La demande pour les solutions de type tunnel est forte, donc il en existe beaucoup. Cela peut valoir le coup de regarder ce que proposent les autres services pour s’en inspirer.
Ça a l’air pas mal. De quoi échapper à l’enfer de la configuration.