mirror of
https://github.com/juanfont/headscale.git
synced 2026-01-11 20:00:28 +01:00
[Bug] Node registered with preauthkey has expiration of 0001-01-01 00:00:00 in Beta 2. #780
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @yeyeoke on GitHub (Aug 30, 2024).
Is this a support request?
Is there an existing issue for this?
Current Behavior
When creating a preauthkey with the following command:
docker exec -it headscale headscale preauthkeys list --user system
The preauthkey gets created correctly;
ID | Key | Reusable | Ephemeral | Used | Expiration | Created | Tags
1 | KEYID | true | false | false | 2024-09-01 06:54:03 | 2024-08-30 06:54:03 |
However, as soon as I register a node with it, the expiration of that node is set to 0001-01-01 00:00:00.
Expected Behavior
I'd expect a node to get the same expiration as the preauthkey or, at least set the expiration to something which doesn't render the node unusable.
Steps To Reproduce
Create a preauthkey, and register a node with it, check the expiry of that node.
Environment
Runtime environment
Anything else?
No response
@kradalby commented on GitHub (Aug 30, 2024):
Does this also apply to 0.22.3?
This is by design.
A node getting 0001-01... expiry implies that it will never expire. The expiry for the preauth key is for how lon the given key can be used, which is not related to how long the node is approved.
If you want to set an expiry for your node, you can do it with the CLI, or you can set a default in the configuration.
However, if the node is not working because its set to 0001-01..., then this is a bug, it should work forever, please let me know if that is the case.
@yeyeoke commented on GitHub (Aug 30, 2024):
Alright, I actually considered that, but that issue then is that the node, in this case an exit node, can't be enabled in the Tailscale app for iOS. It says the node has expired.
@kradalby commented on GitHub (Aug 30, 2024):
Did this happen for 0.22.3? I'm just trying to understand if it is a regression or have been there all the time.
Is this something you observe on other OSes? (Linux/macOS/Windows)?
@yeyeoke commented on GitHub (Aug 30, 2024):
I currently have no way of verifying if this happened on earlier versions, but I do not believe so since I used the same way of setting up an exit node.
However, yes, the newly added exit-node is shown as expired on both iOS and Mac.
Mac:
iOS:
@yeyeoke commented on GitHub (Aug 30, 2024):
This might also be related;
I have my exit-node in a container via docker-compose
exit-node: container_name: exit-node image: tailscale/tailscale:latest restart: unless-stopped network_mode: host privileged: true environment: - TS_USERSPACE=false - TS_STATE_DIR=/var/lib/tailscale - TS_AUTHKEY=REMOVED - TS_AUTH_ONCE=true - TS_HOSTNAME=VPN - TS_ROUTES=192.168.0.0/16 - TS_EXTRA_ARGS=--login-server=https://vpn.domain.com --accept-routes=false --snat-subnet-routes=false --advertise-exit-node --advertise-tags=tag:exitNode --reset volumes: - /opt/tailscale/config/tailscale:/var/lib/tailscale - /dev/net/tun:/dev/net/tun - /etc/timezone:/etc/timezone:ro - /etc/localtime:/etc/localtime:ro cap_add: - net_admin - SYS_MODULE - NET_RAWWhen I run docker exec -it exit-node tailscale status I get an answer "Logged out".
But when I'm checking with Headscale, it says my machine is connected and working.
@kradalby commented on GitHub (Aug 30, 2024):
I am having a hard time replicating this. I have a my headscale on beta2, my Macbook connected to it and an exit node added via pre auth key, showing 0001-01... expiration and my exit node is showing correctly on the Macbook.
Are you using Postgres og SQLite?
Is there anything interesting in the logs in regards to logging it out?
@yeyeoke commented on GitHub (Aug 30, 2024):
I'm using Postgres. Here's the logs from my exit-node container:
boot: 2024/08/30 14:06:38 Running 'tailscale up'
Warning: IPv6 forwarding is disabled.
Subnet routes and exit nodes may not work correctly.
See https://tailscale.com/s/ip-forwarding
2024/08/30 14:06:38 Start
2024/08/30 14:06:38 active login:
2024/08/30 14:06:38 Backend: logs: be:4dff1321c8609b7e49e8b6499de698098222334ba1511748e526ddd539c9edac fe:
2024/08/30 14:06:38 control: client.Login(0)
2024/08/30 14:06:38 control: client.Shutdown ...
2024/08/30 14:06:38 control: doLogin(regen=false, hasUrl=false)
2024/08/30 14:06:38 control: authRoutine: exiting
2024/08/30 14:06:38 control: updateRoutine: exiting
2024/08/30 14:06:38 control: mapRoutine: exiting
2024/08/30 14:06:38 control: Client.Shutdown done.
2024/08/30 14:06:38 control: control server key from https://vpn.domain.com: ts2021=[umTao], legacy=
2024/08/30 14:06:38 control: RegisterReq: onode= node=[d/CnX] fup=false nks=false
2024/08/30 14:06:38 control: RegisterReq: got response; nodeKeyExpired=false, machineAuthorized=true; authURL=false
2024/08/30 14:06:38 blockEngineUpdates(false)
2024/08/30 14:06:38 active login: system
2024/08/30 14:06:38 Switching ipn state NoState -> NeedsLogin (WantRunning=true, nm=true)
2024/08/30 14:06:38 blockEngineUpdates(true)
2024/08/30 14:06:38 control: NetInfo: NetInfo{varies=false hairpin= ipv6=false ipv6os=true udp=true icmpv4=false derp=#4 portmap= link="" firewallmode="ipt-default"}
2024/08/30 14:06:38 magicsock: endpoints changed: my-wan-ip:40309 (stun), 172.17.0.1:40309 (local), 172.18.0.1:40309 (local), 192.168.4.9:40309 (local)
2024/08/30 14:06:43 health(warnable=warming-up): ok
2024/08/30 14:06:48 health(warnable=no-derp-home): error: Tailscale could not connect to any relay server. Check your Internet connection.
2024/08/30 14:06:48 health(warnable=no-derp-connection): error: Tailscale could not connect to the 'Frankfurt' relay server. Your Internet connection might be down, or the server might be temporarily unavailable.
boot: 2024/08/30 14:07:37 failed to auth tailscale: failed to auth tailscale: tailscale up failed: signal: killed
@kradalby commented on GitHub (Aug 30, 2024):
Sounds like you are running into #764 then, I'm not sure for whom this is triggered, it is a bit surprising since the integration tests run for postgres as well.
We do not actively work on the postgres support, if you do not have a good reason for using postgres, I suggest you try SQLite.
@yeyeoke commented on GitHub (Aug 30, 2024):
Oh, that's actually a simple fix in my use-case since I have no reason at all for using Postgres. I'll try that and see if it works better.
@kradalby commented on GitHub (Aug 30, 2024):
Great, please let me know how it works, we will eventually try to resolve the other issue, but since there is little reason to use postgres with headscale, so it isnt really on our priority list considering other work we have to get resolved.
@yeyeoke commented on GitHub (Aug 30, 2024):
Yeah, I get it. I can report that this solved my issue. Everything works now 👍
@kradalby commented on GitHub (Aug 30, 2024):
Awesome thanks, I'll close this as both resolved and duplicate.