rathole-org/ratholeUn proxy inverso leggero e ad alte prestazioni per l'attraversamento NAT, scritto in Rust. Un'alternativa a frp e ngrok.
Un proxy inverso sicuro, stabile e ad alte prestazioni per l'attraversamento NAT, scritto in Rust.
rathole, come frp e ngrok, può aiutare a esporre su Internet un servizio su un dispositivo dietro NAT, tramite un server con IP pubblico.
Un rathole completo si può ottenere dalla pagina delle release. Oppure compilare dal sorgente per altre piattaforme e per minimizzare il binario. È disponibile anche un'immagine Docker.
L'uso di rathole è molto simile a frp. Se hai esperienza con quest'ultimo, la configurazione è molto facile. L'unica differenza è che la configurazione di un servizio è divisa tra client e server, e un token è obbligatorio.
Per usare rathole, hai bisogno di un server con IP pubblico e di un dispositivo dietro NAT, dove si trovano alcuni servizi da esporre su Internet.
Supponendo di avere un NAS a casa dietro NAT e di voler esporre il suo servizio SSH su Internet:
Crea server.toml con il seguente contenuto e adattalo alle tue esigenze.
# server.toml
[server]
bind_addr = "0.0.0.0:2333" # `2333` specifica la porta su cui rathole ascolta i client
[server.services.my_nas_ssh]
token = "use_a_secret_that_only_you_know" # Token usato per autenticare il client per il servizio. Modificalo con un valore a piacere.
bind_addr = "0.0.0.0:5202" # `5202` specifica la porta che espone `my_nas_ssh` su Internet
Quindi esegui:
./rathole server.toml
Crea client.toml con il seguente contenuto e adattalo alle tue esigenze.
# client.toml
[client]
remote_addr = "myserver.com:2333" # L'indirizzo del server. La porta deve essere uguale a quella in `server.bind_addr`
[client.services.my_nas_ssh]
token = "use_a_secret_that_only_you_know" # Deve essere uguale a quella del server per superare la validazione
local_addr = "127.0.0.1:22" # L'indirizzo del servizio da inoltrare
Quindi esegui:
./rathole client.toml
myserver.com sulla porta 2333, e tutto il traffico verso myserver.com:5202 sarà inoltrato alla porta 22 del client.Così puoi ssh myserver.com:5202 per SSH al tuo NAS.
Per eseguire rathole come servizio in background su Linux, guarda gli esempi systemd.
rathole può determinare automaticamente se eseguire in modalità server o client in base al contenuto del file di configurazione, se è presente solo uno dei blocchi [server] e [client], come nell'esempio in Avvio rapido.
Ma i blocchi [client] e [server] possono anche essere inseriti in un unico file. In tal caso, sul lato server esegui rathole --server config.toml e sul lato client esegui rathole --client config.toml per indicare esplicitamente a rathole la modalità di esecuzione.
Prima di passare alla specifica completa della configurazione, si consiglia di dare un'occhiata agli esempi di configurazione per farsi un'idea del formato.
Vedi Trasporto per maggiori dettagli sulla crittografia e il blocco transport.
Ecco la specifica completa della configurazione:
[client]
remote_addr = "example.com:2333" # Necessario. L'indirizzo del server
default_token = "default_token_if_not_specify" # Opzionale. Il token predefinito per i servizi, se non ne definiscono uno proprio
heartbeat_timeout = 40 # Opzionale. Imposta a 0 per disabilitare il test heartbeat a livello applicativo. Il valore deve essere maggiore di `server.heartbeat_interval`. Default: 40 secondi
retry_interval = 1 # Opzionale. L'intervallo tra i tentativi di connessione al server. Default: 1 secondo
[client.transport] # L'intero blocco è opzionale. Specifica quale trasporto usare
type = "tcp" # Opzionale. Valori possibili: ["tcp", "tls", "noise"]. Default: "tcp"
[client.transport.tcp] # Opzionale. Ha effetto anche su `noise` e `tls`
proxy = "socks5://user:[email protected]:1080" # Opzionale. Il proxy per connettersi al server. Supporta `http` e `socks5`.
nodelay = true # Opzionale. Determina se abilitare TCP_NODELAY, se applicabile, per migliorare la latenza riducendo la larghezza di banda. Default: true
keepalive_secs = 20 # Opzionale. Specifica `tcp_keepalive_time` in `tcp(7)`, se applicabile. Default: 20 secondi
keepalive_interval = 8 # Opzionale. Specifica `tcp_keepalive_intvl` in `tcp(7)`, se applicabile. Default: 8 secondi
[client.transport.tls] # Necessario se `type` è "tls"
trusted_root = "ca.pem" # Necessario. Il certificato della CA che ha firmato il certificato del server
hostname = "example.com" # Opzionale. Il nome host che il client usa per validare il certificato. Se non impostato, utilizza `client.remote_addr`
[client.transport.noise] # Protocollo Noise. Vedi `docs/transport.md` per ulteriori spiegazioni
pattern = "Noise_NK_25519_ChaChaPoly_BLAKE2s" # Opzionale. Il valore predefinito come mostrato
local_private_key = "key_encoded_in_base64" # Opzionale
remote_public_key = "key_encoded_in_base64" # Opzionale
[client.transport.websocket] # Necessario se `type` è "websocket"
tls = true # Se `true` userà le impostazioni in `client.transport.tls`
[client.services.service1] # Un servizio da inoltrare. Il nome `service1` può essere cambiato arbitrariamente, purché identico al nome nella configurazione del server
type = "tcp" # Opzionale. Il protocollo da inoltrare. Valori possibili: ["tcp", "udp"]. Default: "tcp"
token = "whatever" # Necessario se `client.default_token` non è impostato
local_addr = "127.0.0.1:1081" # Necessario. L'indirizzo del servizio da inoltrare
nodelay = true # Opzionale. Sovrascrive `client.transport.nodelay` per servizio
retry_interval = 1 # Opzionale. L'intervallo tra i tentativi di connessione al server. Default: eredita dalla configurazione globale
[client.services.service2] # Possono essere definiti più servizi
local_addr = "127.0.0.1:1082"
[server]
bind_addr = "0.0.0.0:2333" # Necessario. L'indirizzo su cui il server ascolta i client. Di solito è sufficiente cambiare la porta.
default_token = "default_token_if_not_specify" # Opzionale
heartbeat_interval = 30 # Opzionale. L'intervallo tra due heartbeat a livello applicativo. Imposta a 0 per disabilitare l'invio di heartbeat. Default: 30 secondi
[server.transport] # Uguale a `[client.transport]`
type = "tcp"
[server.transport.tcp] # Uguale al client
nodelay = true
keepalive_secs = 20
keepalive_interval = 8
[server.transport.tls] # Necessario se `type` è "tls"
pkcs12 = "identify.pfx" # Necessario. File pkcs12 del certificato del server e della chiave privata
pkcs12_password = "password" # Necessario. Password del file pkcs12
[server.transport.noise] # Uguale a `[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] # Necessario se `type` è "websocket"
tls = true # Se `true` userà le impostazioni in `server.transport.tls`
[server.services.service1] # Il nome del servizio deve essere identico a quello del client
type = "tcp" # Opzionale. Uguale al client `[client.services.X.type]`
token = "whatever" # Necessario se `server.default_token` non è impostato
bind_addr = "0.0.0.0:8081" # Necessario. L'indirizzo su cui il servizio è esposto. Di solito è sufficiente cambiare la porta.
nodelay = true # Opzionale. Uguale al client
[server.services.service2]
bind_addr = "0.0.0.1:8082"
rathole, come molti altri programmi Rust, utilizza variabili d'ambiente per controllare il livello di logging. Sono disponibili info, warn, error, debug, trace.
RUST_LOG=error ./rathole config.toml
eseguirà rathole con solo logging degli errori.
Se RUST_LOG non è presente, il livello di logging predefinito è info.
Dalla v0.4.7, rathole abilita TCP_NODELAY per impostazione predefinita, il che dovrebbe migliorare la latenza e le applicazioni interattive come RDP, server Minecraft. Tuttavia, riduce leggermente la larghezza di banda.
Se la larghezza di banda è più importante, TCP_NODELAY può essere disabilitato con nodelay = false.
rathole ha una latenza simile a frp, ma può gestire più connessioni, fornire maggiore larghezza di banda, con meno utilizzo di memoria.
Per maggiori dettagli, vedi la pagina separata Benchmark.
Tuttavia, non dedurre da questo che rathole possa magicamente rendere il tuo servizio inoltrato diverse volte più veloce di prima. Il benchmark è stato eseguito su loopback locale, indicando le prestazioni quando il compito è vincolato dalla CPU. Si può ottenere un notevole miglioramento se la rete non è il collo di bottiglia. Sfortunatamente, questo non è vero per molti utenti. In tal caso, il beneficio principale è un minor consumo di risorse, mentre la larghezza di banda e la latenza potrebbero non migliorare significativamente.
Fuori ambito elenca le funzionalità che non sono previste e il motivo.