Optimisation réseau de bout en bout avec Antigravity et le Conseil, configuration d'OPNsense et nouvelle structuration du foyer İnci de Kastamonu

Résumé : Un abonnement fibre à haut débit ne garantit à lui seul ni une faible latence, ni une connexion stable, ni un réseau sécurisé. Des algorithmes de file d'attente du cœur de réseau aux calculs de taille de paquet PPPoE (MTU/MSS), des fuites DNS à l'isolation VLAN dans les immeubles à plusieurs étages, si chaque couche n'est pas correctement configurée, même une ligne à 1000 Mbps subit des coupures instantanées, une inflation de tampon (bufferbloat) et de graves failles de sécurité. Dans cet article, j'aborde d'abord les principes d'ingénierie fondamentaux et les mesures de sécurité qu'il faut absolument connaître lors de la mise en place ou de l'amélioration d'un réseau. Ensuite, je partage l'optimisation de bout en bout réalisée avec Google Antigravity et notre conseil d'intelligence artificielle de 12 membres sur notre propre station de travail Linux et sur notre pare-feu OPNsense (FreeBSD 15.1), puis, enfin, la nouvelle structure mise en place pour le Foyer d'Études Supérieures pour Étudiantes İnci de Kastamonu (kastamonuinciyurt.com), à la fois dans le réseau physique du bâtiment (UniFi Wi-Fi 6, 5 VLAN, horodatage 5651) et dans la couche cloud et intelligence artificielle, avec tous les détails techniques.

Quels sont les concepts fondamentaux à connaître en architecture réseau ?

Lors de la conception du réseau d'un bureau à domicile ou de l'infrastructure d'un foyer étudiant de 150 personnes réparties sur plusieurs étages, la majorité des problèmes rencontrés se résume à une plainte du type « Internet est lent » ; or les mécanismes qui opèrent en arrière-plan sont bien plus spécifiques. Avant de passer aux étapes d'optimisation, il faut clarifier les cinq concepts fondamentaux suivants pour comprendre pourquoi nos interventions fonctionnent :

1. L'équilibre MTU et MSS : pourquoi la taille des paquets fait-elle tomber la connexion ?

La taille maximale de données qu'une trame Ethernet standard peut transporter (MTU - Unité Maximale de Transmission) est de 1500 octets. Cependant, sur la quasi-totalité des infrastructures FTTH (fibre jusqu'au domicile) GPON en Turquie, la connexion est établie via PPPoE (protocole point à point sur Ethernet). PPPoE ajoute à chaque paquet un en-tête supplémentaire de 8 octets. Dans ce cas, la taille maximale réelle de paquet pouvant traverser votre ligne sans fragmentation descend à 1500 - 8 = 1492 octets.

Pour les connexions TCP, si l'on retire de ces 1492 octets l'en-tête IPv4 de 20 octets et l'en-tête TCP de 20 octets (soit 40 octets au total), la charge utile maximale transportable en une seule fois, c'est-à-dire le MSS (taille maximale de segment), est de 1452 octets :

Couche / Protocole	Coût de l'en-tête	Taille maximale restante	Explication
Ethernet standard	0 octet (base)	MTU de `1500` octets	Limite de trame par défaut du réseau local (LAN)
PPPoE (fibre VLAN 35)	8 octets	MTU de `1492` octets	Limite supérieure passant sans fragmentation sur le backbone du FAI
Charge TCP/IPv4 (MSS)	40 octets (20 IP + 20 TCP)	MSS de `1452` octets	Données applicatives nettes transportées dans un seul paquet
Charge ping ICMP (`-D`)	28 octets (20 IP + 8 ICMP)	Charge de `1464` octets	Plus grande donnée ping pouvant passer sans fragmentation (`DF`)

Si le blocage MSS (MSS Clamping) est mal configuré sur votre routeur, deux problèmes opposés apparaissent : si la valeur reste trop élevée, un « trou noir PMTU » (Path MTU Blackhole) se crée ; les pages web se chargent à moitié, les sessions SSH se figent lors de la production de sorties volumineuses. Si la valeur est déduite deux fois par erreur, on obtient une perte de capacité inutile sur chaque paquet et une charge processeur supplémentaire.

2. L'inflation de tampon (Bufferbloat) et la gestion intelligente des files d'attente (SQM)

Lorsque votre ligne Internet est libre, le ping vers l'adresse 1.1.1.1 peut afficher 18 ms. Mais si, sur le même réseau, un appareil télécharge un gros fichier ou effectue une sauvegarde vers le cloud et que cette latence grimpe soudainement à 250-400 ms, cela signifie que vous subissez une inflation de tampon (bufferbloat).

Les tampons de paquets profonds mais non gérés (files d'attente FIFO) du terminal optique (ONT) ou des modems côté FAI mettent les paquets en file d'attente lorsque la ligne atteint la saturation. Les paquets urgents de quelques octets, comme ceux d'un appel vidéo, d'une communication vocale ou d'une requête DNS, doivent attendre derrière les énormes paquets de téléchargement qui les précèdent. La solution consiste à plafonner le débit de la ligne juste avant qu'il ne remplisse le tampon du FAI (au niveau de 92 % à 95 %) sur votre propre pare-feu et à répartir chaque flux dans une file d'attente virtuelle distincte grâce à l'algorithme RFC 8290 FQ_CoDel (mise en file équitable et délai contrôlé).

3. Confidentialité DNS (DoT / DoH) et résolution sans contournement (Zero-Bypass)

Même si vous installez sur votre réseau une couche de filtrage DNS qui bloque les noms de domaine publicitaires, malveillants et d'hameçonnage (phishing), les systèmes d'exploitation et navigateurs modernes peuvent facilement la contourner :

DNS codé en dur : certains appareils IoT, boîtiers de télévision et applications ignorent l'adresse DNS locale fournie par DHCP et envoient directement leurs requêtes à 8.8.8.8:53.
DNS externe chiffré (DoT et DoH) : le « DNS privé » des appareils Android (DNS-over-TLS sur TCP/UDP 853) ou le « DNS sécurisé » des navigateurs (DNS-over-HTTPS sur TCP/UDP 443) désactivent complètement votre serveur DNS local.

Pour une véritable sécurité réseau, tout le trafic sortant du réseau local sur le port 53 doit être redirigé de manière transparente vers le serveur DNS local au niveau du pare-feu (NAT Redirect), le port DoT 853 doit être rejeté (Reject - ainsi l'appareil bascule immédiatement vers le DNS standard) et, pour fermer les tunnels DoH des navigateurs, le domaine canari use-application-dns.net doit être répondu en NXDOMAIN, conjointement avec les listes de serveurs DoH connus.

4. Segmentation VLAN et contrôle des tempêtes de diffusion (Broadcast Storm)

Dans un réseau multi-utilisateurs, faire fonctionner les ordinateurs d'administration, les téléphones du personnel, des centaines d'appareils d'élèves, les invités et les caméras de sécurité sur le même réseau plat (flat network) 192.168.1.0/24 constitue une grave faiblesse de sécurité. Un appareil du même sous-réseau peut écouter le trafic par empoisonnement ARP (ARP Spoofing) ou accéder à l'interface d'administration des caméras de sécurité.

Grâce au marquage IEEE 802.1Q VLAN, des réseaux virtuels totalement isolés les uns des autres sont mis en place sur un seul câble physique et un seul commutateur (switch). De plus, lorsque le réseau compte des appareils multimédias dont les interfaces filaire et sans fil sont actives simultanément (par exemple des enceintes Sonos ou des ponts sans fil), si les priorités RSTP (protocole d'arbre couvrant rapide) ne sont pas correctement configurées sur le commutateur, une boucle de paquets (broadcast storm) verrouillant tout le réseau en quelques secondes se produit.

Quelles mesures de sécurité prenons-nous lors du partage de configurations réseau ?

Notre règle fondamentale est de ne pas compromettre la sécurité opérationnelle (OPSEC) tout en décrivant clairement une architecture technique. Nous appliquons ces limites de sécurité aussi bien dans nos propres systèmes que dans cet article :

Masquage des identités d'infrastructure : les véritables adresses IP externes (WAN), les adresses de passerelle BRAS du FAI, les identifiants d'abonné PPPoE, les adresses MAC des appareils, les identifiants uniques des bases de données cloud (UUID) et les noms de domaine d'administration internes ne sont jamais partagés en clair ; dans les exemples, on utilise les blocs de documentation RFC 5737 (203.0.113.0/24, 198.51.100.0/24) et les blocs d'adresses privées RFC 1918 (192.168.1.0/24, 10.10.0.0/16).
Principe de zéro port ouvert sur le réseau externe (WAN) : sur l'interface WAN de nos pare-feu, aucun port entrant n'est ouvert, y compris pour la connexion à distance, l'interface d'administration web, la surveillance des caméras ou les services de base de données. L'administration à distance se fait uniquement via des tunnels Cloudflare Zero Trust sortants (outbound-only) prenant en charge la cryptographie post-quantique (X25519MLKEM768) et via WireGuard, avec obligation d'authentification multifacteur (OTP/TOTP).
Isolation totale des caméras de sécurité (CCTV) vis-à-vis d'Internet : les caméras IP et les enregistreurs NVR fonctionnent dans leurs propres réseaux VLAN privés ; leur accès à l'internet externe est entièrement bloqué par le pare-feu. Ainsi, l'exploitation depuis l'extérieur d'une éventuelle faille zero-day dans les logiciels des caméras ou l'intégration des appareils à un réseau botnet devient impossible.

1. Optimisation réseau de la station de travail Linux locale avec Antigravity et le conseil

Le premier maillon de l'optimisation de bout en bout a consisté à régler la pile réseau du noyau et la stabilité de la connexion sans fil de la station de travail Omarchy (Arch Linux) sur laquelle nous travaillons. Avec les agents jcode et claude-architect du conseil, nous avons mis en place les améliorations permanentes suivantes dans les couches /etc/sysctl.d/ et /etc/NetworkManager/ :

Contrôle de congestion TCP BBR et tampons de socket de 16 MiB

L'algorithme cubic par défaut du noyau Linux réduit brutalement la fenêtre d'envoi dès qu'il détecte une seule perte de paquet, même sur la ligne. À la place, nous avons rendu permanents l'algorithme BBR développé par Google, qui modélise la bande passante réelle et le temps aller-retour (RTT) de la ligne, ainsi que l'ordonnanceur de paquets FQ (Fair Queueing), au moyen des fichiers /etc/sysctl.d/99-network-bbr.conf et 99-omarchy-sysctl.conf :

# /etc/sysctl.d/99-network-bbr.conf
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.core.wmem_max = 16777216
net.core.rmem_max = 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216

# PPPoE ve tünel hatlarında PMTU kara deliklerini önleyen RFC 4821 keşfi
net.ipv4.tcp_mtu_probing = 1

Désactiver les délais d'économie d'énergie sans fil et le bruit de multidiffusion

Sur les puces Wi-Fi 6E et Wi-Fi 7 modernes (notamment la série Intel BE200/BE211), le mode d'économie d'énergie par défaut de NetworkManager met la couche radio en veille lorsque la connexion est inactive. Cela provoque des pics soudains de latence (jitter) lors de l'envoi de paquets, entre 20 ms et 300 ms. De plus, les protocoles LLMNR et mDNS de systemd-resolved génèrent à la fois un trafic de multidiffusion (multicast) inutile sur le réseau local et ouvrent la porte aux attaques d'empoisonnement de noms sur le réseau local. Nous avons éliminé les deux problèmes à la racine :

# /etc/NetworkManager/conf.d/omarchy-wifi-powersave.conf
[connection]
wifi.powersave = 2

# /etc/systemd/resolved.conf.d/10-disable-multicast.conf
[Resolve]
LLMNR=no
MulticastDNS=no

En outre, nous avons durci l'outil omarchy-netradar, que nous avons développé pour surveiller les appareils et les latences du réseau local, selon les normes de sécurité HANCORE : l'outil ne peut scanner que les blocs de réseaux privés (RFC 1918, RFC 3927 et loopback), isole tous ses sous-processus dans des groupes de processus distincts (process_group(0)) et empêche l'injection d'arguments en utilisant le terminateur d'option -- lors des appels de commandes externes.

2. Optimisation du noyau, de SQM et du DNS sur OPNsense (FreeBSD 15.1)

Au cœur du réseau se trouve OPNsense 26.7.7 (FreeBSD 15.1), exécuté sur un processeur Intel N150 à 4 cœurs, 8 Go de RAM et un SSD NVMe. Lorsque nous avons examiné ligne par ligne la sauvegarde de configuration existante avec les agents gemini-cli et research à contexte 1M+ du concept, nous avons identifié des goulots d'étranglement critiques négligés dans les installations standard et les avons résolus un par un.

Perte de capacité cachée : correction de l'erreur de double réduction MSS

Lorsque nous avons exécuté des tests de validation avec le drapeau DF (Ne pas fragmenter) sur notre ligne Türk Telekom FTTH GPON (VLAN 35 / PPPoE), nous avons confirmé que la ligne prend en charge un MTU de exactement 1492 octets :

# 1464 bayt yük + 20 bayt IP + 8 bayt ICMP = 1492 bayt (%0 kayıp)
ping -D -s 1464 1.1.1.1

# 1465 bayt yük = 1493 bayt -> "frag needed and DF set (MTU 1492)"
ping -D -s 1465 1.1.1.1

Cependant, il existe une nuance assez courante mais importante dans la configuration de l'interface OPNsense : lorsque vous saisissez directement 1452 dans le champ <mss> de l'interface WAN, OPNsense soustrait une seconde fois les 40 octets d'en-tête TCP/IP en arrière-plan et génère dans le pare-feu pf la règle scrub on pppoe1 inet all max-mss 1412. Cela signifie que 40 octets sont perdus inutilement dans chaque paquet TCP. Lorsque nous avons corrigé la valeur de l'interface WAN en <mss>1492</mss>, OPNsense a lui-même déduit 40 octets et a produit sur pf la valeur max-mss 1452, qui est exactement celle attendue.

Isolation des interruptions matérielles (IRQ) et réglages du noyau FreeBSD

Sur un processeur Intel N150 à 4 cœurs, afin que les paquets réseau, les opérations de chiffrement et les services en espace utilisateur ne s'attendent pas mutuellement sur le même cœur, nous avons mis en place un partage des tâches du noyau (CPU Pinning) via un hook de démarrage :

Cœur du processeur	Tâche et interruption (IRQ) assignées	Justification architecturale
`CPU 0`	`NetISR` (`hybrid`, `QLimit=4096`) + `Dummynet FQ_CoDel`	Fonctionnement ininterrompu du routage des paquets et de l'ordonnancement intelligent des files d'attente
`CPU 1`	`re0` (interruption Ethernet Gigabit LAN)	Éviter que le trafic du réseau local n'entre en collision avec les interruptions WAN
`CPU 2`	`re1` (interruption WAN GPON `VLAN 35` / `PPPoE`)	Isoler la charge d'encapsulation PPPoE sur un seul cœur
`CPU 3`	Espace utilisateur (`unbound`, `cloudflared`, `crowdsec`, `dnsmasq`)	Éviter que le filtrage DNS et le chiffrement du tunnel ne retardent la transmission des paquets

Sur les interfaces Ethernet physiques, nous avons désactivé le TSO/LRO matériel et le filtrage VLAN (-vlanhwtso -tso -lro) qui entraient en conflit avec les files d'attente logicielles ; en conséquence, nous avons atteint dans les statistiques des interfaces les valeurs Ierrs=0, Oerrs=0, Idrop=0, Coll=0 (zéro erreur de paquet et zéro rejet de file d'attente). De plus, sur le système disposant de 8 Go de RAM, afin d'éviter que le système de fichiers ZFS n'absorbe toute la mémoire, nous avons activé la limite vfs.zfs.arc.max = 2147483648 (2 Go) et la gestion matérielle de fréquence Intel Speed Shift (dev.hwpstate_intel.{0..3}.epp = 20).

Tuyaux Dummynet FQ_CoDel et résultat Waveform Bufferbloat A+

Afin d'annuler la bufferbloat sur la ligne fibre asymétrique 1000 Mbps / 50 Mbps, nous avons défini dans OPNsense Traffic Shaper (Dummynet) deux tuyaux FQ_CoDel entièrement conformes à la norme RFC 8290 :

Tuyau descendant (WAN_Down_930M_FQCoDel) : bande passante 930 Mbit/s, target = 5 ms, interval = 100 ms, quantum = 1492 correspondant exactement à la taille des paquets PPPoE, limit = 4096, flows = 4096 et ECN = activé.
Tuyau montant (WAN_Up_46M_FQCoDel) : bande passante 46 Mbit/s, target = 5 ms, interval = 100 ms, standard de faible quantum RFC 8290 (quantum = 300) donnant la priorité aux petits paquets ACK/DNS sur les lignes inférieures à 100 Mbps, limit = 1024, flows = 1024 et NoECN.

Les mesures de performance en direct réalisées après l'optimisation ont donné les résultats suivants :

Point de mesure / Scénario	Minimum	Moyenne	Maximum	Écart (gigue)	Perte de paquets
Premier saut FAI (BRAS - au repos)	`1.24 ms`	`1.64 ms`	`2.00 ms`	`0.27 ms`	`0.0 %`
DNS du backbone Türk Telekom (`dpinger`)	`4.25 ms`	`5.31 ms`	`6.00 ms`	`0.52 ms`	`0.0 %`
Cloudflare Anycast (`1.1.1.1`)	`18.06 ms`	`18.57 ms`	`19.00 ms`	`0.31 ms`	`0.0 %`
Google Anycast (`8.8.8.8`)	`25.14 ms`	`25.94 ms`	`27.01 ms`	`0.62 ms`	`0.0 %`
Téléchargement à pleine charge (8 flux parallèles)	—	`8.67 ms` (`+7.04 ms`)	—	—	Classe A+
Envoi à pleine charge (6 flux parallèles)	—	`3.21 ms` (`-0.56 ms`)	—	—	Classe A+

Unbound DNS (1.26.1) : 1,1 Go de mémoire économisés et une architecture sans latence

La configuration Unbound existante présentait deux problèmes critiques : premièrement, comme le Query Forwarding en clair et le DNS-over-TLS (DoT) étaient tous deux activés en même temps, plus de 3 000 requêtes tombaient en expiration (queries_discard_timeout). Deuxièmement, 11 listes noires différentes qui se chevauchaient (2,89 millions de noms de domaine) faisaient consommer à Unbound à lui seul 2,37 Go de RAM.

Uniquement DoT en TLS 1.3 : nous avons désactivé le transfert en clair ; nous n'avons conservé que les points de terminaison DoT cloudflare-dns.com (1.1.1.1:853, 1.0.0.1:853) et dns.google (8.8.8.8:853, 8.8.4.4:853).
DNSBL ciblées et 1,1 Go de RAM gagnés : nous avons supprimé les listes redondantes et activé HaGeZi Multi PRO Wildcard, Threat Intelligence Feeds, Abuse.ch ThreatFox et la liste de blocage DoH pur comptant 3 283 serveurs (doh.txt). Nous avons remplacé le mode de réponse 0.0.0.0 par NXDOMAIN (nxdomain = 1) ; ainsi, les applications clientes reçoivent une réponse immédiate sans attendre l'expiration de la connexion. Le nombre total de noms de domaine uniques a été fixé à 1 709 008 et la consommation mémoire d'Unbound est passée de 2,37 Go à 1,28 Go (15,8 %).
Domaine canari et exemption Apple iCloud : pour fermer les tunnels DoH cachés des navigateurs, nous avons ajouté le domaine canari use-application-dns.net à la liste noire, et pour ne pas perturber le service iCloud Private Relay sur les appareils Apple, nous avons ajouté mask.icloud.com, mask-h2.icloud.com et mask-api.icloud.com à la liste blanche.
Redirection forcée sur PF : dans le pare-feu, nous avons écrit une règle NAT rdr qui redirige de manière transparente tous les paquets TCP/UDP 53 sortant du LAN vers 127.0.0.1:53, ainsi qu'une règle de filtrage qui rejette les paquets TCP/UDP 853 (DoT) externes en 3,5 ms par Reject (TCP RST / ICMP Unreachable).

Pourquoi avons-nous choisi CrowdSec et Cloudflare Zero Trust plutôt que Suricata et Zenarmor ?

Un piège dans lequel tombent souvent les utilisateurs d'OPNsense est d'installer en même temps Suricata (IPS) et Zenarmor (os-sensei) sur des pare-feu à faible consommation. Dans notre analyse du conseil, nous avons démontré avec des données concrètes pourquoi ces deux paquets ne doivent pas être utilisés sur ce matériel :

Les deux moteurs tentent d'accrocher le framework noyau netmap de FreeBSD sur la même interface ; cela provoque des conflits d'interruption et des pertes de paquets.
Aujourd'hui, où le trafic HTTPS/QUIC chiffré dépasse 95 %, tenter d'inspecter le corps des paquets sans déchiffrement TLS (SSL Inspection) n'apporte qu'une très faible visibilité supplémentaire en échange d'un coût processeur élevé ; de plus, les services de base de données de Zenarmor consomment à eux seuls 2 à 4 Go de RAM.

À la place, nous avons mis en place un duo bien plus efficace qui ne perturbe jamais le chemin des paquets du noyau (netmap) :

os-crowdsec (IPS comportemental et renseignement sur les menaces) : il analyse dans l'espace utilisateur les journaux du pare-feu et des services, puis écrit directement les IP des attaquants dans la table pf (crowdsec_blocklists, limite de table de 1 000 000) ; il n'ajoute aucune latence au chemin des paquets.
os-cloudflared (tunnel Zero Trust post-quantique) : sans ouvrir un seul port sur le WAN, il place l'interface d'administration derrière Cloudflare Zero Trust Access (uniquement e-mail autorisé et code de vérification à usage unique) grâce au protocole QUIC et à l'échange de clés hybride post-quantique X25519MLKEM768.

3. Nouvelle organisation pour le foyer Kastamonu İnci (`kastamonuinciyurt.com`)

Nous avons appliqué cette approche de l'architecture réseau et de sécurité à l'échelle institutionnelle dans le projet Kastamonu Özel İnci Yükseköğrenim Kız Öğrenci Yurdu, à la fois à la couche réseau physique du bâtiment et réglementation et à la couche site web. S'agissant d'un réseau institutionnel, je ne donne pas dans cette partie de détails tels que le plan d'adressage, les numéros de porte ou l'emplacement des équipements.

Réseau physique du bâtiment : 16 points d'accès UniFi Wi-Fi 6 et architecture en îlot central

Le bâtiment du foyer comprend quatre étages, entre 100 et 150 étudiants et 15 membres du personnel. En examinant les plans des étages, nous avons constaté qu'au centre des étages intermédiaires se trouve un « îlot central » (chambres intérieures et salles d'étude) entouré de couloirs. L'approche classique consistant à « placer un point d'accès à chaque extrémité du couloir » entraînait une atténuation totale du signal 5 GHz dans les murs intérieurs en béton armé.

Pour résoudre ce problème, nous avons positionné au total 16 points d'accès UniFi Wi-Fi 6 selon un plan de couverture cellulaire :

Les 6 UniFi U6-Lite existants ont été conservés ; y ont été ajoutés 8 nouveaux UniFi U6+ ainsi que 2 UniFi U6-Pro à haute capacité pour les espaces communs où les étudiants établissent des connexions intensives simultanées.
Tout le câblage a été ramené au coffret central avec des câbles Cat6 LSZH (Low Smoke Zero Halogen) 100 % cuivre sans fumée et sans halogène, conformément à la réglementation incendie des foyers d'étudiants.

Segmentation zero trust avec 5 VLAN distincts et conformité à la réglementation 5651

Nous avons totalement isolé les uns des autres tous les flux internes du bâtiment sur OPNsense et le commutateur PoE administrable au moyen de 5 VLAN distincts :

Réseau du personnel : les appareils du personnel reçoivent une adresse fixe associée à leur identité ; les enregistrements 5651 sont conservés avant la sortie du Captive Portal.
Réseau des étudiants : Captive Portal avec authentification par T.C. Kimlik (NVİ) et FreeRADIUS, limitation de débit équitable par étudiant et blocage de l'accès aux autres réseaux.
Réseau invité : réseau visiteurs soumis à une limitation de débit et totalement isolé du réseau interne.
Caméras de sécurité : les caméras IP et l'enregistreur sont sur un réseau distinct ; la sortie vers l'internet des caméras est totalement fermée, les enregistrements sont conservés pendant la durée conforme aux normes GSB et protégés par une alimentation sans interruption.
Médias et IoT : les décodeurs de télévision et les systèmes audio des espaces communs ; la priorité RSTP a été réglée sur le commutateur contre les boucles de diffusion.

Consolidation sur un seul équipement : architecture OPNsense ZFS RAID-1 Mirror

Faire fonctionner au foyer un pare-feu distinct, un UniFi Cloud Key distinct, un serveur de logs 5651 distinct et un équipement VPN distinct augmentait à la fois les points de défaillance et la consommation d'énergie. Sans intercaler de couche de machine virtuelle (TrueNAS/Proxmox), nous avons réuni 6 tâches critiques sur un seul équipement OPNsense fonctionnant directement sur un Mini PC sans ventilateur à double SSD NVMe (ZFS RAID-1 Mirror) :

Routeur central, pare-feu et régulateur de trafic FQ_CoDel.
Contrôleur UniFi intégré (os-unifi-maxit) : gère les 16 points d'accès Wi-Fi 6 et les commutateurs PoE sans équipement supplémentaire.
Captive Portal étudiant 5651 et moteur d'authentification os-freeradius.
Horodateur automatique TÜBİTAK Kamu SM : chaque nuit, il scelle les enregistrements d'attribution d'IP, de MAC et de NAT du jour avec un horodatage cryptographique conformément à la loi n° 5651 et les conserve pendant 2 ans sur un stockage en miroir ZFS RAID-1 à double disque (aucune perte de données même si l'un des disques tombe en panne).
Tunnel Cloudflare Zero Trust (cloudflared) : accès sécurisé aux panneaux de gestion du foyer sans ouvrir de port vers l'extérieur.
VPN WireGuard (os-wireguard) : accès distant sécurisé des administrateurs autorisés.

Site web

kastamonuinciyurt.com a été retiré de sa structure statique et déplacé vers une application edge fonctionnant sur Cloudflare Workers. Le portail de gestion, l'assistant IA multilingue et les journaux de découverte d'agents décrits dans la première version de l'article ont été supprimés en octobre 2026 ; le site se compose aujourd'hui de pages présentant le foyer, de réponses préparées aux questions fréquentes et des derniers posts Instagram.

Mon analyse

Ce qui est certain : il n'est pas toujours nécessaire d'acheter du matériel plus cher ou des forfaits à plus haut débit pour améliorer les performances et la sécurité du réseau. Corriger une erreur MSS de 40 octets comptée deux fois sur une ligne PPPoE, nettoyer les listes noires en conflit dans Unbound DNS et passer en mode NXDOMAIN, et couper la bufferbloat avec FQ_CoDel font passer le réseau à un tout autre niveau sur le même matériel.
Ce qui fait le plus de différence en pratique : dans les bâtiments institutionnels (en particulier les foyers d'étudiants à plusieurs étages), le placement des points d'accès sans lecture de l'architecture physique et les installations en réseau plat (flat network) sont la principale source de problèmes. Placer les caméras sur un réseau distinct et couper leur accès à l'internet, séparer les réseaux étudiants et personnel, et regrouper tout le système dans un seul boîtier OPNsense en miroir ZFS RAID-1 a considérablement augmenté à la fois la sécurité et la facilité de maintenance.
En résumé : que vous administriez votre station de travail Linux personnelle et votre pare-feu domestique ou que vous montiez le réseau d'une institution de 150 personnes ; lorsque une gestion correcte des files d'attente au niveau du noyau (BBR + FQ_CoDel), un DNS sans latence, le principe de zéro port ouvert sur le réseau externe et le contrôle en couches d'un conseil multi-modèles se rejoignent, on obtient à la fois une haute vitesse et une sécurité de niveau institutionnel.