VirMach-assigned OS hostname wasn't very identifiable. Renamed the
NetBird peer (and NB_HOSTNAME env) to virmach-lax — vendor + airport
code convention that scales if more VirMach VPSes in other regions
get added later (virmach-nrt, virmach-fra, etc).
New FQDN: virmach-lax.netbird.selfhosted
Operations reference: ssh root@virmach-lax.netbird.selfhosted
OS-level hostname left as StrongHotpink-VM (provider default).
External VM 141.11.93.252 had SSH locked to specific source IPs
(tailscale0, HiNet WAN, one other). Mac couldn't reach it from
other ISPs. Solved by joining the VM to our NetBird mesh and adding
an iptables ACCEPT rule for wt0:22.
Run into the same Tailscale kernel-mode iptables-legacy collision
already documented in peer-deployment-ops.md — systemd oneshot
workaround fixed it.
Doc now describes both the temporary ProxyJump solution and the
permanent mesh-membership solution, plus a config strategy of
retiring per-IP whitelists in favor of a single wt0 ACCEPT rule.
Dashboard's 'SSH Access is disabled' warning confuses new users
who can clearly ssh into peers just fine. These are two different
systems: Dashboard's SSH Access is NetBird's own in-daemon SSH
tunnel server (accessed via Dashboard Connect button or
'netbird ssh'), while the regular ssh command uses the target
machine's OpenSSH running on port 22 and has nothing to do with
the Dashboard SSH toggle.
Home-lab use cases rarely need the NetBird built-in SSH — regular
OpenSSH over the NetBird overlay is sufficient. Doc explains when
you would actually want it (browser-based terminal from Dashboard,
credential offloading to NetBird identity, etc) and how to enable
if needed.
