Reactor Scram

I tested the Windows instructions using my Windows Server 2022 VM and the tip of the Windows IPC PR and it works well.

@jamilbk I tested everything else and made a small code fix too, looks like `FIREZONE_NAME` got lost somewhere in the headless Client, so I added it back in. It's ready...

I was using `curl` the whole time, no browser involved. It's possible that there is some DNS caching in systemd that gets reset when the tunnel goes down and back...

Looks like I already had `tracing::debug` in `on_update_resources` and it's definitely getting called as soon as I click in the portal. Actually, the "everyone" group has `ifconfig.net` as a resource,...

I saw `Note: Users will always belong to the Everyone group.` even though it's a service account so that's why I assumed. Opened a ticket asking to clarify https://github.com/firezone/firezone/issues/5064

Yeah I'm seeing the same thing: - `etc-resolv-conf` doesn't have this issue (but I had to set 1.1.1.1 as my upstream resolver, resolv.conf and systemd-resolved didn't seem to play along)...

Yeah `resolvectl flush-caches` might be the command we want. If that doesn't delete `/home` or anything Edit: Docs clarify that `resolvectl` replaces `systemd-resolve` https://manpages.ubuntu.com/manpages/focal/man1/resolvectl.1.html

I'm changing the title back because the replication steps are known to work but I'm still checking out the root cause(s)

I think it's something more subtle than just not flushing the cache, because it replicated on Windows with the headless Client, and I see this line about flushing the Windows...

Okay. So it's not just "Flush when we connect", but "Flush when we connect, or when we add or remove routes"? Do we need to flush when we call `set_dns`...