rstun
rstun copied to clipboard
neevek
Discussion on how to support multiple tcp tunnels and multiple udp tunnels
I intentionally try to make rstun support multiple tcp tunnels and multiple udp tunnels, or even running mixed IN and OUT modes at the same time.
The initial thoughts are: ① Allow the two parameters tcp_mapping and udp_mapping to separate multiple records with commas;
② Modify the format of tcp_mapping and udp_mapping single records, and add the optional prefix of IN or OUT—if a prefix is provided, the value provided will be used, otherwise the mode value in the public parameter will be used;
Curreent Configuration file example
rstunc
--mode OUT \
--server-addr 1.2.3.4:6060 \
--password 123456 \
--cert path/to/cert.der \
--tcp-mapping 0.0.0.0:9900^8800 \
--loglevel D
New Configuration file example
rstunc
--mode OUT \
--server-addr 1.2.3.4:6060 \
--password 123456 \
--cert path/to/cert.der \
--tcp-mapping IN^0.0.0.0:9900^8800,OUT^0.0.0.0:1900^1800,0.0.0.0:2900^2800 \
--loglevel D
In this new configuration, a total of 3 tcp tunnels are running:
0.0.0.0:9900^8800 and 0.0.0.0:1900^1800 both specify their own mode.
0.0.0.0:2900^2800 does not specify its own mode, so the public mode in the command is used.
I'm not sure whether the above idea is reasonable. In fact, to be honest, I'm not sure whether I can complete it on my own.
Hi, thanks for bringing this to a discussion. I have actually thought about supporting tcp and udp tunnels for a single client when introducing udp support, but I didn't come up with a good design on this, so the plan has been put on hold since then.
The format you suggested for tcp_mapping and udp_mapping looks good to me, with the new format, I think we can completely remove the top level --mode argument to avoid ambiguity.
To support mixed mode tunnels for a single client, two options:
- With single connection, a message indicating the transport type (tcp or udp) and transport direction (inbound or outbound) must be exchanged for each newly opened stream, this also requires changing the way that the server handles streams.
- With multiple connections, a new connection is created for each tunnel, and a login message is exchanged for the connection (thus the tunnel), then everything works the way as what it looks like now.
We also need to handle creating access servers on both the server and client ends for the tunnels, this needs quite a lot of refactoring. I think this is not an easy but achievable task.
2. With multiple connections
As you stated, it is an economical approach to use one quic channel to support one tunnel.
If I understand correctly, in the current software architecture, the tcp tunnel and the udp tunnel are each built on an independent quic channel (client.rs:313 and client.rs:310), which means we don’t need to make any changes to the rstund to achieve our goal.
There may be other omissions, such as statistics, please feel free to give me your advice.