Wireguard only peers #2892
Wireguard only peers #2892
Conversation
Starting work towards issue juanfont#1545
Mostly written by Claude, with review and corrections by me
…net nodes This allows us to properly utilize the idea of multiple KnownNodeIDs for a single WireGuard node. Limitations in the previous types required all of them to share a single masquerade address which isn't realistic. A single WireGuard-only node has some properties which are essential to this peer (e.g. public key, endpoints), and some properties which vary depending on which tailnet node wants to connect to it (e.g. masquerade address). This commit adjusts the whole wg-only peer feature to deal with this logical separation.
iridated
requested review from
juanfont,
kradalby,
nblock and
ohdearaugustin
as code owners
|
Hello, thanks, just to manage expectations, I'm gonna have to look at this every ones in a while, because it is very overwhelming, and I will still prioritise the current roadmap and the work I have to do. At a first glance, it does look promising, but I am very concerned about the maintenance burden over time. That said I am positive to ultimately getting it in. |
This comment was marked as spam.
This comment was marked as spam.
|
Just checking back in as this PR is in my mind, I am just not sure what to do or how we should tackle it yet. In addition to maintenance, my genuine main concern with this PR is that I suspect most users do not understand what "WireGuard peers" will mean, even if both I and @iridated have written up what it actually allows. That said, I am still fairly committed to eventually get it in, but we need to split it up and do it bit by bit, and we need to find a way to ensure we can support it over time. I think it is unrealistic to get it in before 0.31.0, which means we aim to redo the API/gRPC before hand making a lot of the 6000 lines in this PR obsolete. I think a meaningful first step would be to factor out all of the WireGuard server-side code into a new PR that is rebased on top of the current main, so we can start to review and test the data structures. I appreciate that not having the CLI/API makes it harder to test, but for now, lets try to just get the amount of code into a size that is reviewable, and make the automated tests run by keeping it rebased on top of main. Speaking of keeping it on top of main. As I expect this effort to take some time, a reasonable measure for maintainability is going to be to keep it up to date on top of main, which will also measure community commitment. If we do not manage this, the effort will likely go stale and I suspect it will sit there until I eventually have time or want to prioritise it. Currently it is not going to make any roadmap for a long time. |
3 participants
Implements #1545 as discussed in that feature
Checklist