One VPN account across two servers: three state ledgers

One account that can sign in to either of two VPN nodes raises a design question long before it raises a software question. The account view, the network each node owns, and the session that a connected client holds are three different kinds of state, and they fail in different ways when you copy them around. Copying all three into one system is a common way to lose one of them.

Work through the three ledgers below in order. Each one asks what is authoritative, what is local, and what happens when the other node is gone, and the answers do not follow from each other.

Who may connect: one authority, many nodes

Start with the admission ledger: which identity source is authoritative, which certificate issuers are trusted, which accounts are eligible, what second factor applies, and what each account may reach. Then write down how each node learns about changes, and how quickly.

A shared database is one possible component of that answer. It is not proof that every relevant policy lives there, or that every node applies a change at the same moment. An account disabled at node A but still accepted at node B means the offboarding process has not finished.

Decide what a node does when the authority is unreachable. Accepting cached credentials during an outage is a policy choice with a security cost, and rejecting them is a policy choice with an availability cost. Either is defensible; leaving it undocumented is not.

Keep issuer authority separate from account data as well. Several gateways can trust the same CA without holding its signing key, and each node still needs its own server certificate and its own client-side trust relationship.

What a node owns: addresses and routes

The second ledger is local to each node: listener address, server identity, address pool, routes to private resources, resolver policy, and how traffic leaves toward the internet. The same account can be served by either node while these objects stay distinct.

The return path is the part that gets forgotten. If both nodes hand out addresses from the same pool, the private network cannot tell which node owns a given client, and the reply may be sent to the wrong place. Different pools need routes and permissions too, so a distinct number range is not a complete design.

Direct clients to a node deliberately. DNS selection, client endpoint lists, and a front-end service are different mechanisms with different health and failover behavior. Choosing one is fine; treating "load balancing" as the design leaves the return path and the failure behavior undefined.

A documented product example helps here. Pritunl's replication documentation treats the VPN network as a per-replica object, and clients on different replicas need extra routes and connectivity to reach each other. That is a product-specific arrangement, not a recipe for Community OpenVPN, but it shows why adding a replica changes the network and not only the account store.

What a session is: live state, not a row

The third ledger is the live session. A connected client has protocol state and a network assignment on the node that accepted it. The account being known at the other node does not give that node the session, the keys, or the ability to continue the packets.

Be explicit about what happens when a node fails. The supported outcome may be a reconnect to the other node with fresh authentication and a new address, after which the application recovers in its own way. If uninterrupted handoff is required, that requirement needs explicit implementation support, not an inference from database replication. Write the answer down where the on-call engineer can find it.

Capacity rules need the same treatment. A limit of two simultaneous sessions per account can only be enforced across nodes if some authority has a coordinated view of occupied slots. Node-local lists and a historical account record do not add up to that view.

Testing the three ledgers

Exercise each one separately. Sign in through node A, then through node B, and confirm both succeed with the expected address ranges. Withdraw an identity and check both nodes, not just the one you happened to test. Then stop one node and observe what the client and the private application actually do.

Include the return path in the acceptance test. A client that connects to B but cannot receive replies from a resource behind A has passed the admission check and failed the network one, and that distinction should appear in the report.

Only when all three ledgers have an explicit owner, a change path, and a failure behavior is the multi-node account design complete. Copying a configuration file across nodes answers none of those questions.