OpenVPN management socket: a control channel, not metrics

Ask the management interface for a status once and it starts to look like a status port. It is not one. Once a client is admitted it can issue the protocol's control commands, and the account running that client inherits whatever those commands can do to the daemon. Treating it as a read-only feed is the mistake that turns a monitoring integration into an unauthenticated console.

The belief, and what it costs

The belief is that the management listener is equivalent to a metrics endpoint: attach a collector, read counters, move on. What actually happens is that the collector opens a session with control capabilities, and every other assumption you made about the deployment now depends on that collector behaving well.

Nothing in the interface advertises a read-only mode. There is no observer role to select, and a username in the configuration does not create one.

What an admitted client actually holds

The community daemon accepts one active management client at a time. That single slot means a GUI, a script and a monitoring agent cannot all attach; the second one waits or fails while the first holds the session. If your design assumes concurrent readers, it is already wrong.

Where a periodic snapshot is enough, the status-file output gives you the same numbers without a live session. Writing that file on an interval and reading it with ordinary file permissions keeps the collector outside the control plane entirely, which is the arrangement most monitoring actually needs.

An owned socket, not an open one

A Unix-domain socket keeps the control path off the network, which removes the changing tunnel address from the problem. It does not remove the permission question. The parent directory has to be writable by the service account and reachable by the controller's account, and those are two separate grants:

management /run/openvpn/office-management.sock unix /etc/openvpn/management.password
management-client-user vpn-observer
management-client-group vpn-observer

The password file carries the management secret as its first line. Protect that file like any other credential, and keep its contents out of logs and support tickets. The user and group restrictions are peer checks on the Unix socket, not filesystem permissions, so the intended process needs both the file access and the matching identity.

Making the socket world-accessible to clear a permission error is the one fix to avoid. It converts a local control channel into something any process on the host can drive.

Publishing it over TCP is not the same design

Moving the listener to a TCP port does not make it safer or more convenient. The management password is sent in the clear, so a TCP listener exposes both the credential and the session to anyone who can observe the path. Reaching it from another host requires an authorised administration channel, or a small local agent that exposes only the observations you need.

A password on a plaintext transport is authentication without confidentiality, and that combination is worse than it looks because it feels protected.

Startup dependencies you did not ask for

Several management options change the daemon's lifecycle. Holding startup until a controller connects, or terminating when the controller disappears, turns an optional observer into a hard dependency. A monitoring agent that crashes would then take the tunnel down with it.

Review those options before enabling anything beyond the socket itself. Optional observation should stay optional, and a restart policy should not be coupled to a collector that was added for graphs.

A socket file left behind after a failed process is not proof that a listener exists. Identify which instance owns the path before removing it, and use the service's own recovery workflow rather than deleting files under a running daemon.

What acceptance looks like

Four checks cover the design: the intended controller identity connects, a process without that identity is rejected, the daemon survives a controller that disconnects without warning, and the tunnel still carries traffic through a controlled restart. A successful management connection proves only the control plane. It says nothing about whether private application traffic works, so test that separately. Write the four results down where the next operator can find them.

The management interface documentation describes the single-client model and the privileged nature of the protocol, which is the part worth reading before you point a dashboard at it.