Architecture

Vue d’ensemble#

                                ┌──────────────────────────────┐
            ISP A ──────────────┤                              │
                                │   Sovereign Edge Firewall    ├── Zone : Clients
            ISP B ──────────────┤   (basculement actif/passif) │── Zone : VPN
                                │                              │── Zone : Anonymisation
                                │   • Filtre stateful           │── Zone : Privacy
                                │   • NAT (par uplink)          │── Zone : DMZ
                                │   • Offloading SSL transparent│
                                │   • Moniteur de bascule       │
                                └──────────────────────────────┘

Le pare-feu s’installe au bord du réseau avec deux liens internet parallèles. En interne, il présente une interface logique à chaque zone isolée.

Haute disponibilité dual-provider#

Deux uplinks (par ex. fibre + LTE/5G ou deux opérateurs) sont connectés en parallèle. Un moniteur de bascule surveille l’état du lien, la joignabilité de la passerelle et la latence, et bascule la route par défaut sur le second uplink en moins de cinq secondes en cas de panne.

Points clés :

• Ruleset symétrique. Les deux uplinks partagent les mêmes règles de filtrage, NAT et scrub. Pas de “bon chemin” ni de “mauvais chemin”.
• NAT dynamique. Le source NAT tire l’IP d’egress de l’interface active dynamiquement — pas d’IP en dur, pas de mappings obsolètes au basculement.
• Override sélectif. Certaines classes de trafic peuvent être épinglées sur l’uplink secondaire (par ex. un chemin proxy anonymisant, une répartition de charge pour des services gourmands en téléchargement).
• Failback automatique. Une fois le primaire en bonne santé, le moniteur restaure la route par défaut automatiquement.
• Tests de bascule. Une procédure définie (voir Exploitation) vérifie tous les trimestres que la bascule fonctionne — pas seulement en théorie.

Segmentation par zones#

Au lieu d’une topologie plate “intérieur/extérieur”, le pare-feu fonctionne sur un modèle multi-zones. Le mouvement latéral entre zones est bloqué par défaut.

Chaque zone possède :

• Son ruleset de filtrage — ce qui entre, ce qui sort.
• Sa politique NAT — quelle IP d’egress, quel uplink préféré.
• Sa couche d’inspection — si HTTPS est intercepté, ce qui est loggué.
• Ses tables whitelist/blocklist — alimentées par les sorties des daemons (voir docs Abusive HTTP Watch).

Couches de sécurité transparentes#

Les endpoints de la zone clients reçoivent les protections suivantes sans aucune configuration locale :

Offloading SSL comme antivirus#

C’est la couche la plus précieuse opérationnellement. Le raisonnement :

• Plus de 90 % des menaces web modernes — téléchargements de malware, payloads de phishing, exploits drive-by — sont livrées sur TLS.
• L’antivirus endpoint (Defender, Bitdefender, …) sur le poste ne voit que le flux chiffré. Il ne peut détecter le fichier infecté qu’après que l’appareil l’ait déballé.
• À ce stade, l’appareil a déjà exécuté les premières étapes de la payload. Le confinement devient gestion d’incident.

Le pare-feu termine plutôt TLS à la passerelle, remet le clair à un moteur antivirus, et seulement ensuite transmet le contenu à l’endpoint. L’endpoint voit un flux déjà scanné. Le malware est bloqué avant qu’il n’atteigne l’appareil.

La CA utilisée pour le bump est la Sovereign Certificate Authority — les clients font confiance aux certificats de la passerelle parce que la racine de la CA interne est installée via la gestion de configuration standard.

Filtre de contenu#

Réseaux publicitaires, domaines de trackers et hosts malveillants connus sont filtrés avant livraison. Réduit le poids des pages, élimine une classe d’attaques supply-chain (JavaScript de régie publicitaire compromis) et améliore la confidentialité.

Tor / passerelle d’anonymisation#

La zone d’anonymisation n’a aucun egress internet direct. Tout le trafic TCP est routé de manière transparente via un daemon Tor local, y compris les requêtes DNS (via un résolveur local qui utilise le port DNS de Tor). Les endpoints de cette zone n’ont besoin d’aucun client Tor local — le réseau force le routage.

I2P / passerelle privacy#

Même idée que la zone Tor, une couche plus profond. Utilisé pour des charges où la confiance dans les nœuds de sortie Tor est également une préoccupation.

Défauts opérationnels#

• Default-deny. Chaque règle autorisant du trafic est explicite. Protection anti-spoofing, validation reverse-path et heuristiques anti-scan tournent par défaut.
• Limites d’état de connexion. Centaines de milliers de sessions parallèles supportées ; les plafonds par source empêchent l’épuisement de la table d’état.
• Normalisation du trafic. Réassemblage TCP, MSS clamping et protection anti-fingerprinting appliqués sur tous les chemins d’egress — important pour les uplinks mobiles et les tunnels VPN.
• Dual stack. IPv4 et IPv6 sont first-class, y compris la mécanique ICMPv6 moderne (Router Advertisement, Neighbour Discovery).

Où le daemon s’insère#

Le daemon compagnon Abusive HTTP Watch écrit une blocklist que le pare-feu consomme via un cron de rechargement de table. Cela ajoute une couche de blocage comportemental au-dessus des règles statiques — les IP qui prouvent qu’elles cherchent des exploits sont droppées au bord.

Ce que ce n’est pas#

• Pas un boîtier vendor à acheter. C’est un motif de livraison, pas une référence produit.
• Pas un projet pour débutants. Faire tourner cela responsablement nécessite des opérateurs compétents (ou le service Exploitation pour les fournir).
• Pas une solution “configurer et oublier”. Les jeux de tokens, les blocklists et les règles de zones nécessitent un entretien — voir Exploitation.