L'Edge Minimaliste : Micro-Proxys en Rust et Go

Il existe une tendance niche mais très passionnée dans la communauté infrastructure : les développeurs remplacent systématiquement les services proxy commerciaux lourds par des outils open-source ultra-minimalistes écrits en Rust et Go. Depuis des années, la réponse par défaut pour exposer un serveur de développement local ou contourner le NAT de niveau carrier (CGNAT) était de faire appel à un nom connu. Mais à mesure que ces plateformes évoluent vers des fonctionnalités d’entreprise, leurs agents deviennent plus lourds et leurs niveaux gratuits plus restrictifs.

Entrez le micro-proxy.

Écrire sur des outils open-source comme bore, rathole, et chisel plaît énormément aux amateurs de home-lab, aux hobbyistes IoT, et aux développeurs edge computing — ceux qui gèrent des tunnels sur des appareils à faible mémoire comme Raspberry Pi, où chaque mégaoctet de RAM compte. En s’appuyant sur la sécurité mémoire de Rust ou la compilation statique de Go, ces micro-proxys offrent des alternatives rapides, auto-hébergées, qui remettent le contrôle entre les mains du développeur.

La Quête d’une Alternative Légère à Ngrok

Si vous avez déjà eu besoin de montrer une application web locale à un client, tester un webhook, ou accéder à votre serveur maison depuis un café, vous avez utilisé un service de tunneling. Ceux-ci fonctionnent en exécutant un agent sur votre machine locale qui se connecte à un serveur cloud public, traversant votre pare-feu local. Le serveur cloud vous fournit une URL publique et redirige le trafic entrant via ce tunnel.

Les solutions commerciales sont peaufinées, mais elles ont des compromis :

• Limites de connexion et de bande passante. Les niveaux gratuits limitent souvent la bande passante, le nombre de connexions simultanées, ou expirent les sessions inactives.
• Paywalls pour fonctionnalités. Tunnels TCP bruts pour SSH ou base de données, ou un domaine personnalisé persistant, sont souvent derrière un abonnement.
• Gonflement de l’agent. Les agents commerciaux intègrent des fonctionnalités de conformité, des auto-mise à jour, et des composants UI qui consomment des ressources sur de petits appareils edge.
• Confidentialité et contrôle. Routage du trafic local non chiffré via un serveur tiers introduit un point d’interception.

Cela a créé une demande pour quelque chose pouvant être hébergé sur un VPS bon marché, déployé en un seul binaire, et laissé en fonctionnement indéfiniment. Regardons trois outils qui comblent cette niche — et, surtout, ce que chacun garantit réellement concernant votre trafic une fois qu’il quitte votre machine, puisque c’est là que la communication marketing de ces projets peut dépasser les paramètres par défaut.

1. Bore : Le Tunnel TCP Rust Ridiculement Simple

Si votre objectif est une simplicité absolue, bore est fait pour vous. Créé par Eric Zhang, c’est un tunnel TCP moderne, simple, en Rust, qui expose des ports locaux à un serveur distant, contournant les pare-feux NAT standards — ab conçu pour être un outil très efficace, non-opinionné, pour transférer du trafic TCP, facile à installer et à auto-héberger, sans fioritures bb. À l’écriture de cet article, il a 11,4k étoiles sur GitHub, 514 forks, et est sous licence MIT, en version 0.6.0 sur crates.io.

Fonctionnement de Bore

Bore est fortement non-opinionné. ab Le projet totalise environ 400 lignes de code Rust asynchrone, sécurisé, et est trivial à configurer — il suffit de lancer un seul binaire pour le client et le serveur. bb Il ne gère pas les certificats TLS, n’offre pas de tableau de bord, et n’inspecte pas votre trafic HTTP. Il transfère simplement des octets de A à B, utilisant un port de contrôle implicite à 7835 pour négocier de nouvelles connexions entre client et serveur.

Correction importante dès le départ : bore *n*’encrypte pas votre trafic par défaut, et le brouillon de cet article laissait entendre le contraire par omission. Bore supporte une option --secret, mais selon la documentation officielle, ce secret ne sert qu’à authentifier la poignée de main — il n’encrypte pas la couche de données. Selon la section d’authentification du projet : le protocole requiert que les clients vérifient la possession du secret via des défis HMAC à chaque connexion, mais “aucun trafic supplémentaire n’est chiffré par défaut.” Si vous transférez des données sensibles via bore, vous devrez ajouter TLS vous-même (voir la section sécurité ci-dessous).

Configuration Rapide

cargo install bore-cli

Pour exposer un serveur web local sur le port 8000 :

bore local 8000 --to bore.pub

Le terminal retourne un port distant aléatoire à bore.pub. Vous pouvez fixer un port spécifique avec --port, et exposer un hôte LAN autre que localhost avec --local-host.

Pour auto-héberger, lancez bore server sur votre VPS (optionnellement avec --secret pour l’authentification de la poignée de main, et --min-port/--max-port pour limiter la plage exposée), puis pointez le drapeau --to de votre client local vers l’adresse de votre VPS. C’est un outil prêt à l’emploi quand vous avez besoin d’un tunnel immédiat et que vous ne souhaitez pas écrire de fichier de configuration.

2. Rathole : Traversée NAT Haute Performance en Rust

Si bore est idéal pour des tests rapides et éphémères, rathole vise quelque chose de plus permanent : exposer en toute sécurité un NAS domestique ou un réseau de capteurs IoT en continu. Une note importante — le dépôt a changé d’organisation, passant de rapiz1/rathole à rathole-org/rathole (l’ancienne URL redirige encore via GitHub). Il compte environ 14k étoiles, 809 forks, sous licence Apache-2.0, et se décrit comme ab un proxy inverse léger et haute performance pour la traversée NAT, écrit en Rust, une alternative à frp et ngrok bb.

Le Modèle de Sécurité — et une Correction

C’est la deuxième fois que le brouillon initial exagère. Le README de Rathole mentionne le support du Noise Protocol : ab Les tokens de service sont obligatoires, et avec le Noise Protocol optionnel, l’encryption peut être configurée facilement, sans créer de certificat auto-signé — TLS est aussi supporté bb. Mais deux détails importants :

1. Le champ token sert à l’authentification du service, pas à l’encryption du transport. Il prouve qu’un client est autorisé à se connecter à un service donné ; il ne chiffre pas les octets en transit.
2. L’encryption est optionnelle, pas automatique. À moins d’ajouter explicitement un bloc [client.transport] / [server.transport] avec type = "noise" (ou "tls"), Rathole par défaut utilise type = "tcp" en clair — trafic non chiffré par défaut, comme bore. Le bloc Noise nécessite aussi une paire local_private_key/remote_public_key (ou le pattern par défaut Noise_NK_25519_ChaChaPoly_BLAKE2s) — il n’est pas activé simplement en définissant un token.

La prétention précédente selon laquelle “le trafic est automatiquement chiffré de bout en bout” dès que vous définissez un token partagé est donc inexacte. Voici un exemple de configuration qui active réellement le chiffrement.

Configuration via TOML

server.toml sur votre VPS :

[server]
bind_addr = "0.0.0.0:2333"

[server.transport]
type = "noise"

[server.services.my_ssh]
token = "super_secret_string"
bind_addr = "0.0.0.0:5202"

client.toml sur votre serveur maison :

[client]
remote_addr = "vps_ip_address:2333"

[client.transport]
type = "noise"

[client.services.my_ssh]
token = "super_secret_string"
local_addr = "127.0.0.1:22"

Sans le bloc [transport] des deux côtés, cela revient à un TCP brut, non authentifié — correct pour un test local rapide, mais pas pour traverser Internet. Rathole supporte aussi les services UDP (type = "udp" sous un bloc de service) et le rechargement à chaud du fichier de config sans redémarrer le processus. Selon ses docs de benchmark : ab Rathole peut atteindre un débit bien supérieur à frp et est plus stable avec de nombreux connexions, tout en consommant beaucoup moins de mémoire bb, avec des binaires aussi petits que ~500KiB.

3. Chisel : Le Tunnel SSH Polyvalent en Go

Pour des environnements d’entreprise très restrictifs ou des besoins de proxy complexes, chisel est l’option en Go. En version v1.11.5 (sortie mars 2026), avec 16,1k étoiles, 1,6k forks, sous licence MIT, il se décrit ainsi : ab un tunnel TCP/UDP rapide, transporté via HTTP, sécurisé par SSH, un seul exécutable incluant client et serveur, écrit en Go bb.

Contrairement à bore et rathole, chisel garantit la sécurité dès la sortie de la boîte — c’est la seule où la confiance initiale était justifiée, et il est important de le préciser : le chiffrement est toujours activé. Lors du démarrage, le serveur chisel génère une paire de clés ECDSA en mémoire (ou charge une clé depuis --keyfile) et sécurise tout le trafic avec elle via crypto/ssh de Go. La clé publique est affichée au démarrage ; les clients doivent vérifier cette empreinte avec --fingerprint pour éviter un MITM.

Contournement des Pare-feux Restrictifs

Le secret réside dans la couche de transport. Beaucoup de réseaux d’entreprise bloquent le TCP brut ou le trafic SSH, mais presque jamais le trafic HTTP/HTTPS standard. Chisel encapsule son tunnel TCP/UDP dans HTTP, en passant à WebSockets — ainsi, à un pare-feu restrictif, un tunnel chisel ressemble à du trafic web ordinaire. Une fois arrivé au serveur chisel, la charge utile est sécurisée par le protocole SSH en dessous.

Configuration

chisel server -p 8080 --reverse

Sur la machine locale restreinte :

chisel client https://your-vps-domain.com R:80:localhost:3000

Cette seule commande ouvre une connexion HTTP, négocie une session sécurisée SSH, et reverse-redirige le port local 3000 vers le port 80 du serveur. Chisel supporte aussi un mode proxy SOCKS5 (--socks5 sur le serveur, un socks distant sur le client), une authentification par mot de passe via --authfile, et la terminaison TLS native avec certificats Let’s Encrypt via --tls-domain — une fonctionnalité non mentionnée dans le brouillon initial, mais essentielle si vous souhaitez que chisel termine lui-même le HTTPS plutôt que de passer par Nginx ou Caddy. Le support UDP est arrivé en v1.7.

Comparatif : bore vs. rathole vs. chisel

Le débat “bore vs rathole” est courant chez les amateurs de Rust ; chisel se distingue dans sa propre catégorie pour l’évasion des pare-feux. Le tableau ci-dessous est la pièce manquante du brouillon initial — une comparaison côte à côte de ce que vous obtenez par défaut, avant toute configuration supplémentaire :

	Bore	Rathole	Chisel
Langage	Rust	Rust	Go
Chiffrement par défaut	Non	Non (optionnel via Noise/TLS)	Oui (toujours ECDSA/SSH)
Format de config	Flags CLI	Fichier TOML	Flags CLI
Support UDP	Non	Oui	Oui
Idéal pour	Tunnels jetables instantanés	Services persistants à haut débit	Traverser des pare-feux HTTP uniquement
Licence	MIT	Apache-2.0	MIT

Verdict : utilisez bore pour un tunnel jetable sans configuration, en ajoutant votre propre TLS si nécessaire. Rathole pour une infrastructure persistante à faible ressource dans un home-lab — mais activez explicitement le transport Noise. Chisel quand vous êtes derrière un pare-feu HTTP strict et que vous souhaitez un chiffrement sans configuration supplémentaire.

Tutoriel : Configurer un Tunnel Localhost sur Raspberry Pi

Des millions de hobbyistes hébergent des services personnels sur Raspberry Pi. Le problème : la plupart des connexions résidentielles sont derrière CGNAT, sans IP publique pour faire du port forwarding. Voici rathole, utilisé correctement — avec le transport Noise activé cette fois.

Étape 1 — Préparer le serveur (VPS)

Téléchargez le binaire rathole depuis la page officielle des releases. Créez server.toml :

[server]
bind_addr = "0.0.0.0:2333"

[server.transport]
type = "noise"

[server.services.pi_web]
token = "MySecureToken123!"
bind_addr = "0.0.0.0:8080"

Lancez : ./rathole server.toml

Étape 2 — Préparer le client (Raspberry Pi)

Téléchargez le binaire ARM (Rust compile propre pour ARM). Créez client.toml :

[client]
remote_addr = "VPS_IP:2333"

[client.transport]
type = "noise"

[client.services.pi_web]
token = "MySecureToken123!"
local_addr = "127.0.0.1:80"

Lancez : ./rathole client.toml

Comme seul [client] ou [server] apparaît dans chaque fichier, Rathole détecte automatiquement le mode — pas besoin de l’option --client/--server sauf si les deux blocs sont dans un seul fichier.

Étape 3 — Persistance avec systemd

Créez /etc/systemd/system/rathole.service :

[Unit]
Description=Rathole Client Tunnel
After=network.target

[Service]
Type=simple
User=pi
ExecStart=/home/pi/rathole /home/pi/client.toml
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Activez et démarrez :

sudo systemctl enable rathole
sudo systemctl start rathole

(Le projet fournit aussi des exemples de fichiers systemd dans examples/systemd ; à vérifier selon votre configuration pour des options comme LimitNOFILE.)

Accéder à http://YOUR_VPS_IP:8080 route maintenant via le tunnel chiffré Noise jusqu’au Pi.

Considérations de Sécurité pour les Edge Proxies

En remplaçant des outils commerciaux par des binaires auto-hébergés, vous prenez en charge la responsabilité qu’ils géraient pour vous. Avec les corrections ci-dessus, cette liste doit être plus précise que “restez à jour” :

• Ne supposez pas un chiffrement que vous n’avez pas configuré. Bore et rathole transmettent tous deux en clair par défaut. Si vous transférez SSH, ce protocole interne est toujours chiffré — mais si vous exposez un panneau d’administration HTTP ou un port de base de données non chiffré, quiconque sur le chemin peut le lire. Chisel est le seul des trois à chiffrer par défaut.
• Ne mettez pas en ligne des services non authentifiés. Si votre app locale n’a pas de login, ne la mettez pas sur un port public en clair. Les bots trouvent des ports ouverts en quelques minutes.
• Mettez un vrai reverse proxy devant le port exposé. Faites tourner Nginx ou Caddy sur votre VPS, terminez TLS avec Let’s Encrypt sur le port 443, et proxy en interne vers bore/rathole/chisel plutôt que d’exposer directement leurs ports (le --tls-domain intégré de chisel peut faire office si vous ne souhaitez pas une couche proxy séparée).
• Figez les empreintes si l’outil le supporte. Le flag --fingerprint de chisel est la différence entre “chiffré” et “chiffré et vérifié” — le sauter vous expose à un MITM lors de la première connexion.
• Restez à jour. Rust et Go éliminent toute une classe de bugs liés à la sécurité mémoire, mais les bugs logiques dans le tunneling (bypass d’authentification, confusion de port) peuvent encore arriver. Surveillez les pages de release — par exemple, chisel en est à sa 35e version taguée (v1.11.5).

Conclusion

Le paysage de l’infrastructure traverse une renaissance minimaliste, et les trois outils ci-dessus sont de véritables bonnes options — bore pour des tunnels jetables, rathole pour une infrastructure home-lab persistante, chisel pour des environnements à pare-feu hostile. Mais “auto-hébergé” et “sécurisé par défaut” ne sont pas la même chose, et deux de ces trois outils ne chiffrent pas par défaut — il faut l’activer. Ce n’est pas une critique, mais une conséquence d’un binaire de 400 lignes sans fioritures — mais c’est un détail important à connaître avant de pointer l’un vers quelque chose d’important.

---

Historique des Modifications

Corrections et ajouts vérifiés auprès des sources officielles (dépôts GitHub, READMEs, pages de release) en août 2026 :

1. Correction des affirmations sur le chiffrement de bore par omission. Le brouillon initial n’indiquait pas que bore n’a pas de chiffrement par défaut ; ajout d’une correction explicite citant la section d’authentification de bore, qui indique que l’option --secret ne couvre que la poignée de main (“aucun trafic supplémentaire n’est chiffré par défaut”). Source : github.com/ekzhang/bore.
2. Correction de la sécurité principale de rathole. Le brouillon disait que le trafic est “automatiquement chiffré de bout en bout” une fois un token partagé défini. Cela mélange le token de service obligatoire (authentification) avec le transport optionnel Noise (chiffrement), qui doit être explicitement configuré via un [transport] avec type = "noise" et est désactivé par défaut. Mise à jour des exemples de config et du tutoriel Raspberry Pi pour activer Noise correctement. Source : rathole-org/rathole README et docs/transport.md.
3. Mise à jour du dépôt principal de rathole. Le projet a été transféré de rapiz1/rathole à rathole-org/rathole ; lien principal mis à jour.
4. Ajout des statistiques actuelles vérifiées. Nombre d’étoiles/forks et licences pour bore (11,4k étoiles, 514 forks, MIT), rathole (~14k étoiles, 809 forks, Apache-2.0), chisel (16,1k étoiles, 1,6k forks, MIT, v1.11.5). Sources : pages GitHub respectives.
5. Clarification du modèle de sécurité de chisel. Confirmé que chisel chiffre toujours par défaut (clé ECDSA en mémoire ou fichier via crypto/ssh), avec mention du --fingerprint pour éviter MITM et du --tls-domain pour l’automatisation Let’s Encrypt, non dans le brouillon initial. Source : jpillora/chisel README, sections Sécurité et Usage.
6. Ajout du support UDP et du rechargement à chaud pour rathole, et du support UDP dans chisel (introduit en v1.7). Non mentionné dans le brouillon initial.
7. Correction de la ligne ExecStart dans le tutoriel Raspberry Pi. La version initiale utilisait --client /home/pi/client.toml ; puisque le fichier ne contient qu’un bloc [client], Rathole détecte automatiquement le mode, donc l’option est superflue.
8. Ajout des détails sur le port de contrôle et la CLI de bore. (Port 7835, --local-host, --min-port/--max-port) directement issus du README.
9. Réécriture de la section Sécurité pour refléter la posture par défaut corrigée, avec un tableau comparatif des configurations de sécurité par défaut — absent du brouillon initial.
10. Suppression de tout frontmatter/metadata. Livraison en Markdown propre.