Rebalancing RustDesk and a subnet router across Proxmox nodes

RustDesk and the first Tailscale subnet router went onto the original Proxmox host back in April, alongside the rest of the services that used to live on my gaming PC. A second Proxmox node joined the lab not long after, as part of a separate project rebuilding HA DNS on Proxmox. That DNS work isn’t retold here. What this post covers is the piece that came after it: moving RustDesk to the new node and giving the subnet router a second, redundant copy there too, then proving both moves actually held under test.

The subnet router gets a redundant partner

A single subnet router is a single point of failure for every LAN service reachable over Tailscale. The fix was a second router on the newer Proxmox node, advertising the same LAN route as the first.

Before calling it done, I ran separate failover tests: stopped each router in turn and confirmed access to the LAN survived either one being down. Both directions passed. That’s the actual property a redundant router pair needs, not just “both show as connected.”

The access check also ran from a host outside the LAN, not just from a machine already sitting on it. A route that only works for local traffic hasn’t proven anything about the case the router pair exists for, a remote client reaching the LAN when it isn’t there in person.

Moving RustDesk, and checking it for real

RustDesk moved to the newer node too. Its clients were retargeted to the new location, and then I did the thing that actually matters for a remote-access tool: opened a real remote session end to end, not just confirmed the service was up and listening. A process that starts isn’t the same as a connection that works when you need it.

Cleaning up without losing the rollback

The old copy of the subnet router stayed in place on the original node as a rollback option while the new one was being validated. Once the new router passed its checks, I took an active backup before removing that duplicate VM. Keeping a stale rollback around longer than needed is its own risk: an old copy that starts up by accident can fight the current one for the same role.

An unrelated outage the same day

Later the same window, during separate monitoring-VM staging work, the original Proxmox node briefly stopped responding at the LAN layer. Ping, SSH, and the Proxmox UI all went quiet while the second node stayed reachable. The recorded cause was a recently changed AC adapter; it was swapped back to the known-good one and the node started responding again. I’m noting it here because it happened in the same window as the rebalance, not because it’s part of the same story. It doesn’t change anything above, and I’m not calling the hardware side of it closed here.

What this actually proved

Moving a service and moving a failover path aren’t the same test. RustDesk needed a real session, not a green status light. The subnet router pair needed its route checked from somewhere that wasn’t already on the LAN, with each router taken down in turn. Both got that proof before I called the move done, and the backup-before-cleanup step meant the old copies could go without losing a way back if something had gone wrong.