Comment The Social Dork construit un pare-feu domestique OPNsense

Merci à The Social Dork | Cybersécurité d’avoir partagé la configuration d’un pare-feu domestique OPNsense sur ZimaBoard 2. Une machine virtuelle gère le routage et les règles du pare-feu, un point d’accès fournit le Wi-Fi et Pi-hole assure le filtrage DNS pour les clients connectés. Regardez le tutoriel YouTube original pour découvrir la démonstration complète.

À regarder avant de lire : Cette vidéo d’environ dix minutes est utile si vous souhaitez séparer la passerelle réseau de votre point d’accès sans fil. Le créateur explique la topologie, démarre OPNsense dans Zima Virtual Machine, configure les interfaces et le DHCP, puis vérifie la connexion d’un ordinateur portable sans fil et son filtrage DNS.

L’étape montrée consiste à connecter un ordinateur portable au réseau par l’intermédiaire du nouveau pare-feu et à utiliser le filtre DNS choisi. La vidéo présente les étapes de configuration pour un premier client. La préoccupation évoquée en introduction à propos des objets connectés vulnérables nécessiterait une segmentation supplémentaire du réseau et des règles d’accès ; placer les appareils sur un nouveau SSID ne suffit pas, à lui seul, à les isoler les uns des autres.

Déterminez quelles fonctions la passerelle existante doit conserver

La discussion sur la topologie distingue trois fonctions que peut masquer un routeur tout-en-un : la connexion au fournisseur, la frontière du pare-feu et du routage, et l’accès sans fil. Une connexion Ethernet peut alimenter le nouveau pare-feu, tandis qu’un service DSL ou câble nécessite toujours le modem ou l’équipement approprié du fournisseur. Remplacer la fonction de routage ne supprime pas cette exigence de connexion physique.

Dans la configuration opérationnelle du créateur, le routeur domestique existant alimente le côté WAN du pare-feu, tandis qu’un point d’accès est relié à son côté LAN. Si la passerelle en amont effectue aussi la traduction d’adresses réseau, cela crée un double NAT. Cela peut convenir pour un premier essai, mais risque de compliquer les services entrants et le dépannage. La disponibilité du mode pont ou du mode passthrough dépend de l’équipement et du service du fournisseur ; vérifiez ce point avant de modifier la connexion utilisée en production.

Notez les paramètres actuels côté fournisseur d’accès avant la bascule. Une vidéo montrant une connexion Ethernet ne permet pas de connaître les exigences de votre FAI en matière d’authentification, de VLAN ou de modem. Gardez à disposition la configuration de l’ancienne passerelle pendant que vous testez le nouveau chemin avec un seul client. Vous pourrez ainsi distinguer un problème de service amont d’une erreur dans le nouveau LAN.

Le double NAT désigne deux niveaux de traduction par routage ; c’est différent de la simple présence d’un point d’accès en aval. Si l’appareil sans fil continue également d’assurer le routage, il peut introduire un autre niveau et un autre service DHCP. Vérifiez son mode de fonctionnement réel et le branchement des câbles au lieu de déduire son rôle de l’étiquette du produit sur son boîtier.

Associez les interfaces virtuelles à une véritable séparation entre WAN et LAN

The Social Dork télécharge une image d’installation d’OPNsense et la démarre dans Zima Virtual Machine sur ZimaBoard 2. Il s’agit d’une démonstration de pare-feu virtualisé. L’hôte continue d’exécuter ZimaOS : son architecture réseau fait donc partie de la conception, tout comme les paramètres d’OPNsense dans la machine virtuelle.

Pour un déploiement similaire, associez explicitement chaque interface virtuelle au port physique prévu ou à un réseau isolé de l’hôte. La présence de deux prises réseau ne configure pas automatiquement cette association. Maintenez le chemin côté WAN séparé des services habituels de l’hôte et veillez à ce que le trafic des clients LAN traverse le pare-feu pour accéder à la connexion amont. Si un client dispose d’un autre chemin qui contourne la machine virtuelle, le pare-feu ne peut pas appliquer de règles à ce trafic.

Suivez les instructions d’installation d’OPNsense et le guide de la machine virtuelle à jour pour l’image et la plateforme choisies. Notez comment accéder à l’hôte et à la console de la machine virtuelle avant de modifier les interfaces. Un redémarrage de l’hôte, un problème de stockage ou l’arrêt de la machine virtuelle peut interrompre cette passerelle : planifiez la maintenance en tenant compte de la connexion du foyer.

Précisez le plan d’interfaces

1. Identifiez les ports physiques de l’hôte et notez quel câble est relié à la connexion amont.
2. Associez l’interface WAN de la machine virtuelle au réseau amont prévu.
3. Associez son interface côté LAN à un réseau en aval distinct.
4. Vérifiez que l’accès à l’administration et les services habituels de l’hôte ne sont pas exposés involontairement côté WAN.
5. Connectez un client de test en aval et vérifiez sa passerelle par défaut réelle avant d’ajouter d’autres appareils.

Le nom d’une interface dans la machine invitée peut ne pas correspondre à l’étiquette imprimée près d’un port physique. Utilisez le mappage réseau de l’hyperviseur et la console de la machine invitée pour établir la correspondance. Vérifiez-la à nouveau après avoir modifié les adaptateurs virtuels. La vidéo présente une configuration fonctionnelle sur la machine du créateur, mais ne répertorie pas tous les ponts réseau de l’hôte ni tous les réglages d’adaptateur que vous pourriez rencontrer.

Allouez des ressources au pare-feu tout en laissant de la capacité à ZimaOS et aux autres services de l’hôte. Le guide de virtualisation d’OPNsense actuel indique un minimum de 3 Go de RAM, un disque virtuel recommandé d’au moins 8 Go et des conseils de compatibilité réseau. Ce sont des conditions de départ, pas une garantie de débit. Les journaux, les VPN, les fonctions d’inspection et les autres charges de travail peuvent modifier la marge nécessaire.

C’est un compromis opérationnel lié au partage d’une même machine : une mise à jour ou un redémarrage de l’hôte peut également arrêter la machine virtuelle de passerelle. Déterminez comment la machine virtuelle démarrera après le démarrage de l’hôte et comment vous la récupérerez si elle ne démarre pas. Une console accessible de façon fiable est particulièrement utile si un mauvais réglage réseau rend l’interface Web inaccessible.

Laissez un seul service DHCP gérer chaque réseau client

Le créateur utilise des réseaux IPv4 différents en amont et en aval : le côté amont utilise des adresses 192.168.0.x et le LAN client des adresses 192.168.1.x. Ce sont des exemples tirés de la vidéo. Choisissez des sous-réseaux non chevauchants adaptés à votre réseau, plutôt que de reprendre des adresses qui sont peut-être déjà utilisées.

Le point d’accès fournit la connexion radio, tandis qu’OPNsense attribue les baux DHCP aux clients en aval. Le tutoriel aborde le mode point d’accès et la désactivation du service DHCP de l’ancien routeur sans fil. Sur les équipements dépourvus de mode point d’accès dédié, la désactivation du DHCP ne garantit pas à elle seule un fonctionnement transparent en tant que point d’accès : vérifiez les exigences du fabricant concernant le câblage LAN vers LAN et le routage/NAT. Veillez à ce que son adresse de gestion reste accessible sans entrer en conflit avec la plage DHCP.

Testez le bail obtenu sur un ordinateur portable. Il devrait recevoir une adresse dans le LAN prévu, l’adresse LAN du pare-feu comme passerelle par défaut et le serveur DNS prévu. Une association Wi-Fi réussie prouve uniquement que la connexion radio fonctionne. L’adresse, la passerelle et le résolveur indiquent si le client a réellement rejoint le nouveau chemin réseau.

Planifiez séparément les adresses fixes et la plage des baux DHCP

Voici un plan indicatif pour un LAN /24, et non la transcription des adresses exactes du créateur. Adaptez-le à vos réseaux existants. Réservez des adresses fixes aux équipements d’infrastructure en dehors de la plage attribuée dynamiquement, et veillez à ce que le réseau en amont soit différent du LAN en aval.

Si Pi-hole se trouve en réalité sur un autre sous-réseau ou sur un réseau virtuel côté hôte, utilisez son véritable point de terminaison accessible ainsi que le routage et les règles nécessaires. L’adresse de l’exemple ne rend pas le service accessible sur le LAN à elle seule. Une entrée DHCP indique aux clients où envoyer une requête ; elle ne crée pas la route et ne démarre pas le serveur.

Après avoir modifié le DHCP, vérifiez le bail sur l’ordinateur portable plutôt que de consulter uniquement la page de configuration du serveur. Confirmez l’adresse attribuée, le masque, la passerelle et les entrées DNS. Un client qui conserve encore un ancien bail peut donner l’impression qu’une nouvelle configuration correcte ne fonctionne pas. Une adresse ou une passerelle inattendue indique également qu’un autre serveur DHCP est peut-être encore actif.

Considérez la première règle d’autorisation comme un test de connectivité

Le créateur commence par une règle de sortie permissive pour le seul ordinateur portable de test et explique comment empêcher les connexions non sollicitées du WAN vers le LAN. OPNsense utilise un filtrage à états : les réponses à une connexion autorisée sont donc prises en charge par l’état de la connexion. La documentation des règles de pare-feu OPNsense explique comment l’interface, le sens et l’ordre des règles influent sur ce comportement.

La vidéo ouvre également l’interface Web depuis son réseau privé en amont. Dans votre propre déploiement, limitez l’accès administratif à un chemin de gestion de confiance et prévoyez une possibilité de récupération par console. L’étiquette WAN décrit un rôle par rapport à ce pare-feu ; un segment privé de laboratoire en amont et l’Internet public correspondent à des conditions d’exposition différentes.

Pour répondre à la préoccupation concernant l’IoT évoquée au début, créez des réseaux distincts avec du matériel compatible, puis définissez le trafic autorisé entre eux. Les appareils qui échangent du trafic au sein d’un même segment local peuvent communiquer sans passer par le pare-feu chargé de l’acheminer. Pour un autre aperçu pratique des décisions relatives à la passerelle et à la confidentialité, consultez la configuration du pare-feu OPNsense de cachito labs.

Distinguer la connectivité de l’isolation

Définissez la source, la destination, le protocole et l’objectif visé avant d’ajouter une règle. Une règle qui permet de vérifier qu’un ordinateur portable peut accéder à Internet ne constitue pas une politique applicable à tous les appareils d’un foyer. Pour segmenter le réseau, utilisez des réseaux distincts et un pare-feu entre eux. Le trafic échangé localement sur un même segment peut ne pas passer par la passerelle.

Lorsqu’une modification de règle semble inefficace, testez une nouvelle connexion et tenez compte de l’état de la connexion. Le guide des règles OPNsense explique le traitement avec état. Les états existants peuvent influer sur un nouveau test, tandis que la réinitialisation de tous les états interromprait d’autres connexions actives. Identifiez le flux de test précis avant d’apporter une modification de diagnostic générale.

Connecter Pi-hole via DHCP sans créer de boucle DNS

Vers la fin, The Social Dork configure le serveur DNS fourni par DHCP avec l’adresse de Pi-hole. Cela intègre le projet de blocage des publicités avec Pi-hole et Tailscale présenté plus tôt au nouveau réseau sans fil. OPNsense contrôle le chemin du trafic acheminé ; Pi-hole analyse les noms DNS demandés par son service. Les deux composants ont des responsabilités différentes.

Le guide d’intégration OPNsense de Pi-hole décrit la distribution directe par DHCP et la redirection via le pare-feu comme deux configurations possibles. Choisissez un chemin cohérent et veillez à ce que les résolveurs ne se renvoient pas les requêtes en boucle. Vérifiez également que les clients peuvent accéder à l’adresse Pi-hole si celle-ci se trouve sur un autre réseau.

Choisissez un chemin de résolution et représentez-le de bout en bout

La vidéo utilise l’adresse de Pi-hole fournie par DHCP pour les clients. La configuration de redirection présentée dans le guide officiel lié est une autre possibilité. Si vous la choisissez, veillez à ce que le DNS en amont de Pi-hole ne renvoie pas directement la requête dans la même chaîne de redirection. Un chemin clair facilite grandement le diagnostic en l’absence de réponse.

Le DNS dépend également du transport et du routage. Si le client et le résolveur se trouvent sur des réseaux différents, vérifiez le chemin et les règles applicables au port TCP/UDP 53. Si le résultat observé diffère de la configuration DHCP, vérifiez les annonces DNS IPv6 et les paramètres DNS indépendants des clients. Le simple fait d’accéder à l’interface web de Pi-hole ne suffit pas.

Pour filtrer le trafic lorsque vous êtes hors de chez vous, consultez à nouveau le guide pas à pas Pi-hole et Tailscale. L’accès DNS à distance, les règles de la passerelle locale et le routage de tout le trafic Internet via un VPN sont des choix distincts. Testez chacun d’eux sur la connexion où il sera réellement utilisé.

Vérifiez l’ensemble du chemin avant de déplacer chaque appareil

La démonstration finale change le réseau Wi-Fi de l’ordinateur portable et compare le même site Web avec et sans le filtrage. Elle illustre le chemin du client sélectionné, mais ne prouve pas que tous les sites Web sont exempts de publicités ni que tous les appareils sont isolés. Vérifiez d’abord l’accès à Internet et le DNS, puis consultez les journaux pertinents du pare-feu et de Pi-hole pour relier chaque résultat au client prévu.

Avant de migrer le foyer, testez le renouvellement du bail d’un client, une connexion autorisée et une connexion volontairement refusée entre des réseaux distincts, si la segmentation fait partie de votre conception. Exportez une configuration de pare-feu fonctionnelle et vérifiez le processus de récupération. L’objectif est d’obtenir une passerelle dont vous pouvez expliquer et gérer le routage, le DHCP, le filtrage et l’administration. Regardez le guide complet de The Social Dork pour configurer le pare-feu domestique OPNsense pour découvrir la topologie d’origine et la séquence de configuration.

Effectuez un test d’acceptation par étapes

1. Connectez-vous au réseau sans fil prévu et vérifiez le nouveau bail du client.
2. Confirmez la passerelle par défaut, puis testez, le cas échéant, une connexion autorisée à partir d’une adresse IP.
3. Résolvez un nom d’hôte autorisé à l’aide du résolveur sélectionné et repérez la requête.
4. Testez un domaine dans la stratégie Pi-hole active et confirmez la réponse attendue.
5. Si vous avez configuré la segmentation, testez une connexion autorisée et une connexion refusée à travers la limite routée.
6. Reconnectez le client ou renouvelez son bail, puis confirmez que les paramètres prévus sont rétablis.
7. Lors d’une fenêtre de maintenance planifiée, vérifiez le chemin de démarrage de l’hôte et de la VM de passerelle avant de vous y fier en continu.

Dépannez dans l’ordre du réseau

Utilisez les journaux pour répondre à une question à la fois. La documentation sur la journalisation du pare-feu d’OPNsense explique qu’un flux à états ne génère pas nécessairement une nouvelle ligne dans le journal en temps réel pour chaque paquet. Le guide de diagnostic du pare-feu fournit la vue des états. Un journal silencieux ne prouve pas à lui seul qu’aucun trafic n’a traversé le pare-feu.

Enregistrez une configuration fonctionnelle avant tout changement important et conservez une procédure claire de retour arrière. Pendant les tests, gardez l’ancienne connexion disponible séparément ; évitez de relier accidentellement les réseaux amont et aval en contournant le pare-feu. Une procédure de retour arrière utile rétablit une configuration connue de la passerelle et des clients, au lieu d’introduire deux routeurs concurrents dans le même segment client.

FAQ

ZimaBoard 2 peut-elle remplacer à elle seule la radio Wi-Fi ?

Dans cette vidéo, un point d’accès distinct fournit le Wi-Fi. La carte héberge la passerelle virtualisée et les services associés. Le routage et l’accès sans fil sont deux fonctions différentes.

Puis-je retirer le modem du fournisseur d’accès ?

Uniquement si votre raccordement de service n’en a plus besoin. Les configurations DSL, câble et propres à certains fournisseurs peuvent toujours nécessiter leur équipement de terminaison d’origine. Vérifiez les exigences physiques et celles du service avant de remplacer une passerelle.

Une règle autorisant le trafic sortant isole-t-elle les appareils IoT ?

Cela ne crée pas de séparation réseau. Les appareils d’un même segment local peuvent communiquer sans passer par le pare-feu de routage. L’isolation nécessite des réseaux distincts et une politique testée entre eux.

Pi-hole doit-il fonctionner dans OPNsense ?

Le projet présenté utilise un service Pi-hole à côté du pare-feu virtualisé et annonce son adresse via DHCP. L’essentiel est de disposer d’un chemin DNS accessible et cohérent ; ne partez pas du principe que l’installation d’OPNsense installe également ce service.

Pourquoi la VM du pare-feu a-t-elle besoin de deux chemins réseau ?

La configuration routée nécessite un chemin vers l’amont et un autre, distinct, vers l’aval. Le mappage correct des interfaces entre l’invité et l’hôte établit cette séparation. Le fait de voir deux noms d’adaptateur ne prouve pas à lui seul que les réseaux sont isolés.

Que se passe-t-il lorsque l’hôte ZimaOS redémarre ?

Son pare-feu invité et les autres services hébergés peuvent devenir indisponibles. Planifiez le démarrage et la récupération des VM, puis vérifiez-les pendant une fenêtre de maintenance. Le partage du matériel fait de la maintenance de l’hôte un élément de la disponibilité de la passerelle.

Conclusion

La configuration de The Social Dork est utile, car elle transforme une passerelle tout-en-un en plusieurs fonctions faciles à comprendre : connexion au fournisseur, routage virtualisé, accès sans fil, attribution des adresses et filtrage DNS. Le premier test réussi avec un ordinateur portable constitue un point de départ. Une passerelle domestique maintenue en bon état nécessite aussi des limites réseau vérifiées, une politique adaptée à chaque groupe de clients et une procédure de récupération.

Effectuez les vérifications avec un seul client avant de connecter tout le foyer, puis validez séparément toute segmentation supplémentaire ou le fonctionnement du VPN. Gardez la présentation vidéo d’OPNsense à portée de main, avec votre propre plan d’interface et la documentation officielle à jour. L’objectif est d’obtenir un réseau dont vous pouvez expliquer, tester et rétablir le fonctionnement.