Change allow list to evaluate all vpnaddr tables when available #1330
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wadey
approved these changes
Feb 14, 2025
| Info("Host roamed to new udp ip/port.") | ||
| hostinfo.lastRoam = time.Now() | ||
| hostinfo.lastRoamRemote = hostinfo.remote | ||
| hostinfo.SetRemote(vpnAddr) | ||
| hostinfo.SetRemote(udpAddr) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This changes the allow list to operate on all known overlay addresses for a remote instead of just the currently used overlay address, when possible.
Since the default is to allow all, any deny is specific intent to not communicate with a remote host on that underlay range, so to reflect that intent we need to evaluate the underlay address against each of the overlay addresses allow list tables.
There is 1 tricky spot with stage 2 handshakes where we could operate on all known addresses but that would pollute our noise state since we have to consume the packet and ratchet the state forward to get a full set of overlay addresses in the remote certificate. Currently this is not being done but we can achieve it if deemed necessary, ideally the remote side has identical configuration that would have blocked this underlay route from being used.
There is also a similar issue with the lighthouse where it operates on the overlay address reported by the node instead of all overlay addresses in the hostinfo for the reporting node. If we leave it as it is now then it allows some surgical options in the lighthouse configuration but the effect is mismatched from non lighthouse node configuration.