VPN inventory: intended access, generated config, live sessions
A tunnel name is an observation, not a service record. Join the tenant, the deployed configuration and the accounting evidence before you retire anything.
Every tunnel name looks like an inventory row until you ask who owns it. A name tells you that something is connected right now; it cannot tell you who the service belongs to, what they are allowed to reach, or whether the configuration that produced the tunnel is the one you approved. At fleet scale those three questions are the inventory, and the tunnel is only the latest observation.
One service, three records
The intended service is what the tenant is entitled to: identities, prefixes, resources, and a lifecycle state. The deployed configuration is the generated policy that should realise it. The observed session is runtime evidence that something connected. Treating them as one table collapses three different kinds of truth into a row that is wrong in three ways at once.
| Record | Answers | Goes stale when |
|---|---|---|
| Intended service | Who may reach what | A contract changes and nobody edits the record |
| Deployed configuration | What the gateway was told | A device is edited by hand |
| Observed session | What is running now | Telemetry stops or a session ends |
The practical test is a question each record can answer alone. Ask who owns this prefix and the intended-service record answers. Ask what policy the gateway holds and the deployed record answers. Ask whether anyone used it this week and the session record answers. A column that cannot answer its own question is the one to fix first.
Record the tenant, not the interface
Give each service an identifier that survives a reconnect. A temporary tunnel interface or session number changes for reasons that have nothing to do with the customer, and an inventory keyed on one of those grows a new row every time a link flaps. Key it on the tenant and the service instead, then attach observations to that key.
The record needs the responsible tenant and operator, the accepted peer or user identity, a reference to the credential rather than a copy of it, the protected prefixes, the routing context, the allowed resources, and the intended lifecycle state. Credential material belongs in the supported secret store; an inventory that carries private keys has become a second, worse-protected copy of the estate.
Generated configuration has an owner and a version
Automation makes this easier and hides it better. A generator that runs successfully proves that the template rendered, not that every device matches the output. Somebody will eventually change a gateway by hand during an incident, and that change is the most valuable thing to capture, because it is the one no later run will reproduce.
Record which revision produced the deployed policy, and preserve direct edits as a difference to reconcile rather than overwriting them silently. The reconciliation is the product here: the generator's success and the device's actual state are two facts that have to be compared, not assumed equal.
Sessions are evidence, not authorisation
Where the deployment uses RADIUS accounting, RFC 2866 gives concrete fields to work with. Acct-Status-Type distinguishes a start from a stop, and the records belonging to one session share an Acct-Session-Id. Those fields let you reconstruct when a session began and ended without trusting a dashboard's summary.
An accounting identifier is runtime evidence. It does not define which tenant owns a subnet, and it does not grant access to anything. Correlate it with the gateway and the service identity, then keep the collection time next to the observation. A missing report can be a telemetry failure rather than an absence of use, and an old record is not proof that access remains active now.
Retirement uses the same join
Removing a service means removing the intended access, the credentials, and the live sessions, in that order, through the owners of each. Then verify that the obsolete configuration is gone from the devices and that its permitted paths no longer resolve. A customer who left last quarter should not still appear in a prefix list because the tunnel name was deleted but the route was not.
None of this requires one appliance per function or a particular automation product. The operational requirement is narrower and harder: a customer, its intended access, the deployed policy, and current runtime evidence must be joinable without relying on someone's memory of a tunnel name. Build the three records first, then choose the tools that maintain them.