Reconnecting an OpenVPN client: three controls, three scopes

Someone asks for the VPN client to be reconnected, and the request can mean three different things. It might mean dropping one authenticated session, telling every client that a UDP server is going away, or restarting the daemon itself. Each has a different blast radius, and choosing the wrong one turns a single-user fix into an outage. The scope is the decision, and the command follows from it.

Ask who should be affected before asking which control to use.

One instance: the management interface

A configured management interface can list connected instances and drop exactly one of them. Each session carries a client identifier, and client-kill CID targets that identifier rather than a common name. Read the live identifier from the current status output, because a value copied from an older log refers to a session that no longer exists. Dropping the instance ends that connection and nothing else.

It does not guarantee a new connection. Whether the client comes back depends on its retry settings, its remaining remote entries, its authentication requirements and whether the supervising application is still running. A returning client gets a new identifier, which is why comparing identifiers is the only reliable way to tell old from new.

A UDP exit notice is not a per-client command

explicit-exit-notify is a configuration directive about exit and restart events. On a UDP client it tells the peer that the session is ending, and the numeric argument controls how many times the notification is retried. When the server runs over UDP it sends a restart control message to its connected clients, and the documented values distinguish reconnecting to the same server from moving to another remote entry. That is a lifecycle signal with a broad audience.

Nothing in it selects an arbitrary client at an arbitrary moment. Treating it as a reconnect button reaches every connected session at once.

Signals act on the process, not on a session

SIGUSR1 asks a running process to restart its connection without rereading the configuration, and the persistence options decide what survives that restart. SIGHUP goes further: it rereads the configuration file and reopens its resources. SIGTERM and SIGINT request an orderly shutdown. Those are process-level operations: on a multi-client server they affect every session the process carries, not the one named in the ticket.

When the process runs under a service manager, use the manager's own control rather than signalling a PID you found in a process listing. Read the unit to see which signal the manager sends, because a restart and a reload do different things to the same daemon.

Decide the scope before choosing the control

Three questions settle it. Who should be affected: one user, every client of one server, or the daemon and everything it carries. What should survive: the configuration, the tunnel state, or neither. Who is authorized to do it: the management integration, the service owner, or the network operator who controls the exit notification. Answer those and only one control fits.

Adding an unauthenticated control listener to get a reconnect button hands far more than that button to whoever can reach the port.

Verify the new session, not the disconnect

A disconnect event proves the old session ended. It says nothing about a new one authenticating, receiving an address, installing routes, or reaching the resource the user needed. Check the new identifier, then the tunnel state, then one real resource. Those three steps are the difference between a reconnect and a working connection.

Write the scope into the change record. 'Reconnected the client' is not a description when the client was one of forty on a shared server.