Comment cachito labs construit un pare-feu OPNsense sur ZimaBoard 2

Merci à cachito labs d’avoir documenté ce projet ZimaBoard 2 particulièrement réfléchi. Dans sa vidéo originale de présentation, un problème avec le FAI devient une leçon pratique sur le routage, les règles du pare-feu, la confidentialité DNS et la sortie VPN. L’idée intéressante n’est pas simplement de copier une configuration, mais de comprendre comment un petit ordinateur dédié peut devenir le point de contrôle de tout un réseau domestique.

Cette présentation est particulièrement utile si la passerelle de votre FAI vous offre peu de contrôle sur le routage ou la confidentialité. Elle décrit le passage d’une connexion gérée par le fournisseur à un ZimaBoard 2 exécutant OPNsense, puis montre comment les règles du pare-feu, les choix DNS et le routage VPN modifient le comportement du réseau. Les sections ci-dessous transforment cette configuration en guide de décision réutilisable plutôt qu’en transcription minute par minute.

Transparence concernant la collaboration : La description de la vidéo originale contient une mention d’affiliation pour des produits ou services susceptibles d’être cités dans la configuration. L’article ci-dessous résume la configuration et l’usage prévus par cachito labs ; les versions logicielles, les détails de l’interface, les ensembles matériels et la compatibilité peuvent changer après sa publication.

Le résultat : ZimaBoard 2 Mini Home Server  n’est pas un remplacement miniature d’un serveur en rack doté de nombreux cœurs. Sa force réside dans l’association d’un fonctionnement silencieux, de deux interfaces réseau 2,5 GbE, d’un stockage SATA direct et d’une extension PCIe ouverte, le tout dans un petit système x86 auquel on peut attribuer un rôle bien défini sur le réseau domestique : celui de pare-feu et de routeur OPNsense dédié.

En regardant la vidéo, concentrez-vous sur trois changements liés : le ZimaBoard 2 devient la passerelle réseau, OPNsense sépare les règles du pare-feu et du NAT du comportement DNS, et le VPN crée une identité sortante différente pour certains flux. Ces couches expliquent pourquoi le projet peut réduire la visibilité du FAI sans promettre un anonymat absolu.

Lorsqu’un FAI insiste pour contrôler l’équipement en périphérie du réseau, la véritable perte concerne la visibilité et le choix. Un pare-feu séparé permet de retrouver les deux. Le ZimaBoard 2 se place entre la connexion du fournisseur et le reste du domicile, tandis qu’OPNsense décide quels flux sont autorisés, où ils vont et quels services doivent résoudre les noms ou sortir par un VPN. Cette séparation rend le réseau plus facile à comprendre et à modifier ultérieurement.

Pourquoi un problème avec le FAI est devenu un projet de pare-feu

La configuration commence par une frustration familière dans les réseaux domestiques : le fournisseur ne souhaite pas que le client utilise son propre routeur en périphérie. Au lieu de considérer la passerelle du FAI comme le cerveau du réseau, cachito labs transfère le routage et les règles vers un matériel contrôlé par son propriétaire. Le résultat est une limite claire : le FAI fournit la connectivité, tandis que le pare-feu local gère le réseau privé.

Cette distinction est importante, car une passerelle tout-en-un dissimule plusieurs fonctions derrière une seule interface. Le routage, la traduction d’adresses, le transfert DNS, l’accès sans fil et les règles de sécurité peuvent tous être regroupés. Un pare-feu dédié expose ces fonctions sous forme de décisions distinctes. Vous pouvez remplacer le point d’accès sans remplacer le routeur, faire passer uniquement certains appareils par un VPN ou modifier le comportement DNS sans repenser tout le réseau local.

Pourquoi le ZimaBoard 2 convient au rôle de pare-feu

Un pare-feu n’a pas besoin de ressembler à un ordinateur de bureau. Il lui faut des interfaces réseau fiables, une marge de puissance suffisante pour les services choisis et un format physique adapté à un fonctionnement continu. Le ZimaBoard 2 est une plateforme x86 compacte dotée de deux connexions 2,5 GbE, ce qui en fait naturellement un appareil à deux faces : un port se connecte au FAI ou au modem en amont, tandis que l’autre dessert le commutateur interne.

Le matériel n’est que la base. Un boîtier dédié modifie également le modèle de panne. S’il redémarre ou perd son alimentation, tout le domicile peut perdre sa connexion ; la configuration doit donc prévoir un plan de récupération : conserver une sauvegarde fonctionnelle connue, identifier les deux liaisons Ethernet et s’assurer que l’administration locale reste possible lorsque le WAN est indisponible. Un matériel compact est pratique, mais il mérite tout de même une attention digne d’une infrastructure.

L’architecture réseau doit être correcte avant de penser aux règles

Avant d’écrire une règle de pare-feu, dessinez le chemin qu’un paquet doit suivre. L’interface amont reçoit l’adresse fournie par le fournisseur, l’interface aval gère le sous-réseau privé et chaque client utilise l’adresse du ZimaBoard 2 comme passerelle par défaut. Si ces relations sont incorrectes, même un ensemble de règles impeccable ne réparera pas la topologie.

Cette position de passerelle permet au pare-feu de voir le trafic de chaque appareil géré. Il peut appliquer une politique à tout le foyer ou des politiques plus précises aux VLAN, aux serveurs, aux postes de travail et aux équipements domotiques. La conception rend également le dépannage plus méthodique : testez le WAN, puis la passerelle LAN, puis le DNS, et seulement ensuite recherchez les problèmes au niveau des applications.

Installer OPNsense sur un équipement périphérique dédié

Installer OPNsense sur un petit ordinateur x86 est une manière pratique de transformer un matériel générique en routeur spécialisé. L’image est écrite sur un support amorçable, l’appareil démarre depuis ce support et le programme d’installation place le système d’exploitation sur le stockage interne. Une fois le premier démarrage terminé, la console sert à attribuer les interfaces physiques avant que le tableau de bord web ne prenne le relais.

L’attribution des interfaces est le moment où il faut ralentir. Une étiquette telle que « WAN » ou « LAN » n’est utile que si elle correspond réellement au câble et au port concernés. Vérifiez l’état de la liaison, connectez un côté à la fois et gardez une configuration initiale simple. Vous pourrez ensuite ajouter d’autres réseaux et services sans devoir deviner quelle interface physique les transporte.

Interfaces, passerelles, NAT et première route fonctionnelle

Une fois les interfaces attribuées, OPNsense a besoin d’une passerelle amont et d’une adresse LAN privée. L’adresse LAN devient la route par défaut des clients, tandis que la passerelle WAN pointe vers l’équipement du FAI. La traduction d’adresses permet ensuite aux clients privés de partager la connexion en amont, ce qui constitue le fonctionnement habituel d’un réseau domestique derrière une seule adresse publique.

À ce stade, vérifiez la connectivité de base avant d’ajouter des fonctions de confidentialité. Un client doit recevoir une adresse, accéder au tableau de bord du pare-feu, résoudre un nom de test et atteindre Internet. Tester ces couches séparément évite qu’une modification du VPN ou du DNS ne masque un problème plus simple de câblage, de DHCP ou de passerelle.

Les règles du pare-feu et la confidentialité DNS sont deux couches différentes

Les règles du pare-feu répondent à la question « quels flux sont autorisés ? ». Le NAT répond à la question « comment le trafic privé partage-t-il l’adresse en amont ? ». Les paramètres DNS répondent à la question « quel résolveur gère la recherche de nom ? ». Ces contrôles interagissent, mais ne sont pas interchangeables. Autoriser le trafic sortant ne chiffre pas le DNS, et choisir un résolveur chiffré n’envoie pas automatiquement tout le trafic des applications via un VPN.

Une base raisonnable consiste à autoriser le trafic de retour associé, à n’autoriser en sortie que les services nécessaires au réseau et à maintenir l’administration accessible depuis un segment de gestion de confiance. Le DNS peut ensuite être redirigé vers le résolveur choisi, avec un transport chiffré lorsque cela est pris en charge. L’objectif n’est pas de rendre le réseau mystérieusement « invisible », mais de réduire et de mieux définir le nombre de parties capables d’observer ou d’influencer chaque couche.

Le routage via un VPN modifie l’identité de sortie

La partie VPN du projet modifie le chemin de sortie du réseau. Au lieu d’envoyer certains flux directement au FAI, OPNsense établit un tunnel et y achemine les clients ou les destinations correspondants. Les services externes voient alors l’adresse de sortie du fournisseur VPN plutôt que l’adresse publique habituelle du domicile.

Cela améliore la séparation vis-à-vis du FAI, mais ce n’est pas la même chose qu’un anonymat total. Le FAI peut toujours observer la connexion au service VPN ainsi que les grandes caractéristiques du trafic. Le fournisseur VPN devient un autre acteur de confiance, et les sites web peuvent toujours identifier les utilisateurs au moyen des comptes, des cookies, des navigateurs ou de l’empreinte des appareils. Une bonne politique commence donc par une question précise : quels flux ont besoin d’une sortie différente, et pourquoi ?

Un boîtier imprimé en 3D et un emplacement en rack rendent la configuration pratique

Le boîtier ne sert pas uniquement à la décoration. Il protège la carte, stabilise les liaisons Ethernet et facilite l’installation du pare-feu à proximité du modem et du commutateur. Un emplacement en rack favorise également une séparation claire entre l’équipement périphérique, les points d’accès sans fil, le stockage et les autres serveurs.

Prévoyez suffisamment d’espace pour la circulation de l’air et l’accès lors des interventions, surtout si la carte doit fonctionner en continu. Identifiez l’adaptateur secteur et les deux câbles réseau, et évitez de placer le pare-feu à un endroit où un simple accrochage pourrait déconnecter le WAN. Un appareil réseau compact est réellement réussi lorsqu’il reste compréhensible six mois après sa mise en place.

Ce que cette configuration masque — et ce qu’elle ne masque pas

Installer OPNsense sur un ZimaBoard 2 peut dissimuler au FAI la structure interne du réseau domestique. Le fournisseur n’a plus besoin de gérer chaque client privé individuellement ; vu de l’extérieur, le pare-feu périphérique présente une limite contrôlée. Les choix DNS et le routage VPN peuvent réduire la quantité d’informations sur les destinations exposées par le chemin par défaut.

Ces avantages ont toutefois des limites. Le FAI fournit toujours la liaison physique, peut voir que la connexion est active et peut identifier le point de terminaison VPN ou d’autres métadonnées. Le pare-feu ne peut pas protéger un client compromis, empêcher le suivi effectué par un service auprès duquel vous êtes connecté ni garantir que chaque application respecte le chemin prévu. Considérez ce projet comme un moyen de contrôler et de segmenter le réseau, et non comme une promesse de confidentialité absolue.

À qui s’adresse un pare-feu OPNsense sur ZimaBoard 2 ?

Cette conception convient particulièrement à un foyer techniquement curieux qui souhaite contrôler le routage, le DNS, les règles VPN et la segmentation future sans acheter un équipement professionnel imposant. Elle est également utile dans un laboratoire où plusieurs services ont besoin d’un réseau prévisible et où le propriétaire veut comprendre le chemin suivi par chaque paquet.

Elle convient moins lorsque la priorité est de ne nécessiter absolument aucune maintenance. Une passerelle gérée peut être un meilleur choix pour les personnes qui ne souhaitent pas gérer les mises à jour, les sauvegardes, les certificats, les identifiants VPN et les procédures de récupération. Pour les autres, l’association d’une carte basse consommation et d’une plateforme de pare-feu transparente offre un compromis pratique entre une box de FAI et un serveur en rack complet.

Conclusion

Le projet de cachito labs montre pourquoi un petit ordinateur peut avoir un effet considérable sur un réseau domestique. Le ZimaBoard 2 fournit une plateforme compacte à deux interfaces ; OPNsense fournit le moteur de règles ; et le propriétaire décide de la manière dont le DNS, le NAT, les règles du pare-feu et les routes VPN s’articulent. La leçon la plus durable est architecturale : établissez d’abord une passerelle correcte, testez chaque couche indépendamment, puis ajoutez les fonctions de confidentialité et de routage en comprenant clairement ce que chacune peut — et ne peut pas — masquer.

Pour une configuration périphérique basse consommation similaire, découvrez ZimaBoard 2Mini Home Server . Pour la documentation du pare-feu, consultez le site officiel d’OPNsense. Si vous souhaitez comparer des configurations et partager votre propre installation de serveur domestique, rejoignez la communauté ZimaSpace sur Discord.