Validates operator-inbound access over the existing offsite WG arc (doc 06): operator peer forwarded operator->box only, box sshd gated to the operator /32, §4.5 box<->box isolation intact (both negatives counter-proven), mutual repair real (agent self-healed a stopped tunnel in ~15s unaided). One TASK-shaping gap: the operator /32 must be a RENDERED conf field — a runtime `wg set` is wiped by the agent's own self-heal. All live-arc changes reverted + baseline re-verified. Docs-only; no code/hub/agent/manifest change. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PSK5g6qYLknKj8u3QAFEr6
23 KiB
SPIKE — OOB management over the existing WG arc (operator peer, isolation, mutual repair) — 2026-07-05
STATUS: COMPLETE — verdict below. Empirically validates the unproven mechanisms of the OOB (out-of-band operator access) design BEFORE the production spec. No production code shipped; no agent binary change; every config change on the live demo arc reverted at cleanup (§13, verified). The design under test: an operator peer on the existing hub-and-spoke WG arc (doc 06), endpoint-forwarded operator→box only, box sshd reachable solely from the operator tunnel IP, while §4.5 box↔box isolation stays intact — and the hub desired-state channel as the tunnel's repair path.
Class: SPIKE (empirical; no product code). Repos: felhom.eu (this doc only); felhom-agent
read-only for grounding (internal/wgtunnel/{manager,loop}.go, internal/desired/syncer.go,
configs/felhom-agent.sudoers); felhom-hub read-only (internal/wgsync/reconciler.go,
internal/store/wg.go).
Probe ends (the LIVE demo arc, ground-truthed in P0):
- Endpoint =
felhom-hetzner(Hetzner CX23, Debian 13,167.233.158.164, DNSep0.felhom.eu), the dev offsite endpoint: WG serverwg0on 443/UDP, tunnel10.77.0.0/24, endpoint10.77.0.1, PBSfelhom-offsite. Peer list is hub-driven (internal/wgsyncSSH push →felhom-peersync). CC-SSH-reachable as root ✓ (the P0 access gate passed). - Box =
felhom-pve/ nodedemo-felhom(192.168.0.162), agent v0.70.0,wg-felhomclient10.77.0.2/32, tunnel toep0:443. CC's LAN SSH to it was the safety line throughout.
Verdict (one line): GO — an operator peer on the existing arc reaches a box's sshd through the
endpoint with a single added /32, at ~24 ms interactive latency, WITHOUT breaking §4.5 isolation
(both negatives held with packet-level evidence); mutual repair is REAL and already built (the
agent self-healed a stopped tunnel in ~15 s with zero hub/LAN involvement, and OOB works with the
agent dead); the one load-bearing gap the TASK must close is that the operator /32 must become a
RENDERED conf field — a runtime-only wg set is wiped by the agent's own self-heal/restart.
0. What "production ep0" this demo could and could not represent
The demo endpoint (felhom-hetzner) is a real public dual-stack cloud VM with a public IPv4,
443/UDP WG, hub-driven peersync, and a real PBS — architecturally identical to the intended
production ep0. So forwarding, isolation, and the SSH-through-endpoint path are represented
faithfully. What it does not represent: (a) a CGNAT customer line — the box here is
felhom-pve on the operator's One-Hungary fixed-cable line (public IPv4 37.191.56.193,
single-NAT), same caveat as the prior spike §5; the OOB path rides the same outbound-mapping
mechanism, so this is low-risk but unproven on true 100.64/10. (b) A second real customer box
— the "dummy customer" was a throwaway netns peer at the endpoint, which is sufficient for the
topology-isolation negative but is not a full second agent. (c) The production ep0 AAAA is
still mis-set per the standing OPERATOR follow-up (memory: "OPERATOR fix ep0 AAAA"); this spike
used v4 throughout, consistent with the agent's v4-pin (doc 06 §4.2).
1. P0 — ground-truth discovery (no changes) — GATE PASSED
Endpoint wg0 (redacted; wg show prints only the public key — dump is BANNED, S1 rule):
interface: wg0 listening port: 443
peer: yV5hFFZF548r6kq2Nl/CiSyOtFb0xYnvEAjw1ofrTCg= (= the box)
endpoint: 37.191.56.193:54900 allowed ips: 10.77.0.2/32
latest handshake: ~1.5 min ago transfer: 5.51 GiB rx / 16.43 GiB tx
wg0.conf: [Interface] Address 10.77.0.1/24, ListenPort 443, MTU 1420 ; [Peer] box only
sysctl: net.ipv4.ip_forward = 0 net.ipv6.conf.all.forwarding = 0
nft: table inet filter { input: drop-policy, allows 22, 443/udp, 8007 iif wg0 only, icmp ;
forward: policy DROP (empty) }
PBS: proxmox-backup + proxmox-backup-proxy active
Box wg-felhom (redacted):
wg-felhom.conf (agent-rendered, "DO NOT EDIT"): Address 10.77.0.2/32, MTU 1280,
Peer f3d1ZI7…= Endpoint 167.233.158.164:443 AllowedIPs 10.77.0.1/32 PersistentKeepalive 25
unit wg-quick@wg-felhom: enabled, active (exited) handshake fresh
agent marker /var/lib/felhom-agent/wg/registered.json:
{"pubkey":"yV5hFFZF548r6kq2Nl/CiSyOtFb0xYnvEAjw1ofrTCg=","assigned_ip":"10.77.0.2/32","generation":5}
sshd: port 22, ListenAddress 0.0.0.0:22 + [::]:22 (NOT interface-scoped today)
pve-firewall: disabled ; nft list tables: EMPTY (no host nft tables at baseline)
Reconcile model (source + journal):
- Box→tunnel reconcile is CONTINUOUS, not generation-gated.
wgtunnel.Loop.Run(internal/wgtunnel/loop.go) callsManager.Applyon every tick —wg_tunnel.interval_seconds = 60(agent.json, confirmed) — AND on each desired-state nudge. The desired-state fetch is generation-gated (desired/syncer.goOnEnvelope, hub pollpoll_seconds = 900), but the wireguard block is cached and re-applied every 60 s regardless. Consequence for probes: any hand-edit towg-felhom.confor a runtimewg setthat diverges from the agent's rendered conf is at risk of being reconciled within ≤60 s. This is why the AllowedIPs widening (P2) used runtime-onlywg set(which the agent does NOT touch — it only rewrites the conf and restarts on a conf-hash change) and why the self-heal in P5b wiped it (§P5). - Endpoint peer-list reconcile (
hub/internal/wgsync/reconciler.go): declarative FULL-list push every 5 min (or on a mutation Trigger); drift (a manually-added/removed peer) is erased on the next push. Proven live at cleanup (§13).
Gate: endpoint is CC-SSH-accessible as root ✓ → proceed.
2. P1 — operator peer, endpoint-side — GO
Throwaway operator + dummy-customer keypairs generated on the endpoint (wg genkey, 0600,
private keys never printed). Registered BOTH into the hub wg_peers registry (not hand-added
to wg0) so they survive the 5-min reconciler — via sqlite3 /data/hub.db in the hub pod
(stdin-piped SQL to avoid the base64 =/+ quoting trap):
operator cdmN4U+fjR18zBk+SKoceJQyz9HgA9+hN8/FiKF1u0o= 10.77.0.250
dummy tQ6eJC9y8pSKtam44DaSrrtYBZYUvZG2z1stS6PsaD4= 10.77.0.251
The hub reconciler pushed both to wg0 in ~150 s (next 5-min tick fired early on a warm loop).
Endpoint forwarding, enabled NARROWLY — ip_forward=1 (was 0) + a named, one-flush nft chain
felhom_spike_oob hung off forward, ALL rules scoped iifname wg0 oifname wg0:
table inet filter { chain forward { … ; jump felhom_spike_oob } }
chain felhom_spike_oob {
iifname "wg0" oifname "wg0" ct state established,related accept # conntrack replies
iifname "wg0" oifname "wg0" ip saddr 10.77.0.250 ip daddr 10.77.0.2 counter accept # operator→box
iifname "wg0" oifname "wg0" ip daddr 10.77.0.250 counter drop # box→operator NEW: drop
iifname "wg0" oifname "wg0" counter drop # box↔box (any other): drop
}
The operator "laptop" is a netns client on the endpoint (spike-op netns, veth to a
192.168.99.0/30 link, wg-op interface, MTU 1280, AllowedIPs 10.77.0.0/24) — an acceptable
stand-in; the crypto+routing path through wg0 is identical to a remote laptop. GO: operator
peer handshakes with wg0 and pings the endpoint 10.77.0.1 at 0.2 ms (on-box netns).
3. P2 — box-side AllowedIPs widening + SSH-over-tunnel + PBS — GO
The minimal box change, runtime-only (nothing persists past a wg-quick restart — see P5):
wg set wg-felhom peer f3d1ZI7…= allowed-ips 10.77.0.1/32,10.77.0.250/32
ip route add 10.77.0.250/32 dev wg-felhom
Exactly one added /32 (+ the return route). wg-felhom.conf mtime UNCHANGED (2026-07-04) — the
agent's rendered conf was not touched.
From the operator netns, through the endpoint's forwarding:
ping 10.77.0.2 → 5/5, avg 24.7 ms, TTL 63 (TTL 63 = exactly one forwarded hop, i.e. via ep0)
ssh root@10.77.0.2 "hostname; pct list; uptime" → interactive session in 1.205 s:
demo-felhom ; 9201 running demo-felhom (+9001/9100/9999) ; load avg 0.43
Interactive SSH over the tunnel works end-to-end.
PBS-path check (mandatory, immediately after the box change):
wg show wg-felhom latest-handshakes → age 73 s (fresh, advancing)
pvesm status --storage felhom-offsite → active (PVE reaches PBS at 10.77.0.1:8007 over the tunnel)
openssl s_client -connect 10.77.0.1:8007 → CONNECTED, Certificate chain present
PBS unaffected = GO condition met. Adding the operator reach did not perturb the backup path.
4. P3 — isolation negative probes (§4.5 must survive) — GO (both negatives, counter-proven)
Negative 1 — dummy customer → box: DROPPED. The dummy peer handshakes with the endpoint (0.2 ms
to 10.77.0.1 — it IS a registered peer) but:
spike-cust → ping 10.77.0.2 → 3/3 packets LOST (100%)
spike-cust → tcp/22 10.77.0.2 → REFUSED/TIMEOUT
felhom_spike_oob box↔box drop counter: 0 → 8 packets / 552 bytes (the drops are real, not a route miss)
Negative 2 — box → operator: NEW connections DROPPED, replies flow. With an operator→box SSH session OPEN (so ESTABLISHED replies were flowing), from the box:
felhom-pve → ping 10.77.0.250 → 3/3 LOST
felhom-pve → tcp/22 & tcp/80 10.77.0.250 → REFUSED/TIMEOUT
felhom_spike_oob box→operator drop counter: 0 → 13 packets / 852 bytes
(while the operator→box accept counter incremented normally — conntrack replies unaffected)
Both hold with packet-level evidence (nft counters), not merely "command timed out". §4.5 isolation survives the operator-peer addition: a box still cannot reach another box, and a box cannot initiate to the operator.
5. P4 — sshd scoping on the box (belt rule) — GO (all three)
A named, one-flush nft table on felhom-pve (baseline had NO host nft tables), independent hook
so LAN and other interfaces are untouched:
table inet felhom_spike_oob {
chain input { type filter hook input priority -10; policy accept;
iifname "wg-felhom" tcp dport 22 ip saddr 10.77.0.250 counter accept # operator only
iifname "wg-felhom" tcp dport 22 counter drop # any other tunnel src
} }
Verified:
- LAN SSH from CC — unaffected (the safety line): the rule matches
iifname wg-felhomonly; LAN commands kept running throughout. ✓ - Operator SSH over the tunnel — still works (accept counter 27 pkts). ✓
- Defense-in-depth — dummy refused at the HOST even if the endpoint belt failed: I temporarily
simulated an endpoint-belt failure (added an endpoint forward-accept for dummy→box AND widened
the box AllowedIPs to include
10.77.0.251/32). Result: dummy→box ping now passes (endpoint forwards it, 27 ms) but dummy→box SSH is dropped at the host (host belt drop counter 5) —Connection timed out. The two layers are independent; the host belt holds when the endpoint layer is bypassed. The temporary widening was reverted immediately after. ✓
6. P5 — mutual repair (the crown probe)
6a. Agent dead, wg alive — GO
systemctl stop felhom-agent (via LAN, simulating no other way in). Then from the operator peer
over the tunnel: SSH into the box (agent DOWN → OOB does not depend on the agent), and
systemctl reset-failed felhom-agent; systemctl start felhom-agent from that session →
active, felhom-agent 0.70.0. OOB works with the agent down AND repairs it.
6b. wg dead, agent alive — GO, ~15 s, and this is THE central TASK finding
systemctl stop wg-quick@wg-felhom (interface gone). Operator SSH over the tunnel now
Connection timed out (OOB down, confirmed). Then, watching the endpoint's view of the box peer
handshake with zero LAN intervention:
box re-handshake observed at +15 s (agent log: "wgtunnel: service inactive with current conf —
re-enabling (self-heal)")
The agent's reconcile loop already covers a stopped unit — Manager.ensureTunnelLocked's
self-heal branch (internal/wgtunnel/manager.go:394-402): conf hash current + isActive() false →
systemctl enable --now. No wg_repair-shaped desired action is needed; the "wg dead, agent alive"
repair path exists today and fires within one 60 s tick (here 15 s). This closes O-B (mutual
repair via the desired-state channel) — with a caveat that becomes the TASK's main work:
THE GAP. The self-heal rebuilds
wg-felhompurely from the agent-rendered conf, whoseAllowedIPsis derived solely frompbs_tunnel_ip/32(renderConf,manager.go:239:AllowedIPs = <pbsIP>/32). After the self-heal, the box's live AllowedIPs was back to only10.77.0.1/32— the operator/32I added at runtime was wiped, and OOB SSH failed until I re-added it. So OOB survival across the agent's own self-heal/restart/reboot REQUIRES the operator peer's/32to be part of what the agent RENDERS into the conf — a runtimewg setis not durable. (Re-adding10.77.0.250/32at runtime immediately restored OOB, confirming the mechanism; it is only the durability that needs the rendered-conf change.)
6c. Failure-domain sweep with an open OOB session — GO
Over a single open operator→box tunnel session: attempted cloudflared stop (it is NOT a guest
systemd unit — it runs as a Docker container in the controller stack, so the unit stop no-op'd;
noted), then pct stop 9201 (whole guest down). The session stayed alive (ALIVE_2, handshake
fresh) — the tunnel terminates host-side on felhom-pve, so guest death cannot touch it — and
pct start 9201 from the SAME session brought the guest back. Post-check: felhom-controller Up (healthy), cloudflared/nextcloud containers Up (healthy). OOB survives the failure domains it
exists for (guest down; and by construction cloudflared/controller down, since OOB is host-side and
independent of the guest's own edge).
7. P6 — usability + environment (record-only)
- Interactive feel over MTU 1280:
top -bn1,pct exec 9201 -- …(into the guest), and a 20 MBdd | wc -cbulk pull all ran cleanly over the tunnel at ~24 ms RTT — no black-holing, no stalls (MTU 1280 is the doc 06 §4.3 floor; interactive OOB is well within it). - Endpoint load during the probes:
load average 0.10— WG forwarding + a shell session is negligible on a CX23. - Active port: 443/UDP (
wg show wg0 listen-port → 443). Relevant to CGNAT: this is the friendly-port path already; the box's NAT source was37.191.56.193:47922(single-NAT public v4, not CGNAT — the standing caveat). - Keepalive:
PersistentKeepalive 25on the box; handshakes stayed fresh (<125 s) throughout.
8. Findings that must shape the TASK
-
Render the operator
/32into the agent conf — the one required agent change (§6b). OOB reach must survive the agent's self-heal/restart/reboot, so the operator peer's tunnel/32must be a field the agent puts inwg-felhom.confAllowedIPs(today hard-derived frompbs_tunnel_ipalone). Shape options for the TASK to pick: (a) extend the hubwireguarddesired-state block with an optionaloob_peer_ip(or a smallextra_allowed_ipslist) and haverenderConfappend it; (b) a separate[Peer]-less allowed-ips widening is NOT enough (WG ties AllowedIPs to the server peer here, and all tunnel traffic transits the one endpoint peer, so the operator/32just joins the existing peer's AllowedIPs). Keep the derivation deterministic and validated (the existingnetip.ParsePrefix//32checks). Nothing else in the agent needs to change for O-A/O-B — reconcile continuity + self-heal already do the repair. -
Mutual repair (O-B) is already built — do NOT add a
wg_repairaction. The 60 s reconcile tick +ensureTunnelLockedself-heal restored a stopped tunnel in 15 s unaided (§6b). The TASK should rely on this, and at most add the tunnel-health→alert wiring already slated for S6 (doc 06 §4.6 stanza exists). Endpoint-side drift repair likewise already works (5-min declarative full-list push erased the spike peers fromwg0.confat cleanup, §13). -
The exact nft rulesets that worked (copy-paste ready). Endpoint forward chain and the host belt are in §2 and §5 verbatim. Both are named, one-flush tables. Production shape:
- Endpoint:
ip_forward=1+ afelhom_oobforward chain:ct established,related accept;saddr <operator/32> daddr <box/32> acceptper (operator,box) pair; a catch-alliifname wg0 oifname wg0 … dropto preserve §4.5 for every non-OOB pair. Note this makes the endpoint's forward posture per-pair allow-list instead of doc 06 §4.5's blanket "forwarding OFF" — the TASK must state that the OOB feature deliberately turns forwarding ON but gates it to operator→box pairs only, and that the box↔box drop is now an explicit rule, not an absent capability. Peersync (felhom-peersync.sh) would need to learn these forward rules, OR they live in the endpoint's static nftables and only the peer list stays hub-driven (simpler; recommended — the operator set is small and stable). - Box (belt, defense-in-depth): a
felhom_oobinet table,inputhook,iifname wg-felhom tcp dport 22 ip saddr <operator/32> accepttheniifname wg-felhom tcp dport 22 drop. Scope strictly towg-felhom; never touch LAN sshd (the safety line). This belongs in the agent's managed surface if the box is to enforce it (a new narrow grant), OR ship as host-install static config; the spike proved the rule works, the TASK picks the ownership.
- Endpoint:
-
AllowedIPs method: runtime
wg setis NOT durable (finding 1); the durable path is the rendered conf. For the endpoint side, the operator peer is a normal hubwg_peersrow (survives the reconciler) — that part needs no new mechanism, only that the operator peer is not a customer host (host_id empty, as the spike used) and is excluded from any customer-facing accounting. -
sshd scoping shape. Today box sshd listens on
0.0.0.0:22 + [::]:22(P0). The spike scoped access with an nft belt oniifname wg-felhom, NOT by changingListenAddress— deliberate: an interface-boundListenAddresswould fight the LAN safety line and the tunnel's late bring-up. The TASK should keep sshd listening broadly and gate at the packet layer (belt rule), exactly as §5. The endpoint forward rule is the primary gate; the box belt is defense-in-depth (both proven independent in §5). -
Measured latencies (production budget input). Operator→box forwarded RTT ~24 ms (One Hungary ↔ Hetzner-DE); interactive SSH incl.
pct list1.2 s wall; self-heal repair ~15 s; endpoint peer-push convergence ~150 s (≤5 min bound). All comfortably interactive. -
Reconcile continuity constraint (from P0, load-bearing for any future OOB probe/op). The box applies its conf every 60 s. Any OOB mechanism that mutates box wg state MUST go through the agent's rendered conf (finding 1), never a side-channel
wg set/hand-edit — those are silently reverted within a tick. This is a feature (drift-repair) to build with, not around. -
Endpoint-access + production prerequisites discovered. (a) The demo endpoint is a real public VM, so O-A is faithfully represented; production
ep0needs the AAAA fixed (standing OPERATOR item) though the v4-pin means OOB rides v4 regardless. (b)cloudflaredin the guest is a Docker container, not a systemd unit — any runbook step that "stops cloudflared" mustdocker stopit, notsystemctl. (c) The hubwg_peersinsert path for a NON-host operator peer exists in the store (AddWGPeerwith empty host_id — the S1 unbound-admin-row shape); a production OOB feature can reuse it or add an explicit operator-peer admin endpoint.
9. What this spike did NOT prove (honest ledger)
- True CGNAT OOB traversal — the box is single-NAT public-v4 (same caveat as the prior spike
§5). OOB rides the same outbound WG mapping as the backup path, so low-risk, but unproven on
100.64/10. - A second real agent box — the dummy customer was a netns peer (sufficient for the topology isolation negative; not a full agent). The box↔box drop is proven by topology + counters, which is the load-bearing property.
- The rendered-conf operator-
/32change itself — finding 1 is the diagnosis (runtimewg setwiped by self-heal, re-add restored OOB); the agent code change to render it is TASK work, not shipped here. - Endpoint peersync owning the forward rules — the spike put forward rules in ad-hoc nft; the TASK decides static-vs-hub-driven (finding 3 recommends static forward rules + hub-driven peer list).
- Long-horizon hold of an idle OOB session (minutes-scale only here; the backup-path 32-min soak is in doc 06 §7).
10. Cleanup assertion (§13 of the plan) — VERIFIED
Hub: both spike wg_peers rows deleted (WHERE note LIKE 'spike-oob-%'); registry back to the
single real peer demo-felhom-01 / 10.77.0.2.
Endpoint felhom-hetzner: operator+dummy peers removed from live wg0; the 5-min reconciler
then rewrote wg0.conf to the box-only peer (drift-repair confirmed live — the persisted conf
self-healed); felhom_spike_oob forward chain + jump rule deleted; ip_forward restored to 0
(the P0 value); spike-op/spike-cust netns + veths deleted; throwaway WG + SSH keys shred -u'd,
/root/spike-oob removed. Final: nft forward chain is the empty drop-policy chain (P0), wg0
lists only the box, ip_forward=0.
Box felhom-pve: runtime AllowedIPs back to 10.77.0.1/32 (operator /32 removed) + return
route deleted; felhom_spike_oob host table deleted (nft list tables empty, as P0); the
spike-oob-operator line removed from /root/.ssh/authorized_keys (grep count 0); /tmp/wgdown_t0
removed. Final baseline re-verified: felhom-agent active, wg-quick@wg-felhom active + handshake
fresh (age 92 s), pvesm status felhom-offsite active, guest 9201 running + controller healthy, no
host nft tables, LAN SSH fine.
No repo/hub/agent/manifest production change — this commit is docs-only.
11. Method bar honored
wg show <if> dump NEVER run (private-key leak ban, S1); only latest-handshakes + redacted conf
reads. Every mutation was a named one-flush nft table or a runtime-only wg set, inventoried as
made. PBS-path re-checked after the box wg change (P2). Negative probes carry nft-counter evidence,
not just timeouts. Surprises recorded as findings (the self-heal wipe of the runtime /32 — finding
1 — is the headline example).