Operate the tailnet safely

A private network accumulates old devices and permissions unless someone deliberately removes them. Nothing rots loudly.

The old intern’s laptop stays enrolled. A test route stays approved. A forgotten reusable key stays valid. Each one is harmless until it becomes the way in. Operating a tailnet is mostly scheduled subtraction.

The monthly review

Once a month, go through the same list. Walk the Machines list in the admin console, sorted by last seen, and question anything silent for a month. Delete retired nodes. Check the Keys page for auth keys and OAuth clients you cannot explain, and revoke them. Look at every approved subnet route and exit node and ask whether it is still needed. Routes are easy to approve and easier to forget.

Client versions matter too:

tailscale version
# 1.102.3

Old clients miss security fixes and path-negotiation improvements. Update them.

After updating, re-run your policy tests by saving the policy, then do one real check of the critical path:

tailscale ping lab-server
ssh ubuntu@lab-server 'echo ok'

If ok comes back, the path you depend on still works. This takes ten seconds and catches the update that changed something.

Keep a recovery path outside Tailscale

If Tailscale SSH is your only access and a bad policy edit locks you out, you cannot fix the policy that locked you out. You need one way in that does not depend on the system you are administering.

A cloud console, a physical keyboard, or classic SSH on a tightly firewalled public port all work. Test that path during the monthly review too. A recovery path you have not used in a year is a hope, not a path.

The lost-device runbook

When a device goes missing, revoke access first. Not “look for the laptop”, not “ask around”. Revoke, then investigate.

A revoked device can be re-enrolled in minutes if it turns up in a jacket pocket. The reverse mistake, waiting while someone else holds a live tailnet identity, has no undo.

Write it down

Write a monthly checklist and a lost-device runbook. Include who can approve devices, edit policy, advertise routes, and recover a locked-out server.

Use names, not roles. A runbook that says “an admin” helps nobody at 2am. A runbook that says “Anna has console access, Flavio has the policy editor” gets the right person out of bed.