-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add modes to the wireguard backend to use a single tunnel for both address families #1527
Add modes to the wireguard backend to use a single tunnel for both address families #1527
Conversation
fwiw the first commit (private ip helper) is from #1513 which i had to close as the source branch name confuses the flannel testsuite... Not sure if it's worth re-opening by itself; the outstanding question afaict there was from @luthermonson whether we can get rid of that code if flannel bumps its golang version (which iirc is the case, but bumping golang versions is not my choice to make :p) |
b5565a0
to
9702ee0
Compare
@manuelbuil going to need you to look at this one... it's probably up your alley |
9702ee0
to
436086c
Compare
Add IsPrivate methods to IP4 and IP6 to determine if a ip address is in the private range. similar to IsPrivate of net.IP in newer golang versions. Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
94b3ebf
to
31b1968
Compare
Allow users to configure a wireguard backend mode which determines how the tunnel(s) are setup. The current method (a tunnel per address family) is kept as a "seperate" mode on top of that three modes are added that use a single wireguard tunnel overe which traffic for both network families travels. Specifically the following new modes are added all using a single tunnel: * ipv4: Use the remote nodes ipv4 address as wireguard pper * ipv6: Use the remote nodes ipv6 address as wireguard pper * auto: automatically determine which remote node address (v4 or v6) to use. (default) The main benefit of these new modes is that all combinations of nodes only need to have a single viable network path between them to setup the full mesh. For example if in a dual-stack setup (some) nodes have no viable ipv4 path the mesh can simply run over ipv6. This also simplifies firewalling as it only requires a single port to be open. And finally it avoids having odd issues where node pods can connect over one address family but not the other due to only one tunnel having connectivity. Signed-off-by: Sjoerd Simons <sjoerd@collabora.com>
31b1968
to
4fae30a
Compare
Description
Release Note