2026 OpenClaw MeshMac in der Praxis: Mehrknoten-Gateway fail-closed, Proxy-Whitelist, validate-JSON und Drift-Patrouille

Warum Gateways unter Kollaboration abdriften

Ohne maschinenlesbare Verifikation gewinnt die schnellste lokale Problemumgehung: ein Kollege erweitert auf gw-b die Upstream-Liste, damit ein Webhook wieder grün wird — gw-a und gw-c bleiben streng. Für Nutzerinnen wirkt das wie „manchmal blockiert das Gateway“, für Security wie Split-Brain-Policy.

1. Keine Single Source of Truth: gateway.proxy.yaml lebt nur auf einem Host im Editor, nicht im gleichen Commit wie die übrigen Knoten.
2. Laufzeit-Injekte außerhalb des Repos: LaunchAgent-Umgebungsdateien oder Shell-Profile setzen Proxy-Endpunkte, die in Reviews nie auftauchen.
3. Weiches Fehlverhalten: Knoten mit fehlgeschlagener Validierung, die trotzdem Traffic annehmen, erzeugen Muster, die wie Upstream-Ausfall aussehen — Drift bleibt unsichtbar bis zum Incident.

Governance-Fokus: Drift ist ein Kooperationsproblem. Behandeln Sie policy_revision und mesh_node_id als Pflichtfelder in jedem Change-Ticket, nicht als Debug-Luxus.

Kurzmatrix: Proxy-Laufzeit-Posture

Reproduzierbare Schritte und Befehle

1. Node-Version vereinheitlichen. Auf jedem Gateway-Host node -v ausführen und eine LTS-Hauptlinie wählen — typischerweise Node 22.x oder Node 20.x. Gemischte Major-Versionen ändern OpenTelemetry- und TLS-Defaults und täuschen Proxy-Drift vor.

2. Dieselbe Gateway-Build-Installation. Internen Paketkanal oder Tarball mit Hash pinnen, openclaw version im Ticket ablegen. Den allgemeinen Rollout-Rhythmus mit dem Leitfaden Mehrknoten-Deploy, Installation und Config-Sync abstimmen.

3. Checkpoint A (vor jeder Policy-Änderung).

mkdir -p .meshmac-checkpoints/2026-04-25-gateway
cp gateway.proxy.yaml .meshmac-checkpoints/2026-04-25-gateway/
cp com.openclaw.gateway.plist .meshmac-checkpoints/2026-04-25-gateway/ 2>/dev/null || true

4. 2026.4.x-orientierter fail-closed-Block. Setzen Sie proxy.runtime.fail_closed: true, listen Sie allowed_patch_channels und allowed_upstream_hosts explizit auf, verbieten Sie Wildcard-Reload-URIs. Unbekannte Schlüssel oder Parserfehler sollten Start verweigern (deny start), nicht „warnen und weiterlaufen“. Geheimnisse nicht inline in Git: siehe IM-Bindings und Token-Rotation sowie Plugin fail-closed für konsistente harte Kanten über dem Gateway.

5. Doctor, dann strikte Validierung mit JSON.

openclaw gateway doctor --json | tee /tmp/gw-doctor.json
openclaw gateway validate --config ./gateway.proxy.yaml --strict --json | tee /tmp/gw-validate.json

Prüfen Sie in gw-doctor.json, dass keine versteckten Warnungen Ihre Canary überspringen; --strict sollte bei Policy-Lücken mit nicht-null deny_reason oder fehlendem ok abbrechen.

JSON-Erwartung und Mehrknoten-Diff

Erwartetes validate-JSON (vereinfachtes Beispiel — Feldnamen an Ihre OpenClaw-Version anpassen):

{
  "ok": true,
  "mesh_node_id": "meshmac-pool-7",
  "policy_revision": "gateway-proxy@2026-04-25.3",
  "fail_closed": true,
  "allowed_upstream_hosts": ["api.meshmac.internal", "hooks.slack.com"],
  "deny_reason": null
}

Solange ok nicht überall true ist oder policy_revision divergiert, ist das Mesh nicht promotionsbereit. Normalisieren Sie die Ausgaben, damit Schlüsselreihenfolge keine falschen Grün-Signale erzeugt:

for id in gw-a gw-b gw-c; do
  ssh "$id" 'openclaw gateway validate --config /etc/openclaw/gateway.proxy.yaml --strict --json'
done | jq -s 'sort_by(.mesh_node_id)' > /tmp/all-gw.json
jq -c '.[] | {mesh_node_id, policy_revision, fail_closed}' /tmp/all-gw.json

Optional: zwei aufeinanderfolgende Snapshots mit diff -u vergleichen, nachdem Sie beide mit jq -S . sortiert haben. So wird Drift aus parallelen Merge-Requests sichtbar, bevor Lastverteiler den fehlerhaften Knoten bevorzugen — ergänzend zur Betriebssicht aus Lastverteilung und Failover.

Rollback-Checkpunkte

Checkpoint B direkt nach erfolgreicher Canary-Validierung: dieselbe funktionierende gateway.proxy.yaml mit Suffix .ok kopieren. Rollback-Reihenfolge bei Produktionsanomalien: Dateien aus Checkpoint A zurückspielen, LaunchAgent bzw. systemd-Unit neu laden, auf jedem Knoten erneut openclaw gateway validate --strict --json bis ok wahr ist, danach erst eingehende Routen wieder öffnen. Ticket-ID und ausführende Person im Änderungslog festhalten — das ist der minimale Audit-Pfad für Drift-Governance.

Token- und Port-Isolation (Kurz)

• Admin-Introspection nur an 127.0.0.1 auf einem dedizierten Loopback-Port binden.
• Webhook-Listener auf getrenntem Port hinter Edge-ACL; keine Bearer-Tokens in committed YAML — Schlüsselbund oder Secret-Manager-Handle per Umgebungsvariable.
• Kein Port-Sharing mit Debug-Servern oder lokalen Mock-APIs, die Kolleginnen temporär „mal schnell“ starten.

Drift-Signale und Alarmfelder

Binden Sie Ihre Log-Pipeline so, dass fehlende strukturierte Felder so hart fehlschlagen wie ein false ok. Mindestens diese Spalten sollten bei jedem validate-Lauf vorhanden sein: mesh_node_id, policy_revision, fail_closed und — falls abgelehnt — ein nicht leeres deny_reason. Wenn ein Knoten nach einem Reload eine niedrigere Revisionsnummer meldet als seine Peers, behandeln Sie das als Priorität zwei neben „ok false“: oft liegt ein partiell kopiertes Bundle oder ein Race zwischen Dateischreiben und Dienst-Neustart vor.

Für wöchentliche Drift-Reviews genügen drei Kennzahlen: Anzahl Knoten mit identischer policy_revision geteilt durch Gesamtknoten, Zeit seit letztem grünen validate auf jedem Host (Stale-Timer), und Anzahl manueller Proxy-Reloads außerhalb des CI-Kanals. Steigt die dritte Zahl, während die erste fällt, fehlt typischerweise ein Merge in Ihr Konfigurations-Repository — nicht „mehr Monitoring“, sondern strengere Promotionsregeln sind die Hebel.

Patch-Artefakte niemals über schwebende latest-Tags beziehen; pinnen Sie Digest oder Semver und tragen Sie den Wert in dieselbe JSON-Zeile wie policy_revision ein, damit Post-Mortems ohne Rätselraten auskommen.