6. Cas d'usage

Des exemples traités, chacun écrit comme l'ordre dans lequel faire les choses. Ils supposent que vous avez terminé la Première configuration : un lien montant qui marche, un réseau interne, et des clients qui atteignent l'internet.

Les adresses des exemples utilisent les plages de documentation. Remplacez-les par les vôtres.

Publier un serveur

Un serveur web en 192.168.1.10 doit être joignable depuis l'internet sur l'adresse publique du boîtier.

Donnez au serveur une adresse fixe. Soit statiquement sur le serveur, soit en réservation dans Services → Kea DHCP → Kea DHCPv4 pour qu'il reçoive toujours la même. Une redirection vers une adresse qui change est une redirection qui casse.
Créez la redirection. Firewall → NAT → Destination NAT, ajoutez une règle : Interface* : WAN Protocol* : TCP Destination* : l'adresse WAN, port 443 Redirect target* : 192.168.1.10, port 443 * Laissez-la créer la règle de pare-feu correspondante.
Restreignez la source si vous le pouvez. Si seules vos agences en ont besoin, mettez leurs adresses dans un alias (Firewall → Aliases) et réglez la source de la règle sur cet alias au lieu de any. Un service publié à tout le monde est un service qu'il faut défendre contre tout le monde.
Testez depuis l'extérieur. Pas depuis l'intérieur : un client du LAN qui atteint l'adresse WAN emprunte un autre chemin (et demande de la réflexion). Servez-vous d'un téléphone en données mobiles, ou de Network → Diagnostics → Port Probe depuis un autre site.

Quand cela ne marche pas, dans l'ordre : Firewall → Log Files → Live View montre-t-il le paquet qui arrive ? Si non, il ne vous a jamais atteint — l'opérateur ou un équipement en amont le bloque. S'il le montre bloqué, la règle de pare-feu manque ou se trouve sous une règle bloquante. S'il le montre passé et que le client n'obtient toujours rien, c'est que le serveur lui-même n'écoute pas ou a son propre pare-feu.

Segmenter avec des VLAN

Les invités, les caméras et le bureau ne devraient pas être sur un seul réseau.

Sur le commutateur, faites du port vers le boîtier un trunk portant les étiquettes que vous allez utiliser. Cette étape est hors du boîtier, et c'est celle qu'on oublie.
Créez les interfaces. Network → Interfaces → Create new, Type : VLAN, l'interface parente, l'étiquette, Role : LAN. Donnez à chacune une adresse (192.168.20.1/24 pour les invités, par exemple) et sa propre plage DHCP — un formulaire par réseau.
Écrivez les règles. Une interface neuve n'autorise rien tant que vous ne l'avez pas dit. Pour un réseau invité, la forme habituelle est : Bloquer invités → tout réseau interne* (mettez vos plages internes dans un alias et bloquez le trafic vers cet alias) Autoriser invités → le DNS du boîtier, si les invités s'en servent Autoriser invités → n'importe où (l'internet)

Dans cet ordre : le blocage doit venir en premier, parce que la première correspondance l'emporte.

Vérifiez depuis un appareil invité qu'il atteint l'internet et qu'il ne peut pas atteindre le réseau du bureau. Testez le « ne peut pas » aussi soigneusement que le « peut ».

Deux liens montants avec bascule

Une deuxième ligne doit prendre le relais quand la première tombe.

Montez le second lien montant comme sa propre interface avec Role : WAN (Network → Interfaces).
Donnez aux deux passerelles une adresse de surveillance dans Network → Gateways → Configuration — quelque chose de joignable au-delà du routeur de l'opérateur, par exemple un résolveur public. Surveiller la passerelle elle-même ne prouve que la vie du routeur, ce qui n'est pas la question.
Groupez-les. Network → Gateways → Group : la principale en palier 1, la secondaire en palier 2. Deux membres dans le même palier se partagent la charge à la place ; c'est de la répartition de charge, pas de la bascule, et cela casse tout ce qui exige une adresse source stable.
Pointez le trafic sur le groupe. Dans la règle LAN qui autorise le trafic sortant, réglez Gateway sur le groupe.
Testez en débranchant le câble. Regardez Network → Gateways changer d'état et vérifiez que le trafic continue de couler. Les connexions existantes tomberont — elles avaient été établies par l'autre ligne — et les nouvelles réussiront.

VPN site à site avec WireGuard

Deux bureaux, 192.168.1.0/24 et 192.168.2.0/24, réunis.

Sur chaque boîtier :

VPN → WireGuard → Instances, ajoutez une instance : un port d'écoute (51820), une adresse de tunnel (10.10.0.1/24 côté A, 10.10.0.2/24 côté B). Notez la clé publique qu'elle engendre.
VPN → WireGuard → Peers, ajoutez l'autre côté : sa clé publique, son adresse publique et son port comme extrémité, et des allowed IPs couvrant l'adresse de tunnel et le réseau interne de l'autre côté — 10.10.0.2/32, 192.168.2.0/24 côté A, en miroir côté B.
Firewall → Rules sur le WAN : autorisez l'UDP vers le port d'écoute depuis l'adresse de l'autre site.
Firewall → Rules sur l'interface du tunnel : décidez de ce que l'autre bout peut atteindre. « Tout » est une décision, pas une valeur par défaut.

Vérifiez dans VPN → WireGuard → Status : une poignée de main récente des deux côtés et des compteurs qui bougent. Pas de poignée de main veut dire que les deux bouts ne se parlent pas — vérifiez la règle WAN et l'adresse d'extrémité. Une poignée de main sans trafic veut dire que le tunnel est monté et que le routage ou les règles sont faux : regardez d'abord les allowed IPs, puisqu'elles sont à la fois la route et le filtre.

Les télétravailleurs

Des gens à domicile ont besoin d'atteindre le bureau.

Avec WireGuard — le plus simple, la meilleure performance :

Ajoutez une instance pour les utilisateurs distants, avec un réseau de tunnel à elle (10.20.0.1/24).
Pour chaque personne, servez-vous de VPN → WireGuard → Peer generator : il produit la configuration cliente et un code QR pour l'application mobile. Leurs allowed IPs décident de ce qu'ils peuvent atteindre ; un /32 pour leur adresse de tunnel et le réseau du bureau dont ils ont besoin.
Une règle WAN pour le port d'écoute ; des règles sur l'interface du tunnel pour ce qu'ils ont le droit d'atteindre.

Avec OpenVPN — quand les clients doivent traverser des réseaux hostiles :

System → Trust : une autorité de certification et un certificat serveur.
VPN → OpenVPN → Instances : une instance serveur, en TCP sur 443 s'il vous faut survivre aux réseaux restrictifs, avec le réseau du tunnel et les routes et le DNS qu'elle pousse.
Un utilisateur par personne (Access → Users) avec un certificat client.
VPN → OpenVPN → Client Export donne à chacun son profil. Il contient sa clé — envoyez-le par un moyen auquel vous faites confiance, pas par un courriel en clair.

Pour les deux : retirez l'accès quand quelqu'un s'en va. WireGuard — supprimez le pair. OpenVPN — révoquez le certificat dans System → Trust → Revocation.

Wi-Fi invité avec portail captif

Les visiteurs ont l'internet, à vos conditions, sans compte.

Un réseau à eux — un VLAN pour les invités (ci-dessus), avec des règles qui les laissent sortir et les tiennent à l'écart de tout ce qui est interne.
Une zone de portail — Hotspot → Administration : l'interface invités, le texte de la page du portail, et les limites de session et de bande passante.
Comment ils s'authentifient — simple clic avec conditions pour un café, des bons d'accès pour un hôtel, un annuaire ou un serveur RADIUS là où les invités sont connus.
Les bons d'accès, si vous en utilisez : Hotspot → Vouchers engendre un lot avec une période de validité et les imprime. L'horloge démarre à la première utilisation.
Regardez-le fonctionner — Hotspot → Sessions liste qui est connecté, et Hotspot → Log File enregistre chaque tentative.

Si la loi du lieu où vous exercez vous oblige à conserver des traces de qui a utilisé le réseau, voyez System → Compliance — et lisez la réserve qui s'y trouve.

Détection d'intrusion et moteur de sécurité

Voir ce qu'il y a sur le réseau, puis agir dessus.

Installez et configurez le moteur (Security and Policy → Settings) : quelles interfaces il inspecte, et son mode de déploiement.
Regardez d'abord. Laissez la politique Default permissive, activez l'IDS/IPS en mode détection, et laissez tourner une journée.
Lisez ce qu'il a trouvé — Security and Policy → Reports et les cartes du tableau de bord du moteur. Attendez-vous à des faux positifs ; ils sont la raison d'être de l'étape 2.
Laissez-le bloquer ensuite. Activez la prévention pour les catégories de règles que vous avez confirmées, pas toutes d'un coup.
Donnez-vous une liste d'exclusions avant d'en avoir besoin : le terminal de paiement, le boîtier de sauvegarde, la machine qui parle au prestataire comptable — Exclusions dans la politique.

Inspection TLS

Inspecter le trafic chiffré — ce que cela coûte et comment le faire correctement.

La plus grande part du trafic est chiffrée, donc un analyseur qui ne voit pas à l'intérieur voit peu de chose. L'inspection fonctionne en terminant le TLS sur le boîtier et en réémettant le certificat depuis une autorité à vous — ce qui veut dire que chaque client doit faire confiance à cette autorité, et que chaque client qui le fait confie son trafic au boîtier.

Créez l'autorité — System → Trust → Authorities. Une AC de longue durée dont le nom dit ce qu'elle est.
Distribuez-la aux clients — par stratégie de groupe, par MDM, ou à la main. Un client qui ne lui fait pas confiance voit des erreurs de certificat sur chaque site, ce qui ressemble exactement à une attaque, parce que techniquement c'en est une.
Activez le mandataire TLS — Security and Policy → Settings → TLS Proxy, avec cette AC.
Activez l'inspection dans une politique — TLS & Transport dans la politique qui couvre les appareils concernés.
Excluez ce qui ne doit pas être inspecté — la banque, la santé, les sites administratifs, et tout ce qui épingle des certificats (qui échouera de toute façon).

L'inspection est une décision au poids juridique et éthique. Dans beaucoup de juridictions, les salariés doivent être informés, et certaines catégories de trafic ne doivent jamais être interceptées. Décidez de la politique avec votre organisation avant d'activer la fonction, pas après.

Une paire à haute disponibilité

Deux boîtiers, pour qu'une panne soit invisible.

Construisez-les de la même façon : même version, mêmes interfaces, même câblage.
Un lien dédié entre eux pour la synchronisation.
Des adresses CARP — Network → Virtual IPs sur chaque interface que les clients utilisent. Les clients pointent sur l'adresse CARP, jamais sur celle d'un nœud.
La synchronisation d'état sur le lien dédié, pour que les connexions survivent à une bascule.
La synchronisation de configuration — High Availability → Settings, sur le maître seulement, pointée sur le secours.
Testez la bascule : redémarrez le maître et regardez High Availability → Status sur le secours. Puis revenez en arrière.

Une paire qui n'a jamais basculé exprès n'a pas été testée.

Listes de blocage DNS

Bloquer la publicité, le pistage et les domaines malveillants connus, pour tout le réseau.

Services → Unbound DNS → Blocklists : abonnez-vous aux listes que vous voulez, ajoutez vos propres entrées, et enregistrez. Les clients qui utilisent le boîtier comme résolveur sont couverts sans rien à installer.

Deux réserves à connaître : un client qui utilise son propre résolveur DNS-over-HTTPS contourne tout cela (bloquez ou redirigez le DNS sortant si cela compte), et une liste de blocage finira par casser un site dont quelqu'un a besoin — gardez une liste d'autorisations et dites aux gens comment la demander.

Précédent5.12 Alimentation Suivant7. Maintenance