docs: Unraid re-enrolled on Tailscale as 100.100.208.69

Unraid's Tailscale plugin node had been logged out since roughly May 2026.
Re-enrolled as xtrm-unraid (100.100.208.69); the stale 100.100.208.70 node
was deleted first, so the tailnet issued a new address.

Dropped the old 192.168.31.0/24 advertisement — that subnet is only the
macvlan shim and nothing reachable lives there. No LAN subnet routes are
advertised from Unraid; the MikroTik container stays primary. accept-routes
and accept-dns stay off, the former because Unraid sits on 192.168.10.0/24
and would otherwise loop.

Tailscale SSH enabled, since sshd binds only 192.168.10.20 and
192.168.31.250 and so never listens on the Tailscale IP. Port forwarding
over it verified.

Exit node advertised, pending approval in the admin console.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/09-TAILSCALE-VPN.md

@@ -191,7 +191,8 @@ Tailscale VPN running as a container on MikroTik hAP ax³, providing remote acce
 | Tailscale IP | Device | Status |
 |--------------|--------|--------|
 | 100.74.219.35 | MikroTik hAP ax³ (container) | Online |
-| 100.100.208.70 | xtrm-unraid | Online |
+| 100.100.208.69 | xtrm-unraid (Unraid plugin) | Online |
+| 100.100.208.70 | xtrm-unraid (old node, deleted 2026-11-03) | Removed |
 | 100.112.103.7 | hapax3 (old native install) | Offline |
 | 100.75.93.123 | mikrotik-tailscale (previous container) | Offline |
 
@@ -206,3 +207,87 @@ Tailscale VPN running as a container on MikroTik hAP ax³, providing remote acce
 3. **Container Network:** Both AdGuard and Tailscale share the 172.17.0.0/24 network but have separate veth interfaces
 
 4. **Accept Routes:** If subnet routing is needed, add TS_EXTRA_ARGS="--accept-routes" to environment
+
+---
+
+## Unraid Tailscale Plugin Node — 2026-11-03
+
+The Unraid server runs its own Tailscale node via the **Tailscale plugin** (not a
+container), separate from the MikroTik container documented above. It had been
+logged out since roughly May 2026 and was re-enrolled on 2026-11-03.
+
+| Item | Value |
+|------|-------|
+| Tailscale IP | `100.100.208.69` |
+| MagicDNS name | `xtrm-unraid.tailf789e1.ts.net` |
+| Daemon | `/usr/local/sbin/tailscaled` 1.96.2, `-tun tailscale1` |
+| State dir | `/boot/config/plugins/tailscale/state` (survives reboot) |
+| Previous IP | `100.100.208.70` — stale node deleted, so a new IP was issued |
+
+### Prefs set
+
+| Pref | Value | Reason |
+|------|-------|--------|
+| `--advertise-routes` | none | The old `192.168.31.0/24` advertisement was dropped. That subnet is only the macvlan shim (`br0-shim` holds `192.168.31.250/32` with one host route to `192.168.31.4`) — nothing reachable lives there. |
+| LAN subnet routing | not advertised | The MikroTik container is primary for `192.168.10.0/24`, `.20`, `.25`, `.30`. A second advertiser for a subnet Unraid itself sits on would create a routing conflict. |
+| `--advertise-exit-node` | on | Redundant with the hAP today, kept as a fallback on the 24/7 box. **Needs approval in the admin console** before it appears in `tailscale exit-node list`. |
+| `--accept-routes` | **false** | Critical. Unraid is *on* `192.168.10.0/24`; accepting the hAP's route for its own subnet would loop. This is why `tailscale status` reports the health warning "Some peers are advertising routes but --accept-routes is false" — expected here, not a fault. |
+| `--accept-dns` | false | Keeps local AdGuard resolution intact (Unraid AdGuard is config master). |
+| `--ssh` | on | Tailscale SSH. Needed — see the sshd caveat below. |
+
+### SSH over Tailscale — the sshd caveat
+
+`/etc/ssh/sshd_config` on Unraid binds explicitly and has **no wildcard**:
+
+```
+Port 422
+ListenAddress 192.168.10.20   # br0
+ListenAddress 192.168.31.250  # br0-shim
+```
+
+So **sshd does not listen on `100.100.208.69`**. Port 422 on the Tailscale IP is
+closed and stays closed unless a `ListenAddress` is added — which needs a go
+script, because Unraid regenerates this file per interface at every boot.
+
+Access on the Tailscale IP is served by **Tailscale SSH on port 22**, handled by
+`tailscaled` itself and authenticated by tailnet identity rather than by an SSH
+key:
+
+```bash
+# direct, independent of the MikroTik subnet router
+ssh root@100.100.208.69
+ssh root@xtrm-unraid.tailf789e1.ts.net
+
+# port forward — verified 2026-11-03 (Unraid web UI returned HTTP 302)
+ssh -N -L 18089:127.0.0.1:80 root@100.100.208.69
+```
+
+The default tailnet ACL uses `action: "check"`, so the first connection in each
+period opens a browser re-auth prompt. Fine interactively, but it will stall an
+unattended tunnel; switching that rule to `accept` for `autogroup:self` in the
+admin console removes the prompt.
+
+### The other path — via the MikroTik subnet router
+
+Independent of the Unraid node and still working:
+
+```bash
+ssh -i ~/.ssh/id_ed25519_unraid -p 422 -N -L 18088:127.0.0.1:80 root@192.168.10.20
+```
+
+Forwarding works here only because Unraid's stock sshd config denies it globally
+and re-enables it for root alone:
+
+```
+AllowTcpForwarding no           # limetech - disallow forwarding but see below
+...
+Match Group root
+AllowTcpForwarding yes          # limetech - permit only root SSH tunneling
+```
+
+Any non-root account added later will not be able to open tunnels.
+
+### Open item
+
+- Approve the advertised exit node for `xtrm-unraid` in the Tailscale admin
+  console (Machines -> xtrm-unraid -> Edit route settings).