Giter VIP home page Giter VIP logo

rathole's Introduction

rathole

rathole-logo

GitHub stars GitHub release (latest SemVer) GitHub Workflow Status (branch) GitHub all releases Docker Pulls Join the chat at https://gitter.im/rapiz1/rathole

English | 简体中文

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:

  1. 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 an 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
  1. 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
  1. Now the client will try to connect to the server myserver.com on port 2333, and any traffic to myserver.com:5202 will be forwarded to the client's port 22.

So you can ssh myserver.com:5202 to ssh to your NAS.

To run rathole run as a background service on Linux, checkout the systemd examples.

Configuration

rathole can automatically determine to run in the server mode or the client mode, according to the content of the configuration file, if only one of [server] and [client] block is present, like the example in Quickstart.

But the [client] and [server] block can also be put in one file. Then on the server side, run rathole --server config.toml and on the client side, run rathole --client config.toml to explicitly tell rathole the running mode.

Before heading to the full configuration specification, it's recommend to skim the configuration examples to get a feeling of the configuration format.

See Transport for more details about encryption and the transport block.

Here is the full configuration specification:

[client]
remote_addr = "example.com:2333" # Necessary. The address of the server
default_token = "default_token_if_not_specify" # Optional. The default token of services, if they don't define their own ones
heartbeat_timeout = 40 # Optional. Set to 0 to disable the application-layer heartbeat test. The value must be greater than `server.heartbeat_interval`. Default: 40 seconds
retry_interval = 1 # Optional. The interval between retry to connect to the server. Default: 1 second

[client.transport] # The whole block is optional. Specify which transport to use
type = "tcp" # Optional. Possible values: ["tcp", "tls", "noise"]. Default: "tcp"

[client.transport.tcp] # Optional. Also affects `noise` and `tls`
proxy = "socks5://user:[email protected]:1080" # Optional. The proxy used to connect to the server. `http` and `socks5` is supported.
nodelay = true # Optional. Determine whether to enable TCP_NODELAY, if applicable, to improve the latency but decrease the bandwidth. Default: true
keepalive_secs = 20 # Optional. Specify `tcp_keepalive_time` in `tcp(7)`, if applicable. Default: 20 seconds
keepalive_interval = 8 # Optional. Specify `tcp_keepalive_intvl` in `tcp(7)`, if applicable. Default: 8 seconds

[client.transport.tls] # Necessary if `type` is "tls"
trusted_root = "ca.pem" # Necessary. The certificate of CA that signed the server's certificate
hostname = "example.com" # Optional. The hostname that the client uses to validate the certificate. If not set, fallback to `client.remote_addr`

[client.transport.noise] # Noise protocol. See `docs/transport.md` for further explanation
pattern = "Noise_NK_25519_ChaChaPoly_BLAKE2s" # Optional. Default value as shown
local_private_key = "key_encoded_in_base64" # Optional
remote_public_key = "key_encoded_in_base64" # Optional

[client.transport.websocket] # Necessary if `type` is "websocket"
tls = true # If `true` then it will use settings in `client.transport.tls`

[client.services.service1] # A service that needs forwarding. The name `service1` can change arbitrarily, as long as identical to the name in the server's configuration
type = "tcp" # Optional. The protocol that needs forwarding. Possible values: ["tcp", "udp"]. Default: "tcp"
token = "whatever" # Necessary if `client.default_token` not set
local_addr = "127.0.0.1:1081" # Necessary. The address of the service that needs to be forwarded
nodelay = true # Optional. Override the `client.transport.nodelay` per service
retry_interval = 1 # Optional. The interval between retry to connect to the server. Default: inherits the global config

[client.services.service2] # Multiple services can be defined
local_addr = "127.0.0.1:1082"

[server]
bind_addr = "0.0.0.0:2333" # Necessary. The address that the server listens for clients. Generally only the port needs to be change.
default_token = "default_token_if_not_specify" # Optional
heartbeat_interval = 30 # Optional. The interval between two application-layer heartbeat. Set to 0 to disable sending heartbeat. Default: 30 seconds

[server.transport] # Same as `[client.transport]`
type = "tcp"

[server.transport.tcp] # Same as the client
nodelay = true
keepalive_secs = 20
keepalive_interval = 8

[server.transport.tls] # Necessary if `type` is "tls"
pkcs12 = "identify.pfx" # Necessary. pkcs12 file of server's certificate and private key
pkcs12_password = "password" # Necessary. Password of the pkcs12 file

[server.transport.noise] # Same as `[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] # Necessary if `type` is "websocket"
tls = true # If `true` then it will use settings in `server.transport.tls`

[server.services.service1] # The service name must be identical to the client side
type = "tcp" # Optional. Same as the client `[client.services.X.type]
token = "whatever" # Necessary if `server.default_token` not set
bind_addr = "0.0.0.0:8081" # Necessary. The address of the service is exposed at. Generally only the port needs to be change.
nodelay = true # Optional. Same as the client

[server.services.service2]
bind_addr = "0.0.0.1:8082"

Logging

rathole, like many other Rust programs, use environment variables to control the logging level. info, warn, error, debug, trace are available.

RUST_LOG=error ./rathole config.toml

will run rathole with only error level logging.

If RUST_LOG is not present, the default logging level is info.

Tuning

From v0.4.7, rathole enables TCP_NODELAY by default, which should benefit the latency and interactive applications like rdp, Minecraft servers. However, it slightly decreases the bandwidth.

If the bandwidth is more important, TCP_NODELAY can be opted out with nodelay = false.

Benchmark

rathole has similar latency to frp, but can handle a more connections, provide larger bandwidth, with less memory usage.

For more details, see the separate page Benchmark.

However, don't take it from here that rathole can magically make your forwarded service faster several times than before. The benchmark is done on local loopback, indicating the performance when the task is cpu-bounded. One can gain quite a improvement if the network is not the bottleneck. Unfortunately, that's not true for many users. In that case, the main benefit is lower resource consumption, while the bandwidth and the latency may not improved significantly.

http_throughput tcp_bitrate udp_bitrate mem

Planning

  • HTTP APIs for configuration

Out of Scope lists features that are not planned to be implemented and why.

rathole's People

Contributors

blueskea avatar boenshao avatar dependabot[bot] avatar enter-tainer avatar fernvenue avatar gitter-badger avatar goudronviande24 avatar hellodword avatar inclyc avatar missuo avatar neumark avatar orhun avatar rapiz1 avatar rucciva avatar ryanad avatar shiny avatar shirshak55 avatar sunmy2019 avatar tako8ki avatar voidbuf avatar zhfish avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

rathole's Issues

Detect broken data channels

Currently if a data channel is broken, it's still remaining in the connection pool for the latter use. It's not an issue for most applications but disturbs users.

Abort on top-level errors

With the introduce of the config watcher, if the main task encounters unrecoverable errors, the task will exit silently and leave the program freeze until next configuration change.

The expected behavior is to abort the program.

Adaptive color logging

Current logs are always colorful. It will better to automatically disable the color if the output is a pipe

UDP tunnel flapping

Client side experience constant control channel and data plane flapping while tunnelling UDP traffic. In the meanwhile, TCP tunnel is working without an issue.

Both server and client are deployed with official docker image.

The UDP service being tunnelling is wireguard, MTU has been adjusted to accommodate tunnelling and avoid fragmentation.

Error message on client side:

Jan 07 02:02:52.122  INFO new{service=some_service}:run: rathole::client: Control channel established
Jan 07 02:02:52.817 ERROR new{service=some_service}: rathole::client: Failed to run the control channel

Caused by:
    0: Failed to read control cmd
    1: early eof

Retry in 1s...
Jan 07 02:02:52.818 ERROR new{service=some_service}:run: rathole::client: Failed to run the data channel

Caused by:
    unexpected end of file
Jan 07 02:02:52.819 ERROR new{service=some_service}:run: rathole::client: Failed to run the data channel

Caused by:
    0: Failed to read data cmd
    1: early eof
Jan 07 02:02:54.162  INFO new{service=some_service}:run: rathole::client: Control channel established
Jan 07 02:02:54.879 ERROR new{service=some_service}: rathole::client: Failed to run the control channel

Server side configuration snap:

[server]
bind_addr = "someaddr:8080"
default_token = "sometoken"

[server.transport]
type = "noise"

[server.transport.noise]
local_private_key = "somekey"

[server.services.some_service]
type = "udp"
bind_addr = "0.0.0.0:51820"

Client side configuration snap:

[client]
remote_addr = "someaddr:8080"
default_token = "sometoken"

[client.transport]
type = "noise"

[client.transport.noise]
remote_public_key = "somekey"

[client.services.some_service]
type = "udp"
local_addr = "someip:51820"

"Failed to run the data channel" error occured when use udp services

server side log:

5|rathole  | Jan 16 12:33:10.150  INFO handle_connection{addr=58.246.229.238:22945}:new{service=ssu}:run{service=ssu}: rathole::server: Control channel shutdown
5|rathole  | Jan 16 12:33:11.283  INFO handle_connection{addr=58.246.229.238:23425}: rathole::server: Try to handshake a control channel
5|rathole  | Jan 16 12:33:11.293  WARN handle_connection{addr=58.246.229.238:23425}: rathole::server: Dropping previous control channel for service ssu
5|rathole  | Jan 16 12:33:11.293  INFO handle_connection{addr=58.246.229.238:23425}: rathole::server: Control channel established service=ssu
5|rathole  | Jan 16 12:33:11.293  INFO handle_connection{addr=58.246.229.238:23425}:new{service=ssu}:run_udp_connection_pool: rathole::server: Listening at 0.0.0.0:18088
5|rathole  | Jan 16 12:33:11.321 DEBUG handle_connection{addr=58.246.229.238:23457}: rathole::server: Try to handshake a data channel
5|rathole  | Jan 16 12:33:11.322 DEBUG handle_connection{addr=58.246.191.50:9281}: rathole::server: Try to handshake a data channel
5|rathole  | Jan 16 12:33:28.487 ERROR handle_connection{addr=58.246.229.238:23425}:new{service=ssu}: rathole::server: Failed to run TCP connection pool
5|rathole  | Caused by:
5|rathole  |     Connection reset by peer (os error 104)
5|rathole  | Jan 16 12:33:28.487  INFO handle_connection{addr=58.246.229.238:23425}:new{service=ssu}:run{service=ssu}: rathole::server: Control channel shutdown
5|rathole  | Jan 16 12:33:29.658  INFO handle_connection{addr=58.246.229.238:24225}: rathole::server: Try to handshake a control channel
5|rathole  | Jan 16 12:33:29.667  WARN handle_connection{addr=58.246.229.238:24225}: rathole::server: Dropping previous control channel for service ssu
5|rathole  | Jan 16 12:33:29.667  INFO handle_connection{addr=58.246.229.238:24225}: rathole::server: Control channel established service=ssu
5|rathole  | Jan 16 12:33:29.668  INFO handle_connection{addr=58.246.229.238:24225}:new{service=ssu}:run_udp_connection_pool: rathole::server: Listening at 0.0.0.0:18088
5|rathole  | Jan 16 12:33:29.703 DEBUG handle_connection{addr=58.246.229.238:24258}: rathole::server: Try to handshake a data channel
5|rathole  | Jan 16 12:33:29.705 DEBUG handle_connection{addr=58.246.191.50:10274}: rathole::server: Try to handshake a data channel
5|rathole  | Jan 16 12:33:57.304 ERROR handle_connection{addr=58.246.229.238:24225}:new{service=ssu}: rathole::server: Failed to run TCP connection pool
5|rathole  | Caused by:
5|rathole  |     unexpected end of file

client side log:

4|rathole  | Jan 16 12:33:28.384 ERROR new{service=ssu}: rathole::client: Failed to run the control channel
4|rathole  | Caused by:
4|rathole  |     0: Failed to read control cmd
4|rathole  |     1: early eof
4|rathole  | Retry in 1s...
4|rathole  | Jan 16 12:33:29.565  INFO new{service=ssu}:run: rathole::client: Control channel established
4|rathole  | Jan 16 12:33:57.190 ERROR new{service=ssu}:run: rathole::client: Failed to run the data channel
4|rathole  | Caused by:
4|rathole  |     0: Failed to deserialize udp header
4|rathole  |     1: invalid value: integer `3070230528`, expected `V4` or `V6`
4|rathole  | Jan 16 12:33:57.199 ERROR new{service=ssu}:run: rathole::client: Failed to run the data channel
4|rathole  | Caused by:
4|rathole  |     0: Failed to read data cmd
4|rathole  |     1: early eof

Cargo install?

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.

Why not cargo install rathole?

I tried but it fails

error: failed to run custom build command for `rathole v0.3.1`

Caused by:
  process didn't exit successfully: `/tmp/cargo-installeiw1LE/release/build/rathole-4166e51a1e9957bd/build-script-build` (exit status: 1)
  --- stderr
  Error: could not find repository from '/home/hackerzol/.cargo/registry/src/github.com-1ecc6299db9ec823/rathole-0.3.1'; class=Repository (6); code=NotFound (-3)
warning: build failed, waiting for other jobs to finish...
error: failed to compile `rathole v0.3.1`, intermediate artifacts can be found at `/tmp/cargo-installeiw1LE`

Caused by:
  build failed

UDP support

  1. Decide whether to provide UDP support in rathole
  2. If so, research there's any library usable
  3. If not, provide a solution utilizing some udp-to-tcp tunnel in the documentation

Make `accept` of `Transport` cancel safe

This is unlikely to occur. But if a hot-reload for a service and a TCP connection arrives at the same time, the TCP connection will be dropped.

rathole/src/server.rs

Lines 140 to 143 in 1240dd8

tokio::select! {
// FIXME: This should be cancel safe.
// Wait for incoming control and data channels
ret = self.transport.accept(&l) => {

A primitive thought is to turn Transport::accept into Transport::handshake and make it accept a raw TCP connection. And use TCPListener::accept in select because it is cancel safe. However it breaks some abstraction and assumes the underlying protocol is TCP, which causes trouble for UDP-based transport, like QUIC. So maybe the trait can be redesigned in another way. Thoughts will be welcome.

Or keep the trait unchanged and write a future to make Transport::accept cancel safe. I don't know if that's feasible. For TCP, it's impossible to put an accepted connection back to the system backlog. And generally handshake consists of multiple packets. I doubt it can made cancel safe without altering the trait. Redesigning the trait seems the way to go.

Flush when handshake

Current handshake functions don't call flush after sending each packets. It may be an issue affecting reliability.

Log level configuration

  1. Document the env RUST_LOG
  2. Default to the INFO level
  3. Add a configuration option that specify the logging level

Improve documentation

Lots of features and optimization have been introduced since v0.1.0. Documentations are needed to indicate that, including:

  • The security model and the encryption
  • Hot-reloading
  • More benchmark about various use cases and memory #21

Add CI

Add CI including:

  • cargo clippy
  • cargo test

Docker image

Someone requests it and it should be easy to create one, though it doesn't seem quite useful to me. These days people are get used to just typing docker run.

A Dockerfile can be created under the root of the project.

Mipsel release not work

I tried to exec rathole binaries on mipsel device and config it from examples, but it print nothing and usage 25% CPU(100% single thread), looks like be in infinite loop.

CPU is MT7621AT, dual-core with quad-thread.
System is Padavan 3.4.3.9-099_21-10-3, build by hiboyhiboyhiboy.

Failed to run the control channel and the data channel

`Jan 13 12:18:01.913 ERROR new{service=my_ssh}: rathole::client: Failed to run the control channel

Caused by:
0: Failed to read control cmd
1: early eof

Retry in 1s...
Jan 13 12:18:01.939 ERROR new{service=my_ssh}:run: rathole::client: Failed to run the data channel

Caused by:
0: Failed to read data cmd
1: early eof`
This was happening all the time since the client started,I don't know why it happened,but it didn't affect the connection actually,I could still ssh to the computer behind NAT.

Benchmark the memory usage

rathole uses about as 1/5 memory as frp uses. A more formed benchmark should be created to show that.

Support SOCKS5_PROXY and HTTP_PROXY for transport

Like:

[client.transport]
type = "tcp"
[client.transport.tcp]
proxy = "socks5://localhost:1080" # connect to the server via a socks5 proxy

or

[client.transport]
type = "tcp"
[client.transport.tcp]
proxy = "http://localhost:1080" # connect to the server via a http proxy

Support IPv6 `local_addr` for UDP services

rathole/src/helper.rs

Lines 40 to 46 in e6dd0c8

/// Create a UDP socket and connect to `addr`
pub async fn udp_connect<A: ToSocketAddrs>(addr: A) -> Result<UdpSocket> {
// FIXME: This only works for IPv4
let s = UdpSocket::bind("0.0.0.0:0").await?;
s.connect(addr).await?;
Ok(s)
}

UdpSocket::bind("0.0.0.0:0").await? binds to a IPv4 UDP socket and cannot be used to connect to an IPv6 address. A match on addr can solve this issue.

Hot reloading breaks when changing the service name

If I change the service name, the client does not know to unregister the previous service, and re-register a new service under the same name. Getting the following error:

Jan 05 07:06:15.562 ERROR new{service=foo1}: rathole::client: Failed to run the control channel

Caused by:
    0: Authentication failed: foo1
    1: Service not exist

Retry in 1s...

Expose `TCP_NODELAY`

  1. Set TCP_NODELAY for all control channels
  2. Opt-in for each service. Default off.

Seems to reduce the latency in a primitive test, but also impact the bandwidth.

Multiple platform releases

Current CI only compiles against only a few targets, which causes inconvenience for end users.

x86_64_unknown-linux-gnu links a glibc of ubuntu-latest, which may be too new for some distributions. -musl should be added to facilitate older distributions.

  • x86_64-unknown-linux-musl
  • aarch64-apple-darwin
  • aarch64-unknown-linux-musl
  • mips-unknown-linux-musl
  • mipsel-unknown-linux-musl
  • mips64-unknown-linux-muslabi64
  • mips64el-unknown-linux-muslabi64

Can't be installed in centos

I tried to use cargo install rathole to install rathole, but got a result like this.

WARN rustc_codegen_ssa::back::link Linker does not support -no-pie command line option. Retrying without.
 error: failed to compile `rathole v0.3.8`, intermediate artifacts can be found at `/tmp/cargo-installAxF1R0`

Caused by:
  could not compile `rathole`

Caused by:
  process didn't exit successfully: `rustc --crate-name rathole --edition=2021 /root/.cargo/registry/src/mirrors.ustc.edu.cn-61ef6e0cd06fb9b8/rathole-0.3.8/src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C opt-level=3 -C panic=abort -C lto --cfg 'feature="base64"' --cfg 'feature="client"' --cfg 'feature="default"' --cfg 'feature="hot-reload"' --cfg 'feature="noise"' --cfg 'feature="notify"' --cfg 'feature="server"' --cfg 'feature="snowstorm"' --cfg 'feature="tls"' --cfg 'feature="tokio-native-tls"' -C metadata=e437c7ced0e7eeb5 -C extra-filename=-e437c7ced0e7eeb5 --out-dir /tmp/cargo-installAxF1R0/release/deps -L dependency=/tmp/cargo-installAxF1R0/release/deps --extern anyhow=/tmp/cargo-installAxF1R0/release/deps/libanyhow-730a28b8f79ceb5d.rlib --extern async_trait=/tmp/cargo-installAxF1R0/release/deps/libasync_trait-a4dc42297c0ceffd.so --extern atty=/tmp/cargo-installAxF1R0/release/deps/libatty-f50d19c10292bf76.rlib --extern backoff=/tmp/cargo-installAxF1R0/release/deps/libbackoff-13a4b179c6b6ecbb.rlib --extern base64=/tmp/cargo-installAxF1R0/release/deps/libbase64-12a9411d5668daac.rlib --extern bincode=/tmp/cargo-installAxF1R0/release/deps/libbincode-0d0f9498b364a491.rlib --extern bytes=/tmp/cargo-installAxF1R0/release/deps/libbytes-e48e07cf49912739.rlib --extern clap=/tmp/cargo-installAxF1R0/release/deps/libclap-90189fe0dddb30d0.rlib --extern const_format=/tmp/cargo-installAxF1R0/release/deps/libconst_format-c0e3e1842b42edc8.rlib --extern fdlimit=/tmp/cargo-installAxF1R0/release/deps/libfdlimit-afa4c3a19c6961bd.rlib --extern hex=/tmp/cargo-installAxF1R0/release/deps/libhex-c24168e20527c0e0.rlib --extern lazy_static=/tmp/cargo-installAxF1R0/release/deps/liblazy_static-4cfee8f8757b12d4.rlib --extern notify=/tmp/cargo-installAxF1R0/release/deps/libnotify-3217dbbdb1e5c269.rlib --extern rand=/tmp/cargo-installAxF1R0/release/deps/librand-3066103e7a256266.rlib --extern rathole=/tmp/cargo-installAxF1R0/release/deps/librathole-d00699d9f968f2b1.rlib --extern serde=/tmp/cargo-installAxF1R0/release/deps/libserde-cac8618c1490a5ea.rlib --extern sha2=/tmp/cargo-installAxF1R0/release/deps/libsha2-b9c52311cf212fd3.rlib --extern snowstorm=/tmp/cargo-installAxF1R0/release/deps/libsnowstorm-810f2b49afb5a323.rlib --extern socket2=/tmp/cargo-installAxF1R0/release/deps/libsocket2-6037ebe9b9eec2d3.rlib --extern tokio=/tmp/cargo-installAxF1R0/release/deps/libtokio-6b32e572b38416e2.rlib --extern tokio_native_tls=/tmp/cargo-installAxF1R0/release/deps/libtokio_native_tls-3105911603e52e49.rlib --extern toml=/tmp/cargo-installAxF1R0/release/deps/libtoml-5bafa3b48212c2ea.rlib --extern tracing=/tmp/cargo-installAxF1R0/release/deps/libtracing-62c2bfdcceec5fea.rlib --extern tracing_subscriber=/tmp/cargo-installAxF1R0/release/deps/libtracing_subscriber-7972557a3e5b499c.rlib --cap-lints allow` (signal: 9, SIGKILL: kill)

TLS transport for UDP may be unsound

tokio-rs/tls#40

rathole/src/client.rs

Lines 224 to 234 in 6eb0a13

async fn run_data_channel_for_udp<T: Transport>(conn: T::Stream, local_addr: &str) -> Result<()> {
debug!("New data channel starts forwarding");
let port_map: UdpPortMap = Arc::new(RwLock::new(HashMap::new()));
// The channel stores UdpTraffic that needs to be sent to the server
let (outbound_tx, mut outbound_rx) = mpsc::channel::<UdpTraffic>(UDP_SENDQ_SIZE);
// FIXME: https://github.com/tokio-rs/tls/issues/40
// Maybe this is our concern
let (mut rd, mut wr) = io::split(conn);

Binaries for feature combinations

Currently we only release binaries with full features. In the future, we can also release binaries with different feature combinations.

Maybe useful combinations:

  • profile minimal
    • server, client
    • server, client, tls
    • server, client, noise

Replace `ring`

Since only SHA256 in ring is used and ring doesn't support some platforms well, it can be replaced with some pure rust library.

Build under FreeBSD (jail) failed when compiling vergen

# freebsd-version
12.2-RELEASE-p11
cargo build --release

Error message:

error[E0609]: no field `uid` on type `&Process`
   --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/vergen-6.0.0/src/feature/si.rs:265:28
    |
265 |     *user.uid() == process.uid
    |                            ^^^ unknown field

For more information about this error, try `rustc --explain E0609`.

Would you please help?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.