rathole

English | 简体中文

Un proxy inverse sécurisé, stable et haute performance pour le franchissement de NAT, écrit en Rust

rathole, comme frp et ngrok, peut aider à exposer le service sur l'appareil derrière le NAT vers Internet, via un serveur avec une IP publique.

• rathole
  • Fonctionnalités
  • Démarrage rapide
  • Configuration
    • Journalisation
    • Réglage
  • Benchmark
  • À venir

Fonctionnalités

• Haute performance Un débit bien supérieur à frp peut être atteint, et plus stable lors du traitement d’un grand nombre de connexions. Voir Benchmark
• Faible consommation de ressources Consomme beaucoup moins de mémoire que des outils similaires. Voir Benchmark. Le binaire peut être aussi petit que ~500 KiB pour s’adapter aux contraintes des appareils, comme les appareils embarqués tels que les routeurs.
• Sécurité Les jetons des services sont obligatoires et spécifiques à chaque service. Le serveur et les clients sont responsables de leurs propres configurations. Avec le protocole Noise optionnel, le chiffrement peut être configuré facilement. Pas besoin de créer un certificat auto-signé ! TLS est également pris en charge.
• Rechargement à chaud Les services peuvent être ajoutés ou supprimés dynamiquement en rechargeant à chaud le fichier de configuration. L’API HTTP est en cours de développement.

Démarrage rapide

Un rathole complet peut être obtenu depuis la page release. Ou compiler à partir des sources pour d’autres plateformes et pour minimiser le binaire. Une image Docker est également disponible.

L’utilisation de rathole est très similaire à frp. Si vous avez de l’expérience avec ce dernier, la configuration est très simple pour vous. La seule différence est que la configuration d’un service est divisée en côté client et côté serveur, et qu’un jeton est obligatoire.

Pour utiliser rathole, vous avez besoin d’un serveur avec une IP publique, et d’un appareil derrière le NAT, où se trouvent des services à exposer sur Internet.

Supposons que vous ayez un NAS à la maison derrière le NAT et que vous souhaitiez exposer son service SSH sur Internet :

1. Sur le serveur qui a une IP publique

Créez server.toml avec le contenu suivant et adaptez-le à vos besoins.

# server.toml
[server]
bind_addr = "0.0.0.0:2333" # `2333` spécifie le port sur lequel rathole écoute les clients

[server.services.my_nas_ssh]
token = "use_a_secret_that_only_you_know" # Jeton utilisé pour authentifier le client pour le service. Remplacez par une valeur arbitraire.
bind_addr = "0.0.0.0:5202" # `5202` spécifie le port qui expose `my_nas_ssh` sur Internet

Ensuite exécutez :

./rathole server.toml

2. Sur l’hôte derrière le NAT (votre NAS)

Créez client.toml avec le contenu suivant et adaptez-le à vos besoins.

# client.toml
[client]
remote_addr = "myserver.com:2333" # L’adresse du serveur. Le port doit être le même que le port dans `server.bind_addr`

[client.services.my_nas_ssh]
token = "use_a_secret_that_only_you_know" # Doit être identique à celui du serveur pour passer la validation
local_addr = "127.0.0.1:22" # L’adresse du service à transférer

Ensuite exécutez :

./rathole client.toml

3. Maintenant, le client va tenter de se connecter au serveur myserver.com sur le port 2333, et tout le trafic vers myserver.com:5202 sera transféré vers le port 22 du client.

Ainsi vous pouvez ssh myserver.com:5202 pour vous connecter en SSH à votre NAS.

Pour exécuter rathole en tant que service d’arrière-plan sous Linux, consultez les exemples systemd.

Configuration

rathole peut déterminer automatiquement s’il doit s’exécuter en mode serveur ou client, selon le contenu du fichier de configuration, si un seul des blocs [server] et [client] est présent, comme dans l’exemple du Démarrage rapide.

Mais les blocs [client] et [server] peuvent aussi être placés dans un même fichier. Alors, côté serveur, exécutez rathole --server config.toml et côté client, exécutez rathole --client config.toml pour indiquer explicitement à rathole le mode d’exécution.

Avant de passer à la spécification complète de la configuration, il est recommandé de parcourir les exemples de configuration pour se faire une idée du format de configuration.

Voir Transport pour plus de détails sur le chiffrement et le bloc transport.

Voici la spécification complète de la configuration :

[client]
remote_addr = "example.com:2333" # Nécessaire. L’adresse du serveur
default_token = "default_token_if_not_specify" # Optionnel. Le jeton par défaut des services, s’ils n’en définissent pas
heartbeat_timeout = 40 # Optionnel. Mettre à 0 pour désactiver le test de heartbeat au niveau applicatif. La valeur doit être supérieure à `server.heartbeat_interval`. Par défaut : 40 secondes
retry_interval = 1 # Optionnel. L’intervalle entre les tentatives de reconnexion au serveur. Par défaut : 1 seconde

[client.transport] # Tout le bloc est optionnel. Spécifie le transport à utiliser
type = "tcp" # Optionnel. Valeurs possibles : ["tcp", "tls", "noise"]. Par défaut : "tcp"

[client.transport.tcp] # Optionnel. Affecte également `noise` et `tls`
proxy = "socks5://user:[email protected]:1080" # Optionnel. Le proxy utilisé pour se connecter au serveur. `http` et `socks5` sont supportés.
nodelay = true # Optionnel. Détermine s’il faut activer TCP_NODELAY, si applicable, pour améliorer la latence mais diminuer la bande passante. Par défaut : true
keepalive_secs = 20 # Optionnel. Spécifie `tcp_keepalive_time` dans `tcp(7)`, si applicable. Par défaut : 20 secondes
keepalive_interval = 8 # Optionnel. Spécifie `tcp_keepalive_intvl` dans `tcp(7)`, si applicable. Par défaut : 8 secondes

[client.transport.tls] # Nécessaire si `type` est "tls"
trusted_root = "ca.pem" # Nécessaire. Le certificat de l’autorité de certification qui a signé le certificat du serveur
hostname = "example.com" # Optionnel. Le nom d’hôte que le client utilise pour valider le certificat. S’il n’est pas défini, on utilise `client.remote_addr`