Maintain access as a security system

A VPN you built once and never touched again drifts toward being a liability. Access systems need operation, not just installation.

Start with the population of things that can connect. Remove lost or retired devices quickly. On the WireGuard side, the interface itself tells you which peers are alive:

sudo wg show wg0 latest-handshakes
# xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=   1785171243
# mAbc9xkQGVpDzR7wFJ2sLuNvTq81cYheKf0iW5nBOEU=   0

The number is a Unix timestamp of the last handshake. Turn it into a date with date -d @1785171243. A 0 means that peer has never connected, so ask yourself why it is still configured.

A peer silent for months is a removal candidate. Delete its [Peer] block from wg0.conf and restart the interface with sudo systemctl restart wg-quick@wg0. On the Cloudflare side, review the device list in the dashboard and revoke stale registrations. Then re-check that the enrollment rule still lists only the identities you intend.

Patch the VPN endpoint and the connector host. These machines process input from the Internet by design. Running last year’s cloudflared or an unpatched kernel on the WireGuard server undermines everything the tunnel protects. On Ubuntu, apt list --upgradable tells you in one line whether you are behind.

Review who can edit routing and policy. A dashboard admin is a network admin, whatever their job title says. If five people can edit Gateway policies, five people can open the private network.

Keep logs long enough for the risks you accepted. Handshake history, policy logs, and connector logs are what turn “something looks wrong” into an answer. Without them, an incident review is guesswork.

Test recovery without weakening access permanently. Here is the classic failure. An outage happens, someone adds a broad allow rule “temporarily”, and the rule outlives the incident by years. Time-box exceptions. Put the removal date in the rule’s name, like TEMP allow all 10.0.0.0/8 remove by 2026-10-01, where the next reviewer will trip over it.

A tunnel that still connects is not necessarily healthy. Re-run both the allowed and the denied tests after any meaningful change. A routing edit can widen access quietly while every existing connection keeps working, and only the denied test catches it.

My advice: a fifteen-minute monthly review. Peer list, device list, policies, versions, one allowed test, one denied test. Write the results down, every time, in the same file.

Boring is exactly what you want from an access system. If the monthly review ever gets exciting, you found a problem before it found you.