ks2/nas-seed: retire nuc's wg-ks4 now, not after the seed

The plan gated nuc's tunnel teardown on the nas leg being seeded, on the
assumption nuc stayed a viable fallback target. It is not one: its
ks4backup pool was deleted when the disk moved, and its data pool is a
512 GB SSD against a ~1.75 TiB replica set. So the tunnel was doing
nothing except re-establishing a keepalive'd link to ks4 on every boot of
a machine that is now powered off between uses.

Disabled 2026-08-31 (wg-quick@wg-ks4 disabled, interface down, ks4 incus
remote removed from nuc). The config and key are deliberately kept, so it
is one systemctl away if ever needed — deleting them would mean
regenerating keys and re-peering on ks4.

transmission-bt is unaffected: its tunnel is in-container and a separate
peer (10.8.0.21), verified still handshaking with egress 193.70.35.17.

Remaining: drop nuc's now-unused peer on ks4's wireguard container.
Harmless to leave, safe to do any time, recorded with the pubkey.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Julien Lutran
2026-08-31 10:32:21 +02:00
co-authored by Claude Opus 5
parent 3c6b762038
commit 4c6396a8fa
+25 -11
View File
@@ -14,11 +14,20 @@ SATA on the new host `nas` (`192.168.0.4`,
Consequences versus the original plan:
- Target pool `ks4backup` is now backed by `tank/backup/ks4` on nas.
- The **WireGuard tunnel moves too**: nas becomes peer `10.8.0.22`;
nuc's `wg-ks4` (`10.8.0.20`) is retired once this works. nuc no longer
needs a tunnel at all — `transmission-bt`, its only other user, now
runs on nas and carries its own in-container tunnel (`10.8.0.21`,
unchanged, ks4 needs no edit for it).
- The **WireGuard tunnel moves too**: nas becomes peer `10.8.0.22`.
`transmission-bt`, the only other user, moved to nas and carries its
own in-container tunnel (`10.8.0.21`, unchanged — ks4 needs no edit
for it).
- ⚠️ **nuc's `wg-ks4` was already disabled on 2026-08-31**, *before* the
seed, not after. The original plan retired it only once nas was
seeded, on the assumption nuc could serve as a fallback target — it
cannot: its `ks4backup` pool was deleted and its `data` pool is a
512 GB SSD, far too small for the ~1.75 TiB replica set. Keeping a
keepalive'd tunnel alive on a machine that is now powered off between
uses bought nothing. `wg-quick@wg-ks4` is `disabled`, and the `ks4`
incus remote was removed from nuc.
`/etc/wireguard/wg-ks4.conf` and its key are **kept**, so it is one
`systemctl enable --now wg-quick@wg-ks4` away if ever needed.
- ks4's ufw rule is unchanged: traffic arrives masqueraded as the
`wireguard` container (`192.168.1.18`) whichever peer sent it.
@@ -84,13 +93,18 @@ incus start solar-restoretest && incus exec solar-restoretest -- systemctl is-sy
incus delete -f solar-restoretest
```
Once verified, tick the nas gate in the [ks2 plan](plan.md) and retire
nuc's tunnel:
Once verified, tick the nas gate in the [ks2 plan](plan.md).
Only one piece of nuc's retirement is still outstanding — dropping its
now-unused peer on ks4. Harmless to leave (an unused peer costs nothing)
and safe to do at any time, since nuc's tunnel is already down:
```sh
# on nuc
systemctl disable --now wg-quick@wg-ks4 && rm /etc/wireguard/wg-ks4.conf
# on ks4
incus exec wireguard -- wg set wg0 peer <nuc-pubkey> remove
# on ks4 — nuc's pubkey is 31Tlgloc…
incus exec wireguard -- wg set wg0 peer 31TlglocNJyooDVAO8HWEC0lyCykhbaFIWVWFUCOrmQ= remove
incus exec wireguard -- wg-quick save wg0
```
Deleting `/etc/wireguard/wg-ks4.conf` + `.key` on nuc is deliberately
**not** done: they cost nothing and regenerating keys would mean
re-peering on ks4.