rathole v0.5 releases: secure, stable and high-performance reverse proxy for NAT traversal
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 less 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.
Internals
Conceptions
Service
The entity whose traffic needs to be forwarded
Server
The host that runs rathole in the server mode
Client
The host behind the NAT runs rathole in client mode. It has some services that need to be forwarded.
Visitor
Who visits a service, via the server
Control Channel
A control channel is a TCP connection between the server and the client that only carries rathole control commands for one service.
Data Channel
A data channel is a TCP connection between the server and the client that only carries the encapsulated data that needs forwarding for one service.
The Process
TODO: Add more details about the protocol
When rathole starts in the client mode, it creates connections to a server.common.bind_addr for each service. This connection acts as a control channel.
When a control channel starts, the server challenges the client by a nonce, the client is required to authenticate as the service it wants to represent. Then the forwarding of that service is set up.
When the server accepts a connection on a service’s bind_port, it sends a control command to the client via the corresponding control channel. Then the client connects to the server to create a data channel. In this way, forwarding is set up. The server also creates a few data channels in advance to improve the latency.
Changelog v0.5
New transport supported!
- feat(transport): add websocket transport by @rucciva in #290
- We dropped linux musl release to save the trouble of linking musl openssl. Now there’s only one release for linux x64. Given that it’s compiled on ubuntu-latest, the required glibc version should be decent for most users to use.
- Because of the maintenance burden of linking TLS libraries, we don’t compile the TLS feature in the release for embedded platforms anymore. If you need to use it, please build from the source by yourself. We will add it back when a pure rust tls library or a good cross-platform TLS libraries linking solution is available.
- docs: non root user with systemd by @boenshao in #269
- chore: fix shield.io badge in README-zh.md by @shiny in #272
