Pendant très longtemps notre réseau local était d'une simplicité navrante. Une borne universelle provenant d'un fournisseur d'accès à l'Internet (FAI) était au centre du réseau qui ne contenait qu'un seul segment auquel tous les appareils étaient connectés. La grande majorité des clients des FAIs sont sans doute dans une situation semblable et pour la plupart d'entre eux cet arrangement est tout à fait adéquat. Cependant, notre ménage est peut-être plus branché pour des raisons professionnelles et à cause de mon intérêt pour la domotique, la programmation et l'électronique numérique. Parmi les appareils connectés à la borne universelle qui est à la fois un modem, un commutateur Ethernet et un point d'accès sans fil, il y a des ordinateurs de bureau et des portables (Linux, MacOS, Windows), des téléphones soi-disant intelligents (Android et IOS), des tablettes (Android et IOS), de nombreux modules domotiques, des haut-parleurs intelligents (Alexa), une passerelle multimédia (Roku), des serveurs de stockage (OMV). En plus, la borne du FAI prend en charge la téléphonie fixe et la télévision en direct. On imagine facilement la pagaille.

Il y a environ 18 mois, j'ai entrepris de réorganiser tout cela dans l'espoir de créer un réseau local résilient aussi indépendant que possible des services du FAI. Cette démarche a été décrite dans un billet intitulé Better Home Networking with OPNsense and VLANs qui n'a pas été traduit en français. Il s'agissait d'une exposition plutôt descriptive articulée autour d'une question : La création d’un meilleur réseau local avec OPNsense et les VLAN a-t-elle finalement été un échec ? Avec un peu de recul, je me rends compte que sa conclusion insistait trop sur des problèmes. Il n'était pas très clair que l'objectif premier d'avoir un réseau local agencé de façon logique était atteint. Depuis, le réseau a été amélioré et les problèmes soulevés ont été pour la plupart résolus. En particulier, WireGuard fonctionne très bien.

Je n'ai pas publié de billets sur le sujet depuis plus d'un an même s'il accapare une grande partie de mes loisirs. Il y a tellement d'information sur l'Internet provenant de personnes qui semblent être des administrateurs de système dans leur vie professionnelle et qui s'amusent à décrire comment répliquer, en partie, ce qui est fait dans leur entreprise que je me questionne sur la pertinence d'une éventuelle contribution d'un amateur, voir d'un dilettante. Je n'ai pas ni un matériel de pointe ni un éventail de matériel qui me permettrait d'émettre des jugements fondés quant au choix de l'équipement. Je n'ai certainement pas les connaissances qui m'autorisent à émettre des conseils. Conséquemment, je me limite à décrire ma démarche sans prétendre qu'elle est optimale ou même correcte et en espérant que des lecteurs y trouve de l'information qui leur soit utile.

Voici les sujets que je voudrais abordés dans cette série de billets.

• Aspects matériels du réseau local

  Le vieux billet Better Home Networking with OPNsense and VLANs contient la section The New Home Network Structure décrivant l'aspect matériel du réseau local tel qu'il était en juin 2024. Depuis il a eu des changements qui ne sont pas encore documentés.

• Installation du pare-feu OPNsense

  Actuellement, le billet Installation du pare-feu OPNsense est complété.

• Utilisation du serveur NTP local d'OPNsense

  Le billet intitulé Utilisation du serveur NTP local d'OPNsense montre qu'il est facile de s'assurer que tous les appareil du réseau local coordonnent leur horloge à l'aide du serveur NTP local d'OPNsense sans avoir à modifier leur configuration. L'ajout d'une règle de réacheminement du port 123 vers le serveur local est tout ce qu'il faut. Il n'y avait aucune information à ce sujet dans l'ancien billet sur la première configuration d'OPNsense

• Réseaux virtuels dans OPNsense

  La création et l'utilisation des réseaux virtuels ont été abordées dans la section The IOT VLAN du vieux billet. Il s'avère que certains recommandent de ne pas transmettre des trames Ethernet standard (untagged packets) et des trames modifiées (tagged packets selon IEEE 802.1Q qui accommodent les réseaux virtuels) sur un même lien physique (trunk). C'est exactement ce qui est en place dans notre réseau local depuis plus d'un an. Nous n'avons pas rencontré de problèmes, mais il me faut étudier de plus près ce sujet avant d'en discuter à nouveau.

• Services DHCP et DNS dans OPNsense

  Les services DHCP et DNS sont des composants essentiels du pare-feu. L'assistant de configuration d'OPNsense choisit les logiciels qui mettent en oeuvre ces services et les configurent d'une façon raisonnable, mais j'ai préféré choisir un autre logiciel pour ce qui est de DHCP et j'ai modifié la configuration du service DNS. Un billet qui explique et motive mes choix est en préparation.

• Blocage de sites avec OPNsense

  Le résolveur DNS Unbound qu'utilise OPNsense prend en charge le blocage de sites malveillants comme le font les logiciels Adguard Home et Pi-Hole. Je trouve intéressant d'utiliser cette fonctionnalité d'Unbound plutôt que de créer un serveur pour faire cette tâche. À venir.

• WireGuard dans OPNsense

  Contrairement à ce qui était affirmé dans mon billet About WireGuard on OPNsense, le composant d'OPNsense qui intègre WireGuard, le serveur de réseau privé virtuel, fonctionne très bien.

Il n'y a pas d'échéance pour la publication des billets proposés et l'ordre n'est pas fixe non plus.