surban / aggligator Goto Github PK

When I was testing agg-tunnel locally, I noticed even with a very small payload, there are huge underlying packets transmitted(about 8k bytes), that is much more than tls handshake. I guess that is for the DH key-exchange?

I think the key-exchange process should be made optional, so in trusted environments, the setup speed will be better.

See here:

https://github.com/ikatson/rqbit/pull/53/files

There's an issue with network-interface that causes it to not build on BSD.
Unfortunately, it works into further issues using the fork they use, because we end up with this:

   --> aggligator-util/src/transport/tcp.rs:485:21
    |
485 |                 let Some(addr) = ifn.addr else { continue };
    |                     ^^^^^^^^^^   -------- this expression has type `Vec<Addr>`
    |                     |
    |                     expected `Vec<Addr>`, found `Option<_>`
    |
    = note: expected struct `Vec<Addr>`
                 found enum `Option<_>`

hi,

I am from Iran, and we are suffering from heavy filtering and slow internet speed.

Your awesome project can help us circumvent these restrictions. I'm currently working on a new proxy in Golang, and I want to use your project for "muxing," or multiplexing, my proxy packets between client and server in order to achieve higher speed and a more resilient network connection. Can you help us port your project to Golang?

Hello, surban! This is a great project and I really feel epic when seeing the bandwidth combined, a Big Thank You!

I guess you haven't tried agg-tunnel on Windows, but I can confirm that it works smoothly, with a small modification. It's that IPv6 listeners don't get IPv4 connections by default on Windows. So most of the time agg-tunnel just catches nothing.

My solution to this (PaperStrike@5f15498) is to set the only_v6 flag with socket2. Per tokio-rs/tokio#6171, tokio seems not liking having the option. In client mode, I set it true, open up two sockets, one for IPv4, one for IPv6, and merge their "accept" together. This is because 127.0.0.1 doesn't get mapped to ::1 and the socket don't catch 127.0.0.1 on Win even with only_v6 set to false, unless with global mode on which uses Ipv6Addr::UNSPECIFIED. In server mode, I simply set only_v6 false.

This issue can also be solved by differentiating platforms and use different code path. Note some Linux also default only_v6 to true, and the default value is configurable. It can also be solved by extending the --ipv4/--ipv6 option usage or introducing new ones. I have no idea which way is better.

This seems irrelevant to what this project is about, but it's relevant to Rust. AFAIK, Java and Python has made their decisions to unify the default behavior across platforms, one binds sockets to both, one binds to only v4 or only v6. Rust/Go/Node.js is still standing in the middle and requires adjustments per project.

I am new to Rust, apologize if I misunderstand anything.
Thank you again for your amazing work!

what for Debian Gnu/Linux deb?

Thank you for this amazing project!

My use case may be a litte bit different that I have two servers with high intranet bandwidth (~1Gbps) but distinct external IPs and limited internet speeds (2-3Mbps), which is a common case in my country (business bandwith being far more expensive than residential bandwidth, or like upload and download being differentiated and upload speed being far more expensive than download speed, kind of stuff). I would like to self-hosting game servers like Minecraft to play with my friends, RDP to remote control my computer, things that I can kinda control the clients (they trust me). So I found your project, configured one of my server to port forward TCP through intranet to another, and got it working! The bandwidth is combined!

Well I did a little trick (PaperStrike@72d77e0) that I modified the code to differentiate remotes by IP instead of remote_user_data, as the server has the same interface for both internet IP and intranet IP. (The servers are from one of the two largest domestic provider, so it can't be unusal.) I am sharing my tricks with you and the others so that we don't always have to pay for a single server with higher bandwidth (Yep somehow one server with higher bandwidth is far more expensive than two server with splitted bandwidth here).

Could it be added as an option?

Also I admit I struggled a bit to get to grips with your tools, especially without a full example to guide me. So, I've included a working example below to hopefully help others.

Example Configuration

Imagine a Minecraft Server (TCP version) active on Server A at port 7003. Here's how we could combine the bandwidth:

1. On Server A, run the following command:

   agg-tunnel server --tcp 7001 --port 7003
   

2. Set up Server B to redirect TCP traffic from its port 7002 to Server A at 10.0.1.1:7001.
3. On the gaming clients, run:

   agg-tunnel client --tcp 30.1.1.1:7001 --tcp 30.1.1.2:7002 --port 7003:7010
   

4. To connect, launch Minecraft and use the server address 127.0.0.1:7010.

Thank you again for the amazing work!

Is there any documentation for how to use the tunneling tool? I'm aware we can just read the code to learn how it parses and figure out what the proper commands are but just a list of a few examples commands would be helpful.

...
   Compiling gethostname v0.4.3
   Compiling aggligator-util v0.10.2 (C:\2_\aggligator-util)
error[E0308]: mismatched types
   --> aggligator-util\src\transport\tcp.rs:485:21
    |
485 |                 let Some(addr) = ifn.addr else { continue };
    |                     ^^^^^^^^^^   -------- this expression has type `Vec<Addr>`
    |                     |
    |                     expected `Vec<Addr>`, found `Option<_>`
    |
    = note: expected struct `Vec<Addr>`
                 found enum `Option<_>`

For more information about this error, try `rustc --explain E0308`.
error: could not compile `aggligator-util` (lib) due to 1 previous error

can't build aggligator, but agg-speed.exe and agg-tunnel.exe built successfully.

C:>cargo -V
cargo 1.76.0 (c84b36747 2024-01-18)