Cloning a VPN Server Image Without Cloning Its Identity

The image boots, the service starts, and clients connect. That is the moment to stop and ask which of two very different operations just happened. Either the copy is restoring one logical gateway that previously existed, or it is adding a second gateway to the fleet. Both are legitimate, and they have different identity and access consequences. A machine that comes up cleanly proves neither.

Three conditions decide the answer, and they are the three buckets of material an image can carry. Sort them before the image is built, not after it has been deployed twice.

First decide which of the two operations you are doing

A restore keeps one service identity. The old instance is gone, the name and certificate stay, and clients continue to trust the same endpoint. An addition creates a second identity that clients, logs and revocation all have to distinguish.

The distinction is not cosmetic. If two live hosts present the same gateway certificate, a client cannot tell them apart, an audit trail cannot either, and revoking that certificate removes both at once. That may be exactly what a deliberate high-availability design wants, and it is rarely what a hurried image copy intends.

So the first decision is a sentence, written down before the image leaves the build host: this copy restores gateway A, or this copy becomes gateway B. Everything after that is bookkeeping against the sentence. If nobody can write it, the copy is not ready to build.

Reusable inputs, identity and authority, deployment state

The reusable bucket is the easy one: packages, reviewed configuration that contains no secrets, service templates, hardening settings. This is what an image is genuinely good at, and it can be reproduced without limit.

The identity and authority bucket is where copies go wrong. A gateway's private key and certificate identify that gateway to every client. The certificate authority's signing key is a different object with a different power: it issues identities. Trusting an issuer does not mean every new gateway needs the ability to issue, and shipping the signing key inside an image grants that ability to anything that can read the image.

The deployment state bucket is the one people forget because it looks like configuration. Listener addresses, address pools, pushed routes, resolver settings and local integration all encode assumptions about the first host. A second node that copies them can allocate from a pool that another gateway already owns, or point clients at a resource that exists only next to the original.

What a new node must be given, and by whom

An independently managed node should receive its own credentials through the approved enrollment process, with the signing operation happening where the signing key lives rather than on the new host. Record which identity can be withdrawn without disturbing the other nodes; if the answer is "all of them", the design has one identity pretending to be two.

Network values deserve the same treatment. Choose a pool, a listener address and a set of pushed routes that do not collide with the existing gateway, and write them into the provisioning inputs rather than into the image. The input is reviewable; the image is not.

There is a legitimate middle case. A supported recovery or replication design may deliberately keep one logical service identity across hosts, with controlled access to the old copy and a rotation plan. That is a decision with an owner, not a default that happens because the image was convenient.

openssl x509 -in /etc/openvpn/server/server.crt -noout -subject -issuer -dates
find /etc/openvpn -name '*.key' -o -name '*.pem' | head -20

The first command tells you which identity the node actually presents and who signed it. The second is a starting inventory, not a proof: private material can live outside that directory, inside an application database, or in a snapshot layer that the running filesystem no longer shows.

What a copy of the image quietly carries

Deleting a file from the newest revision of an image does not remove it from older revisions, layer caches or the snapshots taken while it existed. That is why credential-bearing images have to be treated as sensitive objects for their whole lifetime rather than only at the moment they are built.

Check the image contents and the provisioning inputs as separate questions. The image answers "what is inside this artifact", while the inputs answer "what will this instance become at first boot". A clean image with a bootstrap script that fetches a shared key answers the first question well and the second badly.

Keep recovery images that legitimately contain secrets restricted to the people who need them, and record where they are stored. The alternative, an image that is convenient because it works without any provisioning, is the same image that grants whoever finds it the gateway's identity. Only one of those two tasks shows up in a build log.

Admission checks before production

Before the node takes traffic, confirm four things: the identity it presents, the clients it will accept, the resources it is permitted to reach, and the return path for the addresses it hands out.

systemctl status openvpn-server@lab --no-pager
ss -lunp 'sport = :1194'
ip -4 route show table all | grep -F '10.90.'

Then check the negative case, which is the one that catches accidents: does the new node have administrator or client access that was intended for the original? A copied configuration can carry an extra client entry, an inherited management route, or a push directive that made sense on the first host.

If an image containing live secrets has already moved beyond its approved boundary, replace the credentials and contain the copies. Removing the file from the latest build is not the same as retiring the credential that older copies still hold, and the gap between those two facts is exactly the window an attacker needs.