VPN drops when the screen goes dark: lock, blank or suspend?

When someone says the VPN died when the screen went dark, the first useful question is which of three events actually happened: the session locked, the panel powered down, or the whole machine went to sleep. Those are separate mechanisms on separate timers, and only one of them can stop a process from being scheduled at all. Work through the checks below in order. Stop at the first one that answers the question, because every check after it is answering something else.

Check one: separate the lock from the blank from the sleep

A lock changes who is allowed to use the session; the compositor keeps drawing, the network stack keeps running and the VPN client never notices. Display blanking turns the panel off after an idle interval and leaves the machine fully awake. Suspend stops the CPUs, which means no userspace process gets scheduled at all, so no keepalive can fire no matter how short you set the interval.

That table is why "the screen went dark" is not a diagnosis. A desktop set to blank at five minutes and suspend at thirty will show a dark screen at minute six with a perfectly healthy tunnel. The failure at minute thirty is a different event with a different fix, and both look identical from across the room.

Check two: put power and network events on one timeline

Read the journal for a bounded window rather than the whole boot, and include both the login manager and the connection owner:

journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --list

The first command shows sleep requests, resume, and the network transitions that followed them. The second shows what is currently holding an inhibitor lock, which tells you whether something is deliberately blocking sleep and which program it is. Adjust the unit names if your connection owner is not NetworkManager, and remember that reading another user unit or the system journal depends on local policy.

A missing line is not a negative result. If the journal for the selected unit is not visible to your account, the absence of a suspend record proves nothing, and concluding "it never slept" from an empty filter is how people end up tuning keepalives for a week.

Check three: if it suspended, decide whether that was intended

Once a sleep transition is on the timeline, the question changes from why the VPN broke to whether the machine should have slept at all. On a laptop the answer is often yes, and the tunnel outage is expected behaviour that the client should recover from on resume. On a workstation that is supposed to stay reachable, the sleep policy is the thing to change. Deciding which of those two machines you are looking at takes one question, and it is not a question the journal can answer for you.

Change it through the controls that belong to the logged-in session, or through an administrator-supported mechanism if the requirement is machine-wide. Editing a display manager setting while logged in as another account is not the same action and will look like it worked until the next session starts. Disabling power management entirely is a broad first response that costs battery life and hides the actual policy question.

Check four: if it stayed awake, look at the network and the client

An awake machine that lost its tunnel has one of three stories: the access network dropped, the VPN client stopped or restarted, or the server side expired the association while the client kept believing it was connected. Compare the timestamps of the underlying link event with the tunnel event, and be precise about which came first.

Then test the recovery path separately from the original session. A fresh request through the recovered tunnel can succeed while the long-lived application session opened before the outage remains broken, because the application is holding a stale socket or a cached address. That is an application problem, not evidence that the tunnel failed to come back.

What a useful report contains

Write the sequence with timestamps and owners: when the session locked, when the display blanked, whether a sleep request was recorded, when the link went down and came back, when the tunnel changed state, and what the application actually did. Each item has an owner, so each item can be handed to the right person instead of becoming a general complaint about Linux.

If any of those rows is missing, that is the next thing to measure rather than the next thing to change. A timeline with a gap is more informative than a settings change made on a hunch.