Un mot de Zima
Merci, Active_Learner05, d’avoir considéré ZimaBoard 2 comme une plateforme d’apprentissage plutôt que comme un boîtier limité à un seul rôle. Transformer un ZimaBoard 2 1664 en pare-feu OPNsense, puis travailler sur le stockage, l’ordre de démarrage, l’attribution des interfaces, la conversion en point d’accès et les plugins de sécurité, illustre parfaitement le type d’exploration pratique qui rend un homelab réellement utile.
Nous apprécions tout particulièrement que vous ayez partagé le processus alors qu’il était encore en cours. L’intérêt ne réside pas uniquement dans le fait que le pare-feu soit devenu opérationnel, mais aussi dans la possibilité offerte aux autres utilisateurs de comprendre les décisions prises : pourquoi OPNsense est devenu le système d’exploitation principal, comment le réseau a été connecté, quels services de sécurité ont été activés, ce qui n’a pas fonctionné pendant la configuration et ce que vous avez appris en résolvant vous-même ces problèmes.
— Zima
Découvrez Active_Learner05
Active_Learner05 se décrit comme un touche-à-tout, avec une expérience dans les arts, le développement de jeux, les missions spatiales, la radioamateur et la programmation. Même après s’être éloigné du monde du travail conventionnel pour des raisons de santé, il continue à créer en écrivant, en publiant des livres, en vendant des produits numériques et en explorant de nouveaux projets techniques.
C’est cette curiosité qui l’a conduit à intégrer deux systèmes ZimaBoard 2 1664 à son installation. L’un est devenu un appareil de sécurité réseau domestique dédié, basé sur OPNsense. Le second a pris une direction complètement différente avec un eGPU et une ancienne RTX 4060 Ti pour Ollama, Plex, IT Tools et d’autres expérimentations. Pour cette histoire, nous nous concentrons sur la première carte : comment il l’a transformée en pare-feu et routeur au cœur de son réseau domestique.
Vous pouvez suivre Active_Learner05 sur Reddit pour voir le projet se poursuivre au-delà de cette page.
Pourquoi ZimaBoard 2 est devenue la plateforme du pare-feu
Le choix s’est d’abord fondé sur les caractéristiques de la ZimaBoard 2 1664 plutôt que sur une application unique préalablement définie. Active_Learner05 recherchait un matériel lui permettant de mettre en pratique ses connaissances tout en continuant à apprendre dans les domaines des réseaux, de la sécurité domestique, de la programmation, de la productivité et d’autres services auto-hébergés.
Pour le projet de pare-feu, cela signifiait utiliser la carte comme hôte OPNsense dédié au lieu de conserver ZimaOS comme système d’exploitation principal. Sa configuration publiée comprend un processeur Intel N150, 16 Go de mémoire, un SSD Crucial de 500 Go et une pile OPNsense incluant Suricata, Unbound, Zenarmor et CrowdSec.
Installer OPNsense sur un SSD SATA
Le premier démarrage s’est déroulé sans difficulté particulière. Active_Learner05 décrit la carte comme facile à démarrer et presque prête à l’emploi, mais l’installation d’OPNsense a constitué la première véritable étape d’apprentissage.
Il souhaitait exécuter OPNsense depuis un SSD SATA plutôt que de continuer à utiliser le système d’usine installé sur l’eMMC interne. Il a donc fallu modifier la configuration de démarrage afin que le SSD externe devienne le disque privilégié pour le système d’exploitation. Dans son journal de construction publié sur Reddit, il explique avoir installé l’environnement de récupération d’usine de ZimaBoard pour conserver une solution d’accès de secours, créé un support d’installation OPNsense, puis installé OPNsense depuis une clé USB sur le SSD.
Après l’installation, son ordre de démarrage préféré est devenu :
1. SSD
2. Environnement de récupération CasaOS
Cela correspond également à la documentation de récupération de ZimaSpace, qui indique que les systèmes installés sur un disque externe peuvent nécessiter une modification de la séquence de démarrage du BIOS ou du périphérique de démarrage. Le guide de récupération d’usine de ZimaBoard présente la procédure officielle, tandis que le guide d’installation d’OPNsense couvre l’installation proprement dite du pare-feu.
Attribuer les interfaces WAN, LAN et supplémentaires
Une fois OPNsense installé, l’étape suivante a consisté à transformer les ports Ethernet en une véritable architecture de routage, plutôt qu’à simplement brancher des câbles en espérant que les paramètres par défaut correspondent à la topologie souhaitée.
Active_Learner05 a documenté l’attribution initiale des interfaces WAN et LAN, puis ajouté les interfaces restantes et configuré des ports supplémentaires en OPT1 et OPT2. Le pare-feu pouvait ainsi séparer les rôles au lieu de traiter chaque port comme une partie d’un seul réseau plat.
Les éléments en amont et en aval ont été volontairement simples. Un routeur gaming ASUS a été converti en point d’accès sans nécessiter de réinitialisation d’usine, tandis qu’un switch D-Link DMS-105 2,5 GbE prêt à l’emploi assurait la distribution filaire. ZimaBoard 2 se trouvait entre ces composants et prenait en charge le routage, les règles du pare-feu, le DNS et les services de sécurité réseau.
Construire la pile de sécurité autour d’OPNsense
Faire circuler les paquets du WAN vers le LAN n’était que le début. La partie la plus intéressante du projet était la pile de sécurité qu’Active_Learner05 a ajoutée à OPNsense.
Unbound assurait la résolution DNS. Suricata ajoutait des fonctions de détection et d’inspection des intrusions. Zenarmor fournissait une visibilité et des rapports sur le trafic en fonction des applications. CrowdSec ajoutait une couche supplémentaire pour identifier les comportements malveillants et y répondre.
Cette combinaison a fait de ZimaBoard 2 bien plus qu’un simple remplacement du routeur du fournisseur d’accès. Elle est devenue une machine qu’il pouvait inspecter activement : les services pouvaient être vérifiés, l’utilisation des ressources surveillée et le comportement du réseau exploré, au lieu d’être dissimulé derrière une interface simplifiée de routeur grand public.
Ce que la première configuration lui a appris
Le projet n’a pas été totalement fluide, et c’est aussi ce qui rend cette histoire utile. L’une des difficultés a consisté à abandonner le chemin de démarrage eMMC par défaut afin qu’OPNsense puisse fonctionner sur le SSD SATA. Un autre problème est apparu lors d’une expérimentation PCIe distincte : un câble d’extension utilisé avec une carte OCuLink ne fonctionnait pas comme prévu, ce qui l’a conduit à conclure que la longueur du câble ou sa compatibilité empêchait un transfert de données fiable.
Sur le pare-feu lui-même, il a ensuite indiqué que l’utilisation de la mémoire passait d’environ 40 % à plus de 80 % selon l’activité, tandis que l’utilisation du processeur atteignait environ 50 % au maximum d’après ses observations de l’époque. Il a également constaté que la carte chauffait davantage sous la charge de sécurité et a ajouté un ancien ventilateur AC Infinity de 80 mm à température contrôlée, qui a selon lui amélioré les températures.
Ces détails sont importants, car ils transforment cette page, qui aurait pu se limiter à résumer une installation réussie, en une véritable histoire de homelab : le système fonctionnait, mais le processus impliquait toujours de comprendre les interactions entre les périphériques de démarrage, l’attribution des interfaces, les plugins, les températures et le matériel d’extension.
Du routeur grand public à un réseau que l’on peut inspecter
Le changement pratique au quotidien ne consistait pas simplement à remplacer un routeur par un autre. OPNsense a donné à Active_Learner05 un réseau qu’il pouvait analyser.
Le point d’accès pouvait se concentrer sur le Wi-Fi. Le switch 2,5 GbE pouvait se concentrer sur la distribution. ZimaBoard 2 pouvait se concentrer sur le routage et la sécurité. Dans OPNsense, le DNS, les services du pare-feu, l’inspection du trafic, la détection des intrusions et CrowdSec pouvaient être surveillés indépendamment au lieu d’être regroupés dans un appareil opaque.
Cette séparation correspondait également à la raison initiale pour laquelle il avait acheté ce matériel : utiliser ses caractéristiques pour mettre en pratique ses connaissances et continuer à apprendre. Le pare-feu n’était pas la fin de l’expérience. Il représentait l’un des exemples les plus clairs de la manière dont une carte x86 polyvalente pouvait devenir un appareil réseau spécialisé.
Deux systèmes ZimaBoard 2, deux directions différentes
Le système OPNsense n’est qu’un aspect de la configuration d’Active_Learner05. Son second ZimaBoard 2 1664 a pris la direction opposée, en associant la carte à un GPU externe et à une RTX 4060 Ti pour Ollama, Plex avec accélération GPU, IT Tools et d’autres expérimentations.
Ce contraste aide à comprendre son approche de ZimaBoard 2. Il n’a pas acheté deux machines identiques pour exécuter deux charges de travail identiques. L’une est devenue une infrastructure réseau ; l’autre, une plateforme dédiée aux expérimentations avec le GPU, les médias et l’IA. Le fil conducteur reste l’exploration.
L’histoire continue de s’écrire
L’histoire d’Active_Learner05 et de Zima continue de s’écrire. Il explique qu’il débute encore avec les ordinateurs monocartes et qu’il explore toujours les possibilités du matériel. Ce pare-feu OPNsense est donc moins un aboutissement définitif qu’un premier projet réseau sérieux construit autour de la carte.
Son conseil en une phrase aux futurs utilisateurs est simple : « Essayez et explorez. » Pour consulter la discussion complète sur ce pare-feu encore en cours de développement, rendez-vous sur la publication originale du projet OPNsense ZimaBoard 2 sur Reddit. Vous pouvez également suivre Active_Learner05 sur Reddit au fil de l’avancement du projet.
