OPNsense ou OpenWrt pour un laboratoire domestique multi-VLAN avec des services auto-hébergés

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

Pour un laboratoire domestique multi-VLAN avec des services auto-hébergés, OPNsense est généralement le meilleur choix lorsque la passerelle est un pare-feu x86 dédié dont la fonction principale est le routage, l’application des règles, le VPN, la journalisation et l’inspection de sécurité. OpenWrt convient généralement mieux si vous souhaitez réutiliser du matériel de routeur pris en charge, regrouper le Wi-Fi et le routage dans un appareil compact ou créer des rôles flexibles de point d’accès et de routeur périphérique autour de la mise en réseau Linux.

Aucune des deux plateformes ne l’emporte parce que l’une « prend en charge les VLAN » et l’autre non : elles le font toutes les deux. La décision porte sur le mode d’exploitation. OPNsense propose un flux de travail axé sur le pare-feu, avec des interfaces, des alias, des groupes, des règles avec état, des VPN et un système IPS organisés autour d’une appliance de sécurité dédiée. OpenWrt propose une plateforme Linux axée sur le routage, avec la commutation DSA, des ponts compatibles VLAN, des zones de pare-feu, des paquets et une grande flexibilité matérielle intégrée.

Comparez le rôle de la passerelle avant de comparer les fonctionnalités

Un laboratoire domestique multi-VLAN comporte généralement au moins quatre fonctions sur la passerelle : acheminer le trafic entre les sous-réseaux, contrôler les zones autorisées à initier des connexions, fournir un accès à Internet et exposer ou tunneler certains services auto-hébergés. Lorsque cette passerelle gère également les règles DNS, l’accès à distance, les journaux de trafic, la prévention des intrusions ou plusieurs exceptions entre les appareils IoT, les clients de confiance, les serveurs et les invités, la maintenabilité devient aussi importante que le débit brut.

La comparaison ZimaSpace existante entre un routeur grand public et un pare-feu dédié établit cette limite architecturale. Cette comparaison va un niveau plus loin : si vous avez déjà besoin d’une passerelle open source compatible avec les VLAN, quel modèle logiciel convient le mieux ?

Critère de décision OPNsense OpenWrt
Conception principalement axée sur Appliance dédiée de pare-feu/routeur Routeur, point d’accès, commutateur ou passerelle Linux intégrée flexible
Matériel typique Appliance ou PC x86-64 De nombreux routeurs, SBC et cibles x86 pris en charge
Flux de travail des règles multi-VLAN Règles d’interface, groupes, alias et pare-feu à états Interfaces/ponts, ainsi que zones de pare-feu et règles de transfert
Fonction Wi-Fi intégrée Généralement délégué à des points d’accès externes Souvent un point fort majeur sur le matériel de routeur pris en charge
Flux de travail IDS/IPS Intégration Suricata documentée et intégrée Possible grâce aux paquets, mais dépend davantage de l’appareil
Idéal pour Passerelle de sécurité centrale Routeur/AP/nœud périphérique flexible

Les deux peuvent créer des VLAN, mais ils représentent le réseau différemment

Le modèle DSA actuel d’OpenWrt expose les ports du commutateur via le réseau Linux et prend en charge plusieurs réseaux au moyen de ponts compatibles VLAN et de trunks marqués. Le tutoriel DSA du projet présente des VLAN de pont distincts, des ports marqués et non marqués, ainsi que l’affectation à des zones de pare-feu pour les interfaces VLAN routées. Cela suffit pour créer des réseaux de confiance, IoT, invités, serveurs et administration sur du matériel adapté.

OPNsense aborde le même problème du point de vue d’une appliance pare-feu. Il prend en charge les interfaces VLAN 802.1Q, tandis que ses règles de pare-feu à états sont regroupées par interface et peuvent être combinées avec des alias et des groupes d’interfaces. Ses alias permettent de représenter plusieurs hôtes, réseaux ou ports sous forme d’objets de politique réutilisables.

Pour un laboratoire doté de trois VLAN et d’une douzaine de règles, les deux modèles restent gérables. À mesure que l’ensemble de règles s’agrandit, la question devient de savoir quel modèle mental vous préférez reconstituer à 2 heures du matin : une configuration de routeur Linux composée de périphériques, d’interfaces, de ponts VLAN, de zones, de paquets et d’UCI — ou une configuration de pare-feu dédiée structurée autour d’interfaces, de groupes, d’alias, de politiques et de services de sécurité.

OPNsense est plus performant lorsque la politique devient le produit principal

Supposons que le laboratoire dispose d’un LAN de confiance, d’un VLAN IoT, d’un VLAN dédié aux caméras, d’un VLAN des serveurs, d’un réseau invité, d’un réseau d’administration et d’utilisateurs VPN. Le travail difficile ne consiste plus à créer des balises VLAN, mais à maintenir des exceptions telles que :

  • Home Assistant peut initier certaines connexions sélectionnées vers les appareils IoT.
  • Les appareils IoT peuvent utiliser le DNS et le NTP, mais ne peuvent pas initier de sessions vers le VLAN des serveurs.
  • Les caméras peuvent accéder au NVR, mais pas à Internet.
  • Les utilisateurs VPN distants peuvent accéder aux services d’administration, mais pas aux clients invités.
  • Le trafic public du proxy inverse peut uniquement atteindre les ports des applications prévues.

OPNsense est particulièrement à l’aise dans ce domaine, car le pare-feu constitue son interface principale. Il propose un classement documenté des règles, un suivi des états, des groupes, des catégories, la journalisation, des alias, le NAT et le routage fondé sur des politiques. Ses groupes d’interfaces peuvent appliquer une politique commune à plusieurs interfaces réseau sans dupliquer la même règle partout.

Cela ne signifie pas qu’OpenWrt ne peut pas appliquer les mêmes politiques. Il le peut. La différence réside dans l’orientation opérationnelle : OPNsense part du principe que l’appareil est un pare-feu, tandis qu’OpenWrt est une distribution de routeur polyvalente pouvant être adaptée à de nombreux rôles réseau.

OpenWrt est plus performant lorsque la flexibilité matérielle et le Wi-Fi comptent

L’avantage d’OpenWrt apparaît lorsque la passerelle sert aussi de point d’accès, de routeur de voyage, d’appareil périphérique basse consommation ou de routeur grand public reconverti. Son modèle de VLAN et de commutateur reflète la diversité des composants matériels de commutation intégrés et des états de migration vers DSA selon les appareils.

Ce modèle matériel étendu est utile, mais il introduit une exigence à laquelle les utilisateurs d’OPNsense sont moins souvent confrontés : vérifier la cible matérielle exacte, l’architecture du commutateur, la prise en charge du chipset Wi-Fi, la capacité de stockage flash et de RAM, ainsi que la voie de mise à niveau avant de concevoir le réseau autour de cet équipement. Deux routeurs exécutant OpenWrt peuvent avoir des capacités très différentes en matière de ports, de radios et d’accélération.

Si vous possédez déjà un routeur OpenWrt bien pris en charge, capable d’acheminer votre connexion Internet à la vitesse requise, de gérer les VLAN nécessaires et d’héberger les paquets VPN requis, le remplacer uniquement parce qu’OPNsense dispose d’une interface davantage axée sur le pare-feu peut ajouter du matériel sans résoudre un véritable problème.

OPNsense suppose un matériel plus dédié

OPNsense cible actuellement les systèmes x86-64. Son guide matériel officiel indique 8 Go de RAM et un processeur multicœur à 1,5 GHz comme configuration recommandée pour exécuter l’ensemble standard de fonctionnalités dans les cas d’utilisation courants, tandis que des configurations inférieures peuvent faire fonctionner des configurations allégées ou réduites.

Il s’agit d’une philosophie de déploiement différente de l’installation d’OpenWrt sur un routeur compact. Un petit pare-feu x86 doté de plusieurs interfaces réseau de qualité coûte plus cher et nécessite une prise électrique supplémentaire, mais il sépare aussi le routage et la sécurité du Wi-Fi. Les points d’accès peuvent alors être mis à niveau, redémarrés ou repositionnés sans remplacer la passerelle principale.

Pour un environnement de serveur domestique qui devient déjà fortement axé sur l’infrastructure, cette séparation est souvent un avantage. Pour un petit appartement avec un point d’accès et trois VLAN, elle peut constituer une complexité inutile.

La prise en charge des VPN est solide sur les deux plateformes

WireGuard ne tranche pas non plus. OpenWrt propose des instructions de configuration WireGuard à jour, et OPNsense documente les flux WireGuard pour les utilisateurs nomades comme pour les connexions site à site dans sa documentation VPN.

La véritable différence réside dans ce qui se passe autour du tunnel. Si les utilisateurs du VPN ont besoin de leurs propres objets de stratégie, de plusieurs groupes de destinations, d’un routage sélectif, de journaux détaillés ou de plusieurs zones internes, le flux de travail centré sur le pare-feu d’OPNsense devient attrayant. Si le VPN sert simplement à permettre à quelques appareils personnels d’accéder au réseau local via un routeur compact, OpenWrt peut rester le système le plus simple.

L’IDS/IPS fait pencher la décision en faveur d’OPNsense

Lorsque la passerelle doit inspecter le trafic plutôt que simplement le router et le filtrer, le dimensionnement du matériel devient plus important. OPNsense dispose d’un flux de prévention des intrusions Suricata documenté, qui inclut la sélection des interfaces et les considérations relatives au déchargement matériel spécifique à l’IPS.

OpenWrt peut exécuter des paquets de sécurité supplémentaires sur un matériel suffisamment puissant, mais le résultat réellement exploitable dépend bien davantage du processeur, de la mémoire vive, du stockage et de la prise en charge de l’accélération propres au routeur utilisé. Si un IDS/IPS actif en permanence est réellement nécessaire, choisir ensemble le logiciel pare-feu et le matériel x86 est généralement plus facile à évaluer que de considérer l’inspection comme un paquet supplémentaire sur un routeur Wi-Fi aux ressources limitées.

Ne supposez pas qu’OPNsense est automatiquement plus rapide

Le débit dépend de l’architecture du processeur, de la qualité des cartes réseau, de la taille des paquets, du NAT, de la cryptographie VPN, de l’IDS/IPS, de la mise en forme du trafic, du PPPoE, du déchargement matériel et de l’appareil OpenWrt utilisé. Un appareil OpenWrt x86 puissant peut dépasser les performances d’un équipement OPNsense peu puissant, tandis qu’une machine OPNsense correctement dimensionnée peut surpasser un routeur embarqué bon marché lorsque le routage multi-gigabit et l’inspection sont activés.

Comparez donc le matériel nécessaire pour prendre en charge votre ensemble réel de fonctionnalités. Testez le routage Internet, le routage inter-VLAN, le débit VPN et l’utilisation du processeur avec les services exacts que vous comptez laisser activés. Un débit de routage annoncé sans les règles du pare-feu ni les fonctions VPN et d’inspection ne correspond pas à ce que verra votre laboratoire domestique.

La meilleure architecture repose souvent sur OPNsense au cœur du réseau et OpenWrt en périphérie

Ces plateformes n’ont pas besoin de se remplacer l’une l’autre. Une architecture multi-VLAN particulièrement claire est la suivante :

Internet
   |
Passerelle x86 OPNsense
   |
Trunk 802.1Q
   |
Commutateur administrable
   |---------------- Serveurs domestiques / NAS
   |---------------- Clients filaires
   |
Point(s) d’accès OpenWrt
   |---------------- Wi-Fi de confiance
   |---------------- Wi-Fi IoT
   |---------------- Wi-Fi invité

Dans cette topologie, OPNsense gère le routage inter-VLAN, les politiques, le VPN, les journaux et l’IPS facultatif. OpenWrt fournit les radios Wi-Fi et associe les SSID aux VLAN sans avoir à être l’appliance de sécurité centrale. Cela correspond également aux recommandations de ZimaSpace concernant les réseaux invités et les VLAN : la balise VLAN n’est que le mécanisme de segmentation ; c’est la politique du pare-feu routé qui détermine réellement les zones accessibles.

Matrice de décision pour un laboratoire domestique auto-hébergé

Votre priorité Meilleur point de départ Pourquoi
Pare-feu central dédié avec de nombreuses politiques VLAN OPNsense Processus privilégiant le pare-feu pour les règles, les alias, la journalisation et les interfaces
Réutiliser un routeur Wi-Fi pris en charge OpenWrt Rôle intégré de routeur et de point d’accès, avec un vaste écosystème d’appareils
IDS/IPS à la passerelle OPNsense Processus Suricata documenté et dimensionnement x86 plus simple
Un seul boîtier compact pour le routage et le Wi-Fi OpenWrt Conçu pour le matériel des routeurs embarqués
Plusieurs points d’accès avec un commutateur administrable Cœur OPNsense + points d’accès OpenWrt Sépare la politique de sécurité du matériel radio
Approfondir l’apprentissage des réseaux Linux OpenWrt DSA, ponts, UCI, paquets et infrastructure réseau Linux sont visibles

Verdict final

Choisissez OPNsense lorsque la passerelle multi-VLAN est devenue une infrastructure de sécurité ; choisissez OpenWrt lorsque la passerelle reste principalement un routeur ou un point d’accès flexible. Pour un laboratoire domestique auto-hébergé avec plusieurs VLAN, des services publics, des utilisateurs VPN et des exceptions de politique, un boîtier OPNsense dédié offre généralement un modèle d’exploitation plus clair à long terme.

OpenWrt reste un excellent choix pour les petits réseaux et constitue souvent le meilleur complément plutôt que le concurrent : utilisez-le sur des points d’accès ou des routeurs périphériques, tandis que le pare-feu dédié gère les politiques inter-VLAN.

FAQ

OpenWrt peut-il acheminer plusieurs VLAN ?

Oui. La version actuelle d’OpenWrt prend en charge les configurations de ponts compatibles VLAN avec DSA, les trunks marqués, les interfaces séparées et les zones de pare-feu sur le matériel pris en charge.

OPNsense nécessite-t-il un commutateur administrable ?

Pas pour toutes les configurations, mais un commutateur administrable compatible VLAN est normalement requis lorsqu’un seul trunk physique doit transporter plusieurs VLAN filaires au-delà de l’appliance pare-feu.

Quelle solution est la plus simple pour les VLAN Wi-Fi ?

OpenWrt est souvent plus simple lorsque le même appareil pris en charge fournit les radios. OPNsense est généralement associé à des points d’accès séparés compatibles avec les VLAN.

Dois-je remplacer OpenWrt, qui fonctionne, par OPNsense ?

Seulement si le modèle dédié de pare-feu résout une véritable limite, comme la complexité des règles, l’inspection, la récupération indépendante de la passerelle ou le débit matériel. Une passerelle OpenWrt fonctionnelle n’a pas besoin d’être remplacée uniquement par souci de pureté architecturale.

Comparaisons de produits

Plus à lire

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.