rathole - NAT traversal proxy - alternative to frp, ngrok, etc
-
rathole
A secure, stable and high-performance reverse proxy for NAT traversal, written in Rust
rathole, like frp and ngrok, can help to expose the service on the device behind the NAT to the Internet, via a server with a public IP.
Features
- High Performance Much higher throughput can be achieved than frp, and more stable when handling a large volume of connections. See Benchmark
- Low Resource Consumption Consumes much fewer memory than similar tools. See Benchmark. The binary can be as small as ~500KiB to fit the constraints of devices, like embedded devices as routers.
- Security Tokens of services are mandatory and service-wise. The server and clients are responsible for their own configs. With the optional Noise Protocol, encryption can be configured at ease. No need to create a self-signed certificate! TLS is also supported.
- Hot Reload Services can be added or removed dynamically by hot-reloading the configuration file. HTTP API is WIP.
Quickstart
A full-powered
rathole
can be obtained from the release page. Or build from source for other platforms and minimizing the binary. A Docker image is also available.The usage of
rathole
is very similar to frp. If you have experience with the latter, then the configuration is very easy for you. The only difference is that configuration of a service is split into the client side and the server side, and a token is mandatory.To use
rathole
, you need a server with a public IP, and a device behind the NAT, where some services that need to be exposed to the Internet.Assuming you have a NAS at home behind the NAT, and want to expose its ssh service to the Internet:
- On the server which has a public IP
Create
server.toml
with the following content and accommodate it to your needs.# server.toml [server] bind_addr = "0.0.0.0:2333" # `2333` specifies the port that rathole listens for clients [server.services.my_nas_ssh] token = "use_a_secret_that_only_you_know" # Token that is used to authenticate the client for the service. Change to a arbitrary value. bind_addr = "0.0.0.0:5202" # `5202` specifies the port that exposes `my_nas_ssh` to the Internet
Then run:
./rathole server.toml
- On the host which is behind the NAT (your NAS)
Create
client.toml
with the following content and accommodate it to your needs.# client.toml [client] remote_addr = "myserver.com:2333" # The address of the server. The port must be the same with the port in `server.bind_addr` [client.services.my_nas_ssh] token = "use_a_secret_that_only_you_know" # Must be the same with the server to pass the validation local_addr = "127.0.0.1:22" # The address of the service that needs to be forwarded
Then run:
./rathole client.toml
- Now the client will try to connect to the server
myserver.com
on port2333
, and any traffic tomyserver.com:5202
will be forwarded to the client's port22
.
So you can
ssh myserver.com:5202
to ssh to your NAS. -
I'm using rathole on my server. It's easy enough to install the binary on the host. Rathole is pretty awesome. I'm hosting everything from home without any ports open and a cheap VPS.
Are you looking for a rathole per app config?
-
I'm using rathole on my server. It's easy enough to install the binary on the host. Rathole is pretty awesome. I'm hosting everything from home without any ports open and a cheap VPS.
Are you looking for a rathole per app config?
@ovny Could you make a guide on how to do this? I think it would help with the port 25 issue, among other things.
-
I'm using rathole on my server. It's easy enough to install the binary on the host. Rathole is pretty awesome. I'm hosting everything from home without any ports open and a cheap VPS.
Are you looking for a rathole per app config?
@ovny said in rathole - NAT traversal proxy - alternative to frp, ngrok, etc:
I'm using rathole on my server. It's easy enough to install the binary on the host. Rathole is pretty awesome. I'm hosting everything from home without any ports open and a cheap VPS.
If you have time, it would be awesome if you could explain how to set up this so that others could try self-hosting Cloudron at home using a cheap VPS for the outside world.
-
rathole
A secure, stable and high-performance reverse proxy for NAT traversal, written in Rust
rathole, like frp and ngrok, can help to expose the service on the device behind the NAT to the Internet, via a server with a public IP.
Features
- High Performance Much higher throughput can be achieved than frp, and more stable when handling a large volume of connections. See Benchmark
- Low Resource Consumption Consumes much fewer memory than similar tools. See Benchmark. The binary can be as small as ~500KiB to fit the constraints of devices, like embedded devices as routers.
- Security Tokens of services are mandatory and service-wise. The server and clients are responsible for their own configs. With the optional Noise Protocol, encryption can be configured at ease. No need to create a self-signed certificate! TLS is also supported.
- Hot Reload Services can be added or removed dynamically by hot-reloading the configuration file. HTTP API is WIP.
Quickstart
A full-powered
rathole
can be obtained from the release page. Or build from source for other platforms and minimizing the binary. A Docker image is also available.The usage of
rathole
is very similar to frp. If you have experience with the latter, then the configuration is very easy for you. The only difference is that configuration of a service is split into the client side and the server side, and a token is mandatory.To use
rathole
, you need a server with a public IP, and a device behind the NAT, where some services that need to be exposed to the Internet.Assuming you have a NAS at home behind the NAT, and want to expose its ssh service to the Internet:
- On the server which has a public IP
Create
server.toml
with the following content and accommodate it to your needs.# server.toml [server] bind_addr = "0.0.0.0:2333" # `2333` specifies the port that rathole listens for clients [server.services.my_nas_ssh] token = "use_a_secret_that_only_you_know" # Token that is used to authenticate the client for the service. Change to a arbitrary value. bind_addr = "0.0.0.0:5202" # `5202` specifies the port that exposes `my_nas_ssh` to the Internet
Then run:
./rathole server.toml
- On the host which is behind the NAT (your NAS)
Create
client.toml
with the following content and accommodate it to your needs.# client.toml [client] remote_addr = "myserver.com:2333" # The address of the server. The port must be the same with the port in `server.bind_addr` [client.services.my_nas_ssh] token = "use_a_secret_that_only_you_know" # Must be the same with the server to pass the validation local_addr = "127.0.0.1:22" # The address of the service that needs to be forwarded
Then run:
./rathole client.toml
- Now the client will try to connect to the server
myserver.com
on port2333
, and any traffic tomyserver.com:5202
will be forwarded to the client's port22
.
So you can
ssh myserver.com:5202
to ssh to your NAS.@robi How would you configure it to forward everything, rather than just one port?
-
Rathole's latest release was October 2023: https://github.com/rathole-org/rathole/releases/tag/v0.5.0
Do we have anything better now? @robi what do you think? BoringProxy development ended in 2023, too: https://boringproxy.io/tunneling-comparison/
sish is still under development: https://ssi.sh/
why don't people like ngrok?
-
Rathole's latest release was October 2023: https://github.com/rathole-org/rathole/releases/tag/v0.5.0
Do we have anything better now? @robi what do you think? BoringProxy development ended in 2023, too: https://boringproxy.io/tunneling-comparison/
sish is still under development: https://ssi.sh/
why don't people like ngrok?
@LoudLemur Doesn't mean there hasn't been repo activity. Just no releases it seems.
Mostly just works for people.
Many alternatives exist:
https://github.com/anderspitman/awesome-tunneling
For instance:
https://github.com/ekzhang/bore [Rust based]
Best option for Cloudron is if there is such a tool with a generic enough web interface, like our VPN web app, that will satisfy packaging requirements and easily use one or several such cli tools underneath.
Then the user can choose and the ecosystem can grow.
For anyone feeling generously adventurous, use one of the available and very capable AIs to help make such an app or modify the existing VPN app to make this work.
Then use the already developed prompt for packaging it too