Fünf Ebenen. Ein Binary. Ein zentrales Fenster darüber.
Zedmos ist bewusst schlank: die Engine, ein Control-Socket, ein Log-Writer und ein Identitäts-Abruf. Alles, was Sie in der Oberfläche sehen, ist eine Sicht auf dieses System — kein separates Produkt mit eigenem Paketpfad.
Was die Administration sieht gegenüber dem, was läuft
Die Konsolen-Oberfläche (oder die Hub-Oberfläche im SASE-Modus) ist das einzige Bedienelement. Jedes Modul darunter — NGFW, SD-WAN, SASE und Identität — teilt sich dasselbe Engine-Binary und dieselbe Richtlinien-Datei.
Ein Pfad, acht Stufen
Jedes Teilsystem in einer Spalte
Eingang → Shared-Memory-Ring → Flow-Cache → L7-Inspektion → TLS-Inspektion → Policy-Match → Mehrfach-Aktion. Zero-Copy, Worker pro Kern, Batches zu 256 Paketen. Vollständig im User-Space, keine Kernel-Warteschlange.
Ein UNIX-Socket nimmt JSON-Befehle entgegen — Richtlinien neu laden, Feeds tauschen, Routen ändern. HTTPS-API für die Fernverwaltung, signiert mit der Lizenz-CA.
Ereignisse landen auf einem Single-Producer-Shared-Memory-Ring. Ein dedizierter Log-Writer liefert sie an Ziele für Datei, Syslog, SQLite und Elasticsearch. Ein Write-Ahead-Log sorgt für Persistenz; adaptives Sampling hält priorisierten Verkehr unter Last erhalten.
AD-DC-Agent, Microsoft Graph und SCIM ziehen den Verzeichnis-Zustand in einen lokalen Speicher. Die Verknüpfung IP ↔ Nutzer ↔ Gerät erfolgt auf dem Fast-Path zum Zeitpunkt der Richtlinien-Auswertung.
Lokaler Ereignis-Speicher für Einzelstandorte, mit einer strukturierten Export-Pipeline für die Integration in ein SIEM an mehreren Standorten. Atomare Schreibvorgänge über alle Backends hinweg.
Das Hub-Backend verwaltet das verschlüsselte Overlay-Mesh, verteilt Richtlinien an Hubs und Spokes, aggregiert SLA- und Health-Werte und löst atomares Failover aus, sobald der Primär-Hub degradiert.