Teardown tunnel automatically if peer's certificate expired #370
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
|
|
ton31337
force-pushed
the
feature/validate_peer_cert_with_tunnel_status
branch
3 times, most recently
from
be368eb to
f670376
Compare
ton31337
changed the title
ton31337
force-pushed
the
feature/validate_peer_cert_with_tunnel_status
branch
from
f670376 to
ac84e19
Compare
ton31337
changed the title
ton31337
force-pushed
the
feature/validate_peer_cert_with_tunnel_status
branch
from
ac84e19 to
91793df
Compare
ton31337
force-pushed
the
feature/validate_peer_cert_with_tunnel_status
branch
3 times, most recently
from
6b5bb37 to
33a7a59
Compare
|
Can we please also have a notice "Node X's certificate has expired, tearing down connection" in the logs? |
ton31337
force-pushed
the
feature/validate_peer_cert_with_tunnel_status
branch
from
33a7a59 to
71b2c4a
Compare
|
@virtadpt added more logging regarding disconnection. |
|
So, monitor output for "Invalid certificate status", and then suss out the value of Works for me. I'll give it a try this weekend. |
|
@rawdigits @nbrownus any chance to review this? |
|
@ton31337 Not yet. I'm still working 90 hour weeks. |
|
I finally went off call yesterday. I'll give it a try when I have a moment. |
nbrownus
reviewed
Sep 14, 2021
ton31337
force-pushed
the
feature/validate_peer_cert_with_tunnel_status
branch
from
71b2c4a to
f96d554
Compare
Handle this with periodic keepalive ticks. This is needed to avoid hanging a connection even peer's certificate expired. In case you use short-lived certificates (let's say 2 hours), current behavior is a bit wrong, because the tunnel stays UP and RUNNING fine unless restarted nebula service. This is the log from how it's reflected. ``` time="2021-05-12T10:15:51Z" level=debug msg="Tunnel status" tunnelCheck="map[method:passive state:alive]" vpnIp=172.17.90.241 time="2021-05-12T10:15:59Z" level=debug msg="Tunnel status" tunnelCheck="map[method:passive state:alive]" vpnIp=172.17.90.241 time="2021-05-12T10:16:06Z" level=debug msg="Invalid certificate status" certName=ton31337 vpnIp=172.17.90.241 time="2021-05-12T10:16:06Z" level=debug msg="Tunnel status" tunnelCheck="map[method:passive state:alive]" vpnIp=172.17.90.241 time="2021-05-12T10:16:06Z" level=debug msg="Tunnel status" certName=ton31337 tunnelCheck="map[method:active state:testing]" vpnIp=172.17.90.241 time="2021-05-12T10:16:20Z" level=debug msg="Tunnel status" tunnelCheck="map[method:active state:alive]" vpnIp=172.17.90.241 time="2021-05-12T10:16:20Z" level=info msg="Tunnel status" certName=ton31337 tunnelCheck="map[method:active state:dead]" vpnIp=172.17.90.241 time="2021-05-12T10:16:20Z" level=debug msg="deleting 172.17.90.241 from lighthouse." time="2021-05-12T10:16:20Z" level=debug msg="Hostmap hostInfo deleted" hostMap="map[indexNumber:3347248980 mapName:main mapTotalSize:844 remoteIndexNumber:3605974939 vpnIp:172.17.90.241]" ``` Signed-off-by: Donatas Abraitis <[email protected]>
ton31337
force-pushed
the
feature/validate_peer_cert_with_tunnel_status
branch
from
f96d554 to
1246442
Compare
wadey
approved these changes
Oct 20, 2021
nbrownus
added a commit
that referenced
this pull request
Oct 20, 2021
nbrownus
added a commit
that referenced
this pull request
Oct 20, 2021
nbrownus
added a commit
that referenced
this pull request
Oct 20, 2021
wadey
added a commit
that referenced
this pull request
Mar 18, 2022
This restores the hostMap.QueryVpnIP block to how it looked before #370 was merged. I'm not sure why the patch from #370 wanted to continue on if there was no match found in the hostmap, since there isn't anything to do at that point (the tunnel has already been closed). This was causing a crash because the handleInvalidCertificate check expects the hostinfo to be passed in (but it is nil since there was no hostinfo in the hostmap). Fixes: #657
wadey
added a commit
that referenced
this pull request
Apr 4, 2022
This restores the hostMap.QueryVpnIP block to how it looked before #370 was merged. I'm not sure why the patch from #370 wanted to continue on if there was no match found in the hostmap, since there isn't anything to do at that point (the tunnel has already been closed). This was causing a crash because the handleInvalidCertificate check expects the hostinfo to be passed in (but it is nil since there was no hostinfo in the hostmap). Fixes: #657
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.
Handle this with periodic keepalive ticks. This is needed to avoid
hanging a connection even peer's certificate expired.
In case you use short-lived certificates (let's say 2 hours), current
behavior is a bit wrong, because the tunnel stays UP and RUNNING fine
unless restarted nebula service.
Signed-off-by: Donatas Abraitis [email protected]