Feature: Add support for multicast #245
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We have implemented a lightweight tunnel that supports multicast message transmission based on a patch for tun2socks. I organized the patch as a PR and hope it will be helpful for the development of tun2socks :)
Implementation
To enable tun2socks to handle multicast messages, we need to make the following efforts:
First, we add
multicast-groups
as a startup parameter and implement the corresponding parser . Its format is a comma-separated list of IP addresses, e.g.,225.0.0.1,ff02::1
.Then pass the parsed
net.IP
slicemulticastGroups
as configuration to core.CreateStack
.withMulticastGroups
is implemented to add the defaultnic
to the given multicast groups.NOTE: Why add addresses to the default
nic
?By default,
tun2socks
uses the UDPForwarder
provided bygVisor
to generateForwarderRequest
. When callingCreateEndpoint
, bothep.net.Bind
andep.net.Connect
will be applied to be able to pass the response back to the data sender. When forwarding multicast data, e.g.198.18.0.1:60355 <-> 225.0.0.1:1234
, the UDPEndpoint
will bind to225.0.0.1
and try to connect to198.18.0.1
.The default
nic
of tun2 is working on Spoofing mode. When the UDPEndpoint
tries to use a non-local address to connect, the network stack will generate a temporaryaddressState
to build the route, which can be primary but is ephemeral. Nevertheless, when the UDPEndpoint
tries to use a multicast address to connect, the network stack will select an available primaryaddressState
to build the route. However, whentun2socks
is in the just-initialized or idle state, there will be no available primaryaddressState
, and the connect operation will fail. Therefore, we need to add permanent addresses, e.g.10.0.0.1/8
andfd00:1/8
, to the defaultnic
, which are only used to build routes for multicast response and do not affect other connections.In fact, for multicast, the sender normally does not expect a response. So, the
ep.net.Connect
is unnecessary. If we implement a custom UDPForwarder
andForwarderRequest
in the future, we can remove these code.Testing
I have conducted preliminary testing on this patch using Python scripts and a standard SOCKS5 server in a Linux environment, with the following setup:
Create TUN interface
tun0
and assign an IP address for it.Start tun2socks.
Test ipv4.
Logs.
Test ipv6.
Logs.