Trois architectures de référence. Un seul moteur au cœur de chacune.
Un guide de déploiement pour les topologies courantes. Pour chaque scénario, vous trouverez les exigences de plateforme, les caractéristiques d'exploitation et les erreurs qui créent le plus souvent des frictions en pratique.
Un site, une plateforme, en ligne ou routé.
Le chemin le plus court de l'évaluation à la production. Un seul boîtier durci héberge toute la pile Zedmos — moteur, politique, correspondance d'identités et interface d'administration.
- OPNsense 24.x ou plus récent, ou pfSense CE 2.8.x
- Interface 1 GbE ou 10 GbE multi-files
- Quatre cœurs et 8 Go de RAM pour une inspection de l'ordre du gigabit
- Huit cœurs et 16 Go de RAM pour une inspection de l'ordre de 10 Gbps
- Un pilote d'interface compatible chemin rapide — validé à l'installation
- Interface d'administration locale, sur le boîtier lui-même
- Magasin d'événements local avec transmission SIEM optionnelle
- Rechargement à chaud des politiques et du renseignement sur les menaces
- Installation réversible et non destructive
- Passer directement à l'application sans référence en mode observation
- Mélanger d'anciennes piles de filtrage sur le même chemin de données
- Tourner sur des générations de pilotes non prises en charge sans validation préalable
Deux boîtiers à l'état synchronisé.
Une paire redondante en actif-passif. La politique, l'identité et l'état d'exécution restent synchronisés, si bien qu'une panne du nœud principal est transparente pour les utilisateurs.
- Deux boîtiers identiques
- Interface de synchronisation dédiée
- IP virtuelle côté LAN et côté WAN
- Même version du moteur et même génération de politique sur les deux nœuds
- État de politique et d'identité répliqué en temps réel
- Promotion tenant compte de la santé, avec dérogation de l'exploitant
- Une seule vitre d'administration couvre les deux nœuds
- Reprise en un clic après un épisode de double maître
- Faire tourner des versions de moteur différentes sur les deux nœuds
- Synchroniser sur un segment LAN saturé
- Laisser la préemption active alors que le lien de synchronisation est dégradé
Paire de hubs, orchestrateur, sites distribués — dans l'une des quatre formes.GA
Un overlay géré qui relie les agences, les points de sortie cloud et les personnes distantes à un plan de politique central, dans la forme dont le parc a besoin : un hub, une paire de hubs, des tunnels directs entre les sites qui en ont besoin, ou un maillage complet. L'application est distribuée ; la politique, l'identité et l'observabilité sont centralisées.
- Deux nœuds hub (physiques ou virtualisés), huit cœurs et 16 Go chacun
- Orchestrateur durci avec un magasin de données répliqué
- Des points d'accès publics joignables pour les deux hubs
- Sites : boîtiers d'agence, petites passerelles Linux, ou utilisateurs distants avec un client WireGuard standard
- Distribution centralisée de la politique et de l'identité
- Bascule et retour automatiques entre hubs, orchestrés par la console
- Chaîne d'observabilité structurée vers le SIEM de votre choix
- Modèle d'exploitation multi-locataire disponible
- Héberger la console sur le même site que le hub principal — c'est la console qui déplace les sites
- Surcharger un hub unique au-delà de son enveloppe de capacité mesurée
- Laisser des sites sans point d'accès de repli vers le hub de secours