rathole v0.4.8 releases: secure, stable and high-performance reverse proxy for NAT traversal
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.
- 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.
The entity whose traffic needs to be forwarded
The host that runs rathole in the server mode
The host behind the NAT runs rathole in client mode. It has some services that need to be forwarded.
Who visits a service, via the server
A control channel is a TCP connection between the server and the client that only carries
rathole control commands for one service.
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.
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.
This release fixes the build by upgrading dependencies.
- chore: update tls cert for test by @rapiz1 in #227
- chore(deps): bump libgit2-sys from 0.13.4+1.4.2 to 0.13.5+1.4.5 by @dependabot in #217
- ci: upgrade to upx v4.0.2 by @rapiz1 in #228
- chore(deps): bump tokio from 1.21.2 to 1.24.2 by @dependabot in #219
- chore(deps): bump openssl from 0.10.42 to 0.10.48 by @dependabot in #234
- chore: bump tracing-subscriber in #247
- chore(deps): bump h2 from 0.3.15 to 0.3.18 by @dependabot in #248