SD-WAN sécurisé
La moitié réseau du SASE : des overlays chiffrés entre vos sites, provisionnés depuis une seule vue de topologie, et un contrôle par application du lien par lequel chaque flux sort.
La décision est prise par session, d'après ce qu'est le trafic plutôt que d'après le sous-réseau d'où il vient — et elle est reprise quand un lien se dégrade.
Les pare-feu que le client possède déjà, listés par site. Faites-en glisser un sur le canevas et il devient un site raccordé ou le hub.
Tout ce qui arrive au hub principal rencontre la même politique : contrôle applicatif, IDS/IPS, inspection TLS, DLP et passerelle IA. Tracez plutôt un tunnel direct entre deux sites et leur trafic est inspecté aux deux extrémités plutôt qu'au milieu — la console le dit avant que vous ne validiez.
Établi ou non, latence, octets dans chaque sens — sur le lien, là où vous regardez, pas dans un journal qu'il faudrait ouvrir.
Savoir si les sites passent automatiquement sur un hub de secours quand le principal cesse de répondre — et après combien de silence — est un réglage du dessin, pas de chaque pare-feu.
Le canevas sait quand il diffère de ce que les pare-feu exécutent. Un seul bouton écrit la configuration des deux extrémités de chaque tunnel et la pousse.
Zedmos
L'application, sa catégorie, le nom du serveur TLS ou le domaine — ce sur quoi la règle sélectionne. Pas le port, parce que le port a cessé d'identifier quoi que ce soit il y a des années.
Vous
Une seconde ligne internet, un tunnel, ou une interface précise. Vous dites aussi ce qui doit se passer si cette cible est inutilisable : basculer, ou abandonner — pour qu'un trafic qui ne doit jamais sortir autrement que par le tunnel ne prenne pas discrètement la ligne ouverte.
Zedmos
Chaque candidat est sondé sur un cycle court et noté sur la perte, la latence et la gigue. Une ligne qui est debout et perd quatre pour cent des paquets gâche un appel tout en passant chaque test debout/à terre — c'est la notation qui l'attrape.
Zedmos
La session sort par le lien choisi, la règle et la sortie étant écrites dans l'enregistrement — ainsi la question de savoir pourquoi un trafic est passé par là a une réponse.
Adressage, clés et routes sont calculés pour vous, quelle que soit la forme retenue parmi les quatre. Chaque overlay reçoit une plage unique, chaque nœud une adresse dans cette plage, et les routes autorisées de chaque pair sont recalculées quand la topologie change — y compris quand un tunnel direct entre deux sites s'établit ou disparaît. Les clés sont générées sur le pare-feu lui-même et seule la moitié publique est collectée.
WireGuard pour la plupart des déploiements. OpenVPN là où un parc à base de certificats est déjà la norme et où l'équipe d'exploitation le maîtrise. GRE là où le transport est déjà privé et où vous voulez du routage sans seconde couche de chiffrement. La console vous dit ce que chaque choix implique avant que vous ne validiez.
Un hub de secours ne détient que des routes d'hôtes tant que le principal est sain, il n'attire donc jamais de trafic en silence. Quand le principal cesse de répondre, la console y déplace tous les sites — automatiquement si vous l'activez, ou sur votre commande avec un aperçu de ce qui va changer exactement.
Une règle sélectionne le trafic par application, catégorie, nom de serveur TLS ou domaine, et nomme le lien par lequel il doit sortir : un second WAN, un tunnel WireGuard, OpenVPN ou GRE, ou une interface ordinaire. Si cette cible n'est pas saine, la règle peut se replier sur une autre — ou abandonner, pour qu'un flux qui ne doit jamais emprunter autre chose que le tunnel ne sorte pas discrètement par le WAN ouvert.
Chaque lien candidat est sondé sur un cycle de cinq secondes en ICMP, DNS ou HTTP, et noté sur la perte de paquets, la latence et la gigue sur une fenêtre glissante. Un tunnel est jugé sur l'actualité de sa négociation, pas sur l'existence de l'interface. L'hystérésis empêche un lien limite d'osciller.
Cette page expose l'argument. Celles-ci disent comment c'est fait en pratique, écran par écran et réglage par réglage.
Chaque écran et chaque commande de la section SASE de la console, avec les captures : le canevas, les réglages des nœuds, l'accès privé, les applications d'accès, la posture des appareils, le SD-WAN et le moniteur.
Ce qui tourne où : les hubs, les sites, les formes d'overlay, la décision de bascule, et les quatre questions auxquelles répond l'accès privé.
La chaîne d'inspection elle-même : le chemin rapide, la classification, l'évaluation de la politique et la couche d'émission.
Démonstration et tarifs: info@zedmos.com
Demander une démonstration