The problem announced itself the day the third self-hosted service asked me to create its fourth local admin account. Every service wanted its own users, its own passwords, its own idea of who I am — and every one of those accounts was an orphan credential I would forget to rotate and forget to delete. Meanwhile the network side looked done: part 1 had carved everything into VLANs by trust. But segmentation answers which segments can exchange packets and quietly dodges the harder question: which people and devices are allowed to do what. A VLAN doesn’t know who you are. If your security model ends at segmentation, anyone with a foothold in the right subnet inherits everything that subnet can reach — perimeter thinking, and it fails the same way at home as it does in companies. All shell, no bones.

What I tried first was what everyone tries first: keep minting local accounts and keep a mental map of them. That scales to about three services. The fix the lab taught me is the same one enterprises pay real money for — identity as its own layer, with one place accounts are born and one place they die.

Identity gets its own machine — and its own segment

User accounts, groups, and authentication now live in a dedicated identity appliance. It’s one of the few VMs rather than containers in the lab, and it sits in its own VLAN, because the identity service is the root of trust: compromise it and every downstream permission is fiction. The isolation calculus that felt like overkill for a media server is the bare minimum here — a full kernel boundary, a segment nothing else shares, and the management plane unreachable from anything untrusted.

Centralizing identity sounds like enterprise ceremony for a house, right up until you’ve lived the local-admin-account treadmill. One directory, one place accounts are born, one place they die.

Tailscale is the front door

Remote access is where identity and networking actually meet. Nothing in the lab is port-forwarded; the way in is Tailscale — WireGuard underneath, but the part that matters here is who a connection is, not just where it’s from:

  • Nodes authenticate as identities, not addresses. A device joins the mesh by logging in; access follows the login. Lose a laptop and you revoke the device, not re-key a VPN and re-distribute configs.
  • ACLs are policy as code. “This user’s devices may reach the hypervisor’s management interface; that tagged node may reach only the reverse proxy.” It’s a reviewable text file, not a pile of firewall rules re-derived from memory.
  • Keys expire. Access defaults to decaying unless renewed, which is the correct default for anything you’ll otherwise forget about.

The mental shift: the VPN isn’t a tunnel into a trusted network — it’s a per-device, per-identity grant. Being “on the network” stops being a permission by itself.

Identity-checked front door, with a break-glass path around it my devices laptops · phone Tailscale who are you? · ACLs per-identity grant lab services scoped by ACL authn identity VLAN identity VM one directory · root of trust break-glass hypervisor console local root · off the mesh

recovery must not depend on the thing being recovered

Public exposure follows the same scoping logic. The Cloudflare Tunnel from part 1 publishes specific services, not a network: an outbound connection carries named hostnames to a container behind the reverse proxy, and the blast radius of “public” ends at those hostnames. Public ≠ LAN. (This blog dodges the question entirely — it’s static files on a CDN and touches none of this.)

Design for the day identity is down

Here’s the failure I almost built for myself: the identity VM goes down, and every login in the lab depends on it — including, if you’re careless, the login you’d use to fix the identity VM. A circular dependency, waiting to be discovered at the worst time. This is the same lesson the wake-on-LAN gateway taught me at the power layer: recovery paths must not depend on the thing being recovered.

So the lab keeps deliberate break-glass paths: a local root credential on the hypervisor that lives in a password manager and nowhere on the network, and console access that works when SSO doesn’t. The test that matters isn’t “can I log in” — it’s “can I log in while the directory is off.” I ran that drill on purpose before I needed it, and I recommend the experience: a lock you can’t open in a power cut isn’t security, it’s a lockout.

Takeaways

  • Segmentation controls which networks talk; identity controls which people and devices do. You need both — a VLAN doesn’t know who you are.
  • Centralize accounts in one directory, isolate it like the root of trust it is (own VM, own segment), and stop minting local admins.
  • Prefer identity-based mesh access (Tailscale ACLs, expiring keys, per-device revocation) over network-based trust. “On the VPN” should not mean “allowed.”
  • Expose services, never networks: scope public tunnels to named hostnames.
  • Keep a tested break-glass path that works with identity down — the recovery rule from part 4, applied to logins. Drill it before you need it.