Rusnel
Description
Rusnel is a fast TCP/UDP tunnel, transported over and encrypted using QUIC protocol. Single executable including both client and server. Written in Rust.
Features
- Easy to use
- Single executable including both client and server.
- Uses QUIC protocol for fast and multiplexed communication.
- Encrypted connections using the QUIC protocol (TLS 1.3).
- Static forward tunneling (TCP, UDP)
- Static reverse tunneling (TCP, UDP)
- Dynamic tunneling (socks5, including UDP ASSOCIATE)
- Dynamic reverse tunneling (reverse socks5, including UDP ASSOCIATE)
- Layered peer authentication: insecure, fingerprint pinning, or full mTLS (see Authentication).
Install
or
Clone the repository and build the project:
Usage
)
)
)
)
)
)
;
)
<SERVER> defines )
<remote>...
<remote>s
<local-host>:<local-port>:<remote-host>:<remote-port>/<protocol>
)
)
)
)
; )
; )
)
;
);
(; )
The client survives both transient network drops and full server restarts
out of the box: on disconnect it logs the close reason (e.g.
closed by peer: server received ^C (code 0)), backs off, and tries every
resolved address in parallel using RFC 8305 Happy Eyeballs so v4-only
servers reachable via a v6-preferring resolver still connect within
~250 ms. Server-side resources (including reverse-tunnel listeners) are
released the moment the QUIC connection drops.
Authentication
Both the server and the client require an explicit TLS-mode flag — there is no silent insecure default. Three modes:
| Mode | Server | Client |
|---|---|---|
| Insecure | --insecure |
--insecure |
| Fingerprint pin | --tls-self-signed (or --tls-cert/--tls-key) |
--tls-fingerprint sha256:... |
| Full mTLS | --tls-cert ... --tls-key ... --tls-ca ... |
--tls-ca ... --tls-cert ... --tls-key ... [--tls-server-name ...] |
Quickest path for a private/single-user setup — the server logs its fingerprint at startup, the client pins it:
# server cert fingerprint: sha256:abcd...
For full mTLS, generate a CA + server + client cert (no openssl required):
rusnel cert --help lists the underlying subcommands (ca, server,
client, fingerprint) for finer control. Pre-configured binaries with
credentials baked in at compile time are also supported via
RUSNEL_EMBED_* env vars — see build.rs and the
CHANGELOG for details.
Performance
Rusnel (QUIC) vs Chisel (SSH-over-WebSocket) on loopback. Throughput is iperf3 over a tunneled TCP forward (100 MB × 5 runs + warmup, median); latency is the round-trip time of a 64 B echo across the tunnel.

End-to-end HTTP request times through the tunnel across payload sizes (median of 5 runs, error bars show min/max):

The benchmark harness also includes a wan profile that applies
tc qdisc netem delay 25ms to the loopback interface to approximate a
50 ms-RTT WAN. Reproduce everything with ./benchmark/run.sh
(requires Docker; needs --cap-add=NET_ADMIN for netem profiles, which
the script adds for you). See benchmark/ for tunables.
TODO
- write tests in rust for tcp, udp, reverse and socks
- improve logging by for each tunnel
- add server tls certificate verification
- add mutual tls verification
- disguise traffic as HTTP/3 to bypass DPI firewalls (ALPN
h3, default UDP/443, configurable SNI, RFC 9000 QUIC version, optionally CA-signed cert and minimal HTTP/3 facade for active probes) - benchmark performance against chisel (see Performance — also benchmark against wstunnel, frp)
Reliability & UX
- client reconnect with exponential backoff (configurable via
--max-retry-count/--max-retry-interval) - add proxy support for client (client connects to server through an HTTP/SOCKS proxy)
-
RUST_LOG-style env filter fortracing-subscriber(per-module log levels)
Protocol features
- support UDP over SOCKS5 (UDP ASSOCIATE) — both forward (
socks) and reverse (R:socks) - add fake-backend http/3 feature to server (real HTTP/3 facade for active probes that open streams)
- skip the 1-RTT control handshake on static forwards (cache the parsed
RemoteRequestserver-side; saves ~1 RTT per accepted TCP connection on WAN) - enable QUIC 0-RTT connection resumption (session-ticket cache; cuts the first request after
rusnel clientstartup from ~3 RTT to ~1 RTT)
Data plane performance
- swap the UDP session map for a sharded lock-free structure (
dashmap) so the receive loop doesn't serialize on a global mutex under high pps from many sources - 256 KB
BufReader/copy_bufis applied to every tunneled TCP leg, including SOCKS5 CONNECT — all three paths sharetunnel_tcp_stream - single-copy QUIC→TCP data path via
quinn::RecvStream::read_chunk(tried in 0.5.0; per-chunk syscall overhead regressed loopback throughput ~40 % vsBufReader+copy_bufbecause chunks are small — revisit when quinn exposes a vectoredBytes-returning read API) - UDP over QUIC datagrams (RFC 9221) instead of length-prefixed reliable streams: removes per-datagram
Vecalloc, the per-source map lookup, the stream open, and the length frame
Testing & CI
- integration test that asserts
--congestion bbractually engages BBR (would catch a future quinn API change) - run
./benchmark/run.shon a self-hosted runner per release tag and commit the result PNGs back, so perf regressions surface in PRs