rathole-org/ratholeUn proxy inverse léger et haute performance pour la traversée NAT, écrit en Rust. Une alternative à frp et ngrok.
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.
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 :
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
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
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.
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`
[client.transport.noise] # Protocole Noise. Voir `docs/transport.md` pour plus d’explications
pattern = "Noise_NK_25519_ChaChaPoly_BLAKE2s" # Optionnel. Valeur par défaut comme indiqué
local_private_key = "key_encoded_in_base64" # Optionnel
remote_public_key = "key_encoded_in_base64" # Optionnel
[client.transport.websocket] # Nécessaire si `type` est "websocket"
tls = true # Si `true`, alors utilise les paramètres dans `client.transport.tls`
[client.services.service1] # Un service à transférer. Le nom `service1` peut être modifié arbitrairement, tant qu’il est identique au nom dans la configuration du serveur
type = "tcp" # Optionnel. Le protocole à transférer. Valeurs possibles : ["tcp", "udp"]. Par défaut : "tcp"
token = "whatever" # Nécessaire si `client.default_token` n’est pas défini
local_addr = "127.0.0.1:1081" # Nécessaire. L’adresse du service à transférer
nodelay = true # Optionnel. Remplace `client.transport.nodelay` par service
retry_interval = 1 # Optionnel. L’intervalle entre les tentatives de reconnexion au serveur. Par défaut : hérite de la configuration globale
[client.services.service2] # Plusieurs services peuvent être définis
local_addr = "127.0.0.1:1082"
[server]
bind_addr = "0.0.0.0:2333" # Nécessaire. L’adresse sur laquelle le serveur écoute les clients. Généralement seul le port doit être modifié.
default_token = "default_token_if_not_specify" # Optionnel
heartbeat_interval = 30 # Optionnel. L’intervalle entre deux heartbeats au niveau applicatif. Mettre à 0 pour désactiver l’envoi de heartbeat. Par défaut : 30 secondes
[server.transport] # Identique à `[client.transport]`
type = "tcp"
[server.transport.tcp] # Identique au client
nodelay = true
keepalive_secs = 20
keepalive_interval = 8
[server.transport.tls] # Nécessaire si `type` est "tls"
pkcs12 = "identify.pfx" # Nécessaire. Fichier pkcs12 du certificat et de la clé privée du serveur
pkcs12_password = "password" # Nécessaire. Mot de passe du fichier pkcs12
[server.transport.noise] # Identique à `[client.transport.noise]`
pattern = "Noise_NK_25519_ChaChaPoly_BLAKE2s"
local_private_key = "key_encoded_in_base64"
remote_public_key = "key_encoded_in_base64"
[server.transport.websocket] # Nécessaire si `type` est "websocket"
tls = true # Si `true`, alors utilise les paramètres dans `server.transport.tls`
[server.services.service1] # Le nom du service doit être identique à celui du côté client
type = "tcp" # Optionnel. Identique au `[client.services.X.type]` du client
token = "whatever" # Nécessaire si `server.default_token` n’est pas défini
bind_addr = "0.0.0.0:8081" # Nécessaire. L’adresse à laquelle le service est exposé. Généralement seul le port doit être modifié.
nodelay = true # Optionnel. Identique au client
[server.services.service2]
bind_addr = "0.0.0.1:8082"
rathole, comme beaucoup d’autres programmes Rust, utilise des variables d’environnement pour contrôler le niveau de journalisation. info, warn, error, debug, trace sont disponibles.
RUST_LOG=error ./rathole config.toml
exécutera rathole avec uniquement les logs de niveau error.
Si RUST_LOG n’est pas présent, le niveau de journalisation par défaut est info.
Depuis la v0.4.7, rathole active TCP_NODELAY par défaut, ce qui devrait bénéficier à la latence et aux applications interactives comme rdp, les serveurs Minecraft. Cependant, cela diminue légèrement la bande passante.
Si la bande passante est plus importante, TCP_NODELAY peut être désactivé avec nodelay = false.
rathole a une latence similaire à frp, mais peut gérer plus de connexions, fournir une plus grande bande passante, avec une utilisation mémoire moindre.
Pour plus de détails, voir la page séparée Benchmark.
Cependant, ne concluez pas de là que rathole peut rendre magiquement votre service transféré plusieurs fois plus rapide qu’avant. Le benchmark est effectué en boucle locale, ce qui indique les performances lorsque la tâche est limitée par le CPU. On peut obtenir une amélioration notable si le réseau n’est pas le goulot d’étranglement. Malheureusement, ce n’est pas le cas pour beaucoup d’utilisateurs. Dans ce cas, le principal avantage est une consommation de ressources plus faible, tandis que la bande passante et la latence peuvent ne pas s’améliorer significativement.
Hors de portée liste les fonctionnalités qui ne sont pas prévues et pourquoi.