Nullfeld-/Room-Fakten — Antwort auf die kurze Fragenliste

Von: Branko → OZMAI
Stand: 23. September 2026
Typ: EXTERNAL_SOURCE (Inbox-Regel §3 — keine automatische Geltung)

Antwort auf die fünf Fragen vor dem OZM-Inbox-Schritt. Alle Angaben mit Primär-
quelle im SOT (OZM_Nullfeld_v1). Nichts erfunden; wo etwas bewusst offen ist,
steht das so da.

1. Zielhost + Plattform

  • Host: crumbzero02 (Mesh-Name = NetBox-Handle)
  • Plattform: Raspberry Pi Zero, aarch64-cross-Build; Deploy-User sysop
  • Quelle: ZERO_DEPLOY_v0.md (Phase 1), docs/OUTBOX_BUILD_TARGET_ZERO_v0.md

2. Room-WG-Adresse / Port

  • Hub/Nullfeld-Tunnel-IP: 10.42.0.1
  • WireGuard-Server-Port: 51820 (wg0)
  • Öffentliche Hub-IP: 194.164.194.191
  • Dienste über den Tunnel:
  • 10.42.0.1:8443 — HTTPS
  • :8788 — questions-core (SOT-RAG-Server, 127.0.0.1 lokal / über Tunnel)
  • 10.42.0.1:1883 — MQTT
  • Quelle: questions-core/src/crumb_vpn.rs (Zeilen 66–76, 189–233 live geprüft
    2026-08-13 via wg show wg0 / ss -tlnp), docs/OUTBOX_BUILD_TARGET_ZERO_v0.md

Aussagegrenze: die :8443/:1883-Zeilen sind geplant/teilweise nicht
lauschend im letzten Live-Check (siehe crumb_vpn.rs observed). :8788 und der
Hub selbst sind bestätigt.

3. Nullfeld-WG / Route / Firewall

  • Tunnelnetz: 10.42.0.0/24, 16 Peers konfiguriert (Stand 2026-08-13)
  • Route: client-initiiertes Pull-Modell, Zero greift ins Nullfeld hinein —
    Nullfeld ruft nie zum Zero (OUTBOX_BUILD_TARGET_ZERO_v0.md)
  • Firewall: Härtungsmodul vorhanden (questions-core/src/firewall_hardening.rs)
  • Quelle: questions-core/src/crumb_vpn.rs, docs/OUTBOX_BUILD_TARGET_ZERO_v0.md

4. Pfad- / Key-Konvention

  • Tunnel-IP-Regel: neue Raspis ab .22 → crumbzero02/RC1 = 10.42.0.22/32
  • SSH-Key: auf der SD geboren (Pi Imager OS-Customisation), nur Public-Key-Auth;
    der Zero hält nie einen Git-Cred, pusht nie selbst
  • Deploy-Ziele: /home/sysop/…; Missionsbaum zur Laufzeit unter
    CRUMB_MISSIONS_ROOT (Repo-Layout: missions-bash/missions/)
  • Hub-Public-Key (öffentlich): nsVtizXiFfG4+aWR1J+floEMGcKNOjcEAfr94921TnA=
  • Quelle: scripts/RC1_ONBOARD.md, CLAUDE.md

5. Deployment-Sollstandsweg

Bewusst OFFEN. Die Kette existiert als Pre-Code
(netbox-raspis.yml → vpn-hub.yml → scp crumb-missions + .service), aber
der Transportkanon hält Deployment absichtlich zurück:

  • „kein Deployment in diesem Architekturstand"
  • Key-Injection/Provisionierung = getrennte, offene Entscheidung
  • Scheduler/systemd/WireGuard-Deploy = getrennte, offene Entscheidung
  • davor: unabhängiger Review des nullfeld Pull-Clients (M3C-G7-R0)

Quelle: OZMAI_BRAIN/20_ARCHITECTURE/OZM_INBOX/OZM_INBOX_TRANSPORT_CANON_v0.1.md
§9, ZERO_DEPLOY_v0.md

Kurz: 1–4 sind reale, im SOT geprüfte Fakten. 5 ist per Kanon noch nicht
festgelegt — „gibt es noch nicht / getrennt zu entscheiden" ist hier die
korrekte Antwort, keine Lücke.