Fix duplicate nodes due to incorrect implementation of the protocol#1058
Fix duplicate nodes due to incorrect implementation of the protocol#1058
Conversation
6bed35c to
7b7a5e0
Compare
|
Cheers to you @juanfont . Thanks for the quick fix. Looking forward to trying it. |
|
I tested latest Linux Tailscale client with your branch machinekey-in-noise. I could only login when Headscale DB is empty. Once I login and logout, next login will fail ( |
12c8bec to
991abae
Compare
|
@awsong can you describe the steps you followed? I am not being able to replicate your issue. |
Here's my steps:
Client side:
Now my server DB is empty, you can try to connect to it with user |
|
@awsong I have managed to replicate it! Looking at it... |
Tested your latest fix, now it works fine. Logout/login multiple times, IP stays the same, Headscale reports same machine key and different node key each time. |
3da8e91 to
cb8e601
Compare
|
Looking forward to this fix 🙌🏻 |
| } | ||
|
|
||
| for _, client := range allClients { | ||
| _, _, err = client.Execute([]string{"tailscale", "logout"}) |
There was a problem hiding this comment.
Maybe make a nice .Logout() for this
108e755 to
946723f
Compare
…onn from the handlers In TS2021 the MachineKey can be obtained from noiseConn.Peer() - contrary to what I thought before, where I assumed MachineKey was dropped in TS2021. By having a ts2021App and hanging from there the TS2021 handlers, we can fetch again the MachineKey.
946723f to
623f058
Compare
Under certain conditions we could get duplicated nodes (e.g., after logout/login, reported in #1054) - due to a misunderstanding from my side on the role of MachineKey in TS2021.
MachineKeyin TS2021 (the permanent-ish key associated to a client) is no longer sent in the body of the protocol requests, but obtained from the methodPeer()in thecontrolbase.Connstruct. I was not aware of this (cheers @awsong for the heads up!). Our TS2021 was completely droppingMachineKeyFixes #1054