Locked out of your VPN server: keep a second way in
A broken tunnel should not also remove your ability to repair the server. Plan, test and review an independent administrative path before you need it.
You open the console, change one firewall rule, and the tunnel you were connected through disappears. The change was correct, the reload was not, and now the only route back into the machine is the one you just broke. A second way in is a design decision, and it has to exist before the outage rather than during it.
Walk through what you still have
Start from the console screen in front of you and list the paths that do not depend on the tunnel. A provider web console with a serial or VNC session is one. A management interface on a separate network is another. Physical access is a third, and it is the one people discover is missing at the worst moment.
| Path | Depends on | Usually fails when |
|---|---|---|
| Provider console | Account access and the provider's own API | Credentials live in a wiki only reachable over the tunnel |
| Management subnet | A second interface and its own routing | The bad change was a global route or firewall policy |
| Second tunnel | A different listener, port and credentials | Both listeners were changed in the same edit |
| Physical or local console | Being in the building | Nobody has been in the building for a year |
Read the third column as a failure list rather than an abstraction. Two of those paths usually fail for the same reason. The table is how you notice that before an outage explains it to you.
Independence is a dependency question
A recovery account is not independent if its password is stored in a service you reach through the tunnel. A second VPN on the same host, same port and same firewall policy is not independent either, because the change that broke the first one breaks both.
Walk down the chain and name what each step needs. Network reachability, name resolution, an authentication source, and the management service itself are four separate dependencies, and a path that shares any of them inherits that failure.
The never-tested path deserves its own suspicion. A console that has not been opened in months may require a password reset by email, and that mailbox may be hosted on the machine you cannot reach. Test the path while everything works and you find this on a calm afternoon.
Use the second path for one controlled change
From the console, take a snapshot or copy the configuration you are about to edit. Change one thing. Reload the service and read the result before you touch anything else, because two changes at once turn a recovery into an experiment.
Keep the recovery session open while you do it. The whole value of the second path is that it survives the thing you are changing, so closing it first removes the only property that made it useful.
Verify from the recovery path, not from memory
The check that matters is whether the normal path comes back, and the recovery session is where you confirm it in order:
systemctl status openvpn-server@server --no-pager ss -lntup | grep -E ':(1194|443)\b' nft list ruleset | sed -n '1,40p' journalctl -u openvpn-server@server --since '-10 min' --no-pager | tail -n 30
Read the service state first, then the listener, then the rules, then the journal. A service that is running with no listener points at the service configuration, while a listener with no reachable rules points at filtering. The order matters because each step narrows the next, and skipping to the journal usually means reading errors that describe the symptom rather than the cause.
The systemctl documentation covers the status and restart behaviour used here, including how a failed reload leaves the previous process running. Restoring a coherent revision beats reconnecting repeatedly from a client that cannot repair the server. If the rollback condition you defined before the change has been met, restore and stop.
Keep the inventory current
Review the access list when people or infrastructure change. Test the recovery path while everything works. Retire the accounts nobody has used since the last reorganisation. Two outdated accounts and one expired certificate are a small cleanup on a Tuesday and an outage on a Sunday.
Record who can use each path, what it permits and how the credentials are rotated. A recovery path with no owner becomes a forgotten entrance, which is a different kind of failure from being locked out.