Segmentation VPN + VLAN pour bureau, entrepôt et caméras (sans regrets)

Le modèle mental : le VPN transporte, le VLAN contient

Les gens confondent VPN et VLAN parce que les deux « séparent » des choses. Ils séparent des couches différentes de la réalité.
Un VPN est un tunnel : il transporte des paquets entre des sites ou des clients. Un VLAN est un outil de segmentation locale : il sépare un domaine de commutation
afin que vos caméras ne partagent pas l’espace L2 avec des ordinateurs portables et des IoT aléatoires.

Si vous retenez une règle, retenez celle-ci : Les VLAN servent à limiter le rayon d’explosion ; les règles de pare-feu servent à limiter l’intention ; les VPN servent à assurer la portée.
La « segmentation » sans filtrage est juste de la gestion de câbles sophistiquée.

Dans des configurations multisites (bureau + entrepôt), les VLAN existent à l’intérieur de chaque site, et le VPN transporte le trafic sélectionné entre les sites.
En général, vous ne voulez pas étendre des VLAN à travers le VPN sauf si vous avez une raison très précise, testable, et un goût pour la douleur.
L2 sur VPN est l’endroit où l’espoir vient mourir.

Conseil orienté : faites le routage entre VLAN au niveau 3 (pare-feu ou switch L3), appliquez la politique là, et routez entre sites via le VPN.
Restez ennuyeux. Les réseaux ennuyeux restent opérationnels.

Une citation à collante : « L’espoir n’est pas une stratégie. » — souvent attribuée à la culture des opérations (répétée à l’envi ; la formulation varie).
Considérez-la comme une idée paraphrasée si vous avez vu une version différente. Le message reste valable.

Faits intéressants et contexte historique (ce qui explique le bazar actuel)

• 802.1Q VLAN tagging est devenu la norme à la fin des années 1990 ; avant cela, les « VLAN » étaient souvent propriétaires et incompatible entre fournisseurs.
• IPsec existe depuis les années 1990 aussi, conçu initialement pour IPv6, puis adapté à tout le reste parce que la réalité intervient.
• NAT est devenu la valeur par défaut non pas parce que c’était élégant, mais parce que l’épuisement d’IPv4 était prévisible et que nous l’avons ignoré de toute façon.
• Spanning Tree Protocol (STP) existe parce que les humains sont physiquement incapables de ne pas faire de boucles avec des câbles.
• PoE (Power over Ethernet) a propulsé la popularité des caméras : un câble pour l’alimentation et le réseau signifie que les équipes facilities « font du réseau ».
• ONVIF a été créé pour standardiser l’interopérabilité des caméras IP ; ça a aidé, mais ça n’a pas magiquement rendu la sécurité des caméras bonne.
• « Air-gapped » est plus ancien que l’IT moderne ; c’est un concept des environnements classifiés. En entreprise, cela signifie généralement « connecté au Wi‑Fi parfois ».
• WPA2-Enterprise est arrivé au milieu des années 2000 et a rendu l’authentification Wi‑Fi par utilisateur pratique ; il reste sous-utilisé dans les entrepôts.
• WireGuard est nouveau comparé à IPsec/OpenVPN (conçu au milieu des années 2010), avec une base de code plus petite et des valeurs par défaut sensées.

Il y a un thème : les standards sont mûrs. Les échecs sont généralement humains, organisationnels, ou dus à un « on a précipité les achats ».

Un design de référence qui fonctionne dans de vrais bâtiments

Sites et rôles

Supposons deux sites physiques : Bureau et Entrepôt. Vous pouvez aussi avoir des utilisateurs distants (IT/admin) et peut-être un prestataire de sécurité géré
qui a besoin d’un accès limité aux caméras/NVR.

À chaque site, vous voulez :

• Un routeur/pare-feu (peut être un pare-feu dédié, ou un routeur avec fonctions de pare-feu).
• Un switch manageable capable de VLANs et de trunks ; idéalement avec PoE pour caméras/APs.
• Des points d’accès sans fil qui supportent plusieurs SSID mappés sur des VLANs (guest vs corp vs scanners).

Pattern de segmentation : « refuser par défaut, autoriser par service »

Créez des VLANs séparés par zone de confiance. L’ensemble minimal viable habituel :

• Corp : postes utilisateurs, portables, postes fixes.
• Servers : AD/DNS/NVR/ERP, ce que votre organisation appelle « critique ».
• Caméras : caméras IP et contrôleurs de portes associés.
• Warehouse/OT : scanners, imprimantes d’étiquettes, terminaux portables, équipements proches des PLC.
• Guest : accès internet uniquement. Pas d’accès interne.
• Management : interfaces de gestion des switches/AP, hors bande si possible.

Puis appliquez le contrôle d’accès inter-VLAN sur votre pare-feu/routeur. Si votre switch L3 peut router, parfait — mais centralisez quand même la politique
si vous tenez à l’auditabilité. « ACL distribuées partout » est la façon dont on se retrouve avec des connaissances tribales et une personne qui ne peut pas partir en vacances.

Où placer le VPN

Placez un VPN site-à-site entre les pare-feux/routeurs de bordure du Bureau et de l’Entrepôt. Routez uniquement les sous-réseaux nécessaires.
Si vous êtes tenté de router 0.0.0.0/0 à travers le tunnel pour la « simplicité », stoppez. Ce n’est pas de la simplicité, c’est reporter la complexité jusqu’à l’incendie.

Le VPN d’accès distant pour les humains doit terminer au bureau (ou à un hub central) puis être soumis à la même politique :
les utilisateurs atterrissent dans un sous-réseau/VLAN VPN dédié, puis sont autorisés à atteindre des services spécifiques.

Blague #1 : si votre VLAN caméras peut atteindre le VLAN comptabilité, félicitations — vous avez inventé une façon coûteuse de stocker vidéos et ransomware au même endroit.

Plan d’adressage et carte des VLAN que vous n’honorerez pas plus tard

Les bons plans d’adressage sont ennuyeux. L’ennui est fiable. Choisissez un bloc RFC1918 et subdivisez-le de façon cohérente par site.
Un schéma qui évolue sans complications :

• Bureau : 10.10.0.0/16
• Entrepôt : 10.20.0.0/16

À l’intérieur de chaque site, utilisez des /24 par VLAN :

• VLAN 10 Corp : 10.10.10.0/24 (Bureau), 10.20.10.0/24 (Entrepôt)
• VLAN 20 Servers : 10.10.20.0/24, 10.20.20.0/24
• VLAN 30 Caméras : 10.10.30.0/24, 10.20.30.0/24
• VLAN 40 Warehouse/OT : 10.10.40.0/24 (peut-être inutilisé), 10.20.40.0/24
• VLAN 50 Guest : 10.10.50.0/24, 10.20.50.0/24
• VLAN 99 Management : 10.10.99.0/24, 10.20.99.0/24

Pourquoi ce schéma fonctionne

Les humains déboguent les réseaux. Ils ne « les optimisent » pas. Avec un adressage prévisible, vous pouvez jeter un œil à une IP et connaître
le site + la zone de confiance. Ça compte quand vous regardez des logs la nuit.

Placement DNS et DHCP

Placez DNS authoritative et DHCP dans le VLAN serveurs (ou un VLAN infra dédié). Utilisez le relais DHCP (IP helper) sur les interfaces VLAN
si vous centralisez DHCP. Les caméras détestent souvent les options DHCP sophistiquées ; gardez-le minimal sauf si vous connaissez les bizarreries du modèle.

Les IPs statiques pour les caméras et l’infrastructure valent généralement le coup. Si vous faites des réservations DHCP à la place, exportez/sauvegardez-les.
« On se souviendra des IPs » est un mythe raconté aux administrateurs juniors comme le Père Noël.

Politique de pare-feu : qui parle à qui (et pourquoi)

Règles de base (opinionnées)

• Guest → tout interne : refuser. Toujours. Aucune exception.
• Caméras → internet : refuser par défaut. Autoriser NTP vers votre propre NTP, et éventuellement des points de mise à jour du fournisseur seulement si vous ne pouvez pas faire d’updates hors-ligne.
• Caméras → NVR : autoriser seulement les ports requis (souvent RTSP, ONVIF, spécifiques au fournisseur). Préférez les flux initiés par la caméra vers le NVR si possible.
• Corp → Caméras : généralement refuser. Si les utilisateurs ont besoin d’une vue en direct, passez par l’application web du NVR/VMS, pas un accès direct aux caméras.
• Warehouse/OT → Servers : autoriser seulement les ports applicatifs requis (ERP, impression, services scanners). Pas de « any/any parce que ce sont des scanners ».
• VLAN Management : seuls le sous-réseau VPN IT et un petit ensemble de postes admin devraient y accéder (SSH/HTTPS/SNMP).

Entre sites (via VPN)

Vous n’avez pas besoin d’« confiance totale site-à-site ». Vous avez besoin de services spécifiques :

• Scanners d’entrepôt vers serveurs applicatifs ERP du Bureau
• NVR d’entrepôt vers stockage bureau (si vous centralisez les vidéos)
• Admins IT pour gérer switches/APs/pare-feux de l’entrepôt

Routez et autorisez seulement ces sous-réseaux/ports. Si vous avez besoin de plus, ajoutez-le intentionnellement. Chaque règle doit avoir un propriétaire et une raison.

Journalisation : quoi logger sans se noyer

Journalisez les refus entre VLANs pendant un moment après le déploiement ; c’est comme ça que vous découvrez le service oublié.
Mais ne journalisez pas chaque autorisation. Vous paierez pour du disque et n’apprendrez rien.
Loggez :

• Tentatives refusées des Caméras/Guest vers des ressources internes
• Nouvelles destinations sortantes depuis le VLAN caméras (devrait être rare)
• Événements tunnel VPN up/down
• Refus inter-VLAN affectant des applis critiques (Warehouse/OT → Servers)

Topologies VPN : hub-and-spoke, full mesh, et « s’il vous plaît, non »

Hub-and-spoke (recommandé pour la plupart des organisations)

Le Bureau est le hub ; l’entrepôt est un spoke. Les utilisateurs d’accès distant terminent au hub.
Avantages : un endroit pour gérer la politique, moins de tunnels, dépannage plus simple.
Inconvénients : traffic hairpin si l’entrepôt doit atteindre un troisième site ; la bande passante du hub devient critique.

Full mesh (uniquement si vous avez plusieurs entrepôts et une forte automatisation)

Le mesh est viable quand vous avez une gestion de configuration solide et du monitoring. Si vous le faites à la main dans une GUI web,
vous construisez une future panne.

Extension L2 sur VPN (à éviter)

Étendre des VLANs entre sites fait traverser les domaines de broadcast et de panne à travers les bâtiments. STP ne devient pas polie magiquement à travers un tunnel.
Si vous essayez de faire « un grand LAN », reculez et demandez-vous quelle exigence vous résolvez vraiment — généralement une découverte legacy ou un fournisseur qui ne sait pas router.

WireGuard vs IPsec (compromis pratiques)

WireGuard est propre et rapide, avec moins de réglages à mal configurer. IPsec est omniprésent et souvent accéléré matériellement, mais la configuration varie fortement selon les fournisseurs.
L’un ou l’autre peut être fiable. La fiabilité vient de : routage cohérent, sanity MTU, et politique de pare-feu disciplinée.

Caméras et NVR : arrêtez de les traiter comme des imprimantes

Modèle de menace, en langage clair

Les caméras sont des ordinateurs avec des lentilles. Beaucoup sont livrées avec des configurations par défaut faibles, des bugs firmware persistants, et une surprenante quantité d’« appels sortants ».
Votre but n’est pas de rendre les caméras parfaites. Votre but est de rendre la compromission d’une caméra banale : isolée, journalisée, et incapable de pivoter.

Bonnes pratiques qui fonctionnent réellement

• Pas d’accès entrant direct depuis Internet vers les caméras ou le NVR. Si vous avez besoin de visualisation distante, utilisez un VPN ou un relais durci.
• Bloquez l’egress du VLAN caméras sauf NTP/DNS vers des résolveurs internes et tout autre service explicitement approuvé.
• Utilisez un NVR/VMS dans le VLAN serveurs ou un VLAN sécurité dédié, pas à l’intérieur du VLAN caméras comme une piñata.
• Désactivez UPnP partout. Surtout à la périphérie. UPnP est la façon dont les appareils négocient une « exposition surprise ».
• La synchronisation temporelle compte : si les logs et les timestamps vidéo dérivent, les enquêtes deviennent de la fiction.

Blague #2 : UPnP, c’est comme donner à votre grille-pain une clé maîtresse du bâtiment parce qu’il a promis de « gérer les ports de façon responsable ».

Planification de la bande passante pour la vidéo

Les caméras sont des gouffres de bande passante en état stable. Faites les calculs. Quelques caméras 4K à bitrate élevé peuvent saturer des uplinks et du Wi‑Fi.
Gardez le trafic caméra local au site quand c’est possible (caméras d’entrepôt vers NVR d’entrepôt). Si vous devez centraliser les vidéos,
envisagez une réplication planifiée ou des sous-flux à bitrate réduit sur le WAN.

Multicast et pièges de découverte

Certaines implantations de caméras reposent sur la découverte multicast. Le multicast ne traverse pas automatiquement les VLANs.
Évitez les designs qui exigent « autorisons le multicast partout ». Définissez plutôt où la découverte est nécessaire (souvent uniquement lors du provisioning),
puis verrouillez. Si le fournisseur exige une proximité L2 pour un fonctionnement permanent, considérez cela comme un risque produit, pas un « problème réseau ».

Tâches pratiques : commandes, sorties et décisions (12+)

Les tâches suivantes supposent que vous avez des machines Linux sur chaque site (ou sur le pare-feu si celui-ci est basé sur Linux), plus des switches manageables et un pare-feu.
Les commandes sont volontairement génériques et portables. Le but est opérationnel : ce que vous exécutez, ce à quoi vous vous attendez, et ce que vous décidez.

Task 1: Confirm VLAN interfaces exist and are up

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
eth0             UP             52:54:00:aa:bb:cc
eth0.10          UP             52:54:00:aa:bb:cc
eth0.30          UP             52:54:00:aa:bb:cc
eth0.99          DOWN           52:54:00:aa:bb:cc

Sens : les sous-interfaces VLAN existent ; le VLAN 99 est down.
Décision : si VLAN 99 est management et devrait être actif, remontez-le et vérifiez que le trunk du switch autorise VLAN 99.
S’il est inutilisé, supprimez-le pour réduire la confusion.

Task 2: Verify IP addressing on each VLAN interface

cr0x@server:~$ ip -br addr show
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             203.0.113.10/24
eth0.10          UP             10.10.10.1/24
eth0.30          UP             10.10.30.1/24

Sens : le routeur a des IP de gateway pour VLAN 10 et 30.
Décision : assurez-vous que chaque VLAN a exactement une gateway ; si vous voyez plusieurs devices annonçant des gateways (VRRP mis à part), vous invitez le routage asymétrique.

Task 3: Check routing table for expected site subnets and VPN routes

cr0x@server:~$ ip route
default via 203.0.113.1 dev eth0
10.10.10.0/24 dev eth0.10 proto kernel scope link src 10.10.10.1
10.10.30.0/24 dev eth0.30 proto kernel scope link src 10.10.30.1
10.20.40.0/24 via 10.255.0.2 dev wg0
10.20.30.0/24 via 10.255.0.2 dev wg0

Sens : les VLANs 30/40 de l’entrepôt sont atteignables via wg0.
Décision : si vous voyez des routes trop larges (comme 10.20.0.0/16) alors que vous vouliez seulement accès caméra/NVR, resserrez AllowedIPs / selectors phase2 et la politique de pare-feu.

Task 4: Validate WireGuard tunnel state and last handshake

cr0x@server:~$ sudo wg show
interface: wg0
  public key: rJc...redacted
  listening port: 51820

peer: 9hS...redacted
  endpoint: 198.51.100.20:51820
  allowed ips: 10.20.30.0/24, 10.20.40.0/24, 10.255.0.2/32
  latest handshake: 32 seconds ago
  transfer: 1.23 GiB received, 2.01 GiB sent

Sens : le tunnel est vivant ; du trafic circule.
Décision : si le handshake est ancien et que les compteurs de transfert ne bougent pas, suspectez NAT/forwarding de ports, blocage UDP par le pare-feu, ou clés non appariées.

Task 5: Spot MTU trouble with a controlled ping

cr0x@server:~$ ping -M do -s 1420 10.20.30.10 -c 3
PING 10.20.30.10 (10.20.30.10) 1420(1448) bytes of data.
1428 bytes from 10.20.30.10: icmp_seq=1 ttl=63 time=18.2 ms
1428 bytes from 10.20.30.10: icmp_seq=2 ttl=63 time=18.5 ms
1428 bytes from 10.20.30.10: icmp_seq=3 ttl=63 time=18.4 ms

--- 10.20.30.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms

Sens : une payload de 1420 octets fonctionne ; le MTU est probablement correct pour l’overhead typique de WireGuard.
Décision : si ceci échoue mais que des tailles plus petites réussissent, réduisez le MTU sur wg0 (ou sur l’interface WAN) et retestez les flux vidéo.

Task 6: Confirm DHCP leases for a VLAN (and detect rogue DHCP)

cr0x@server:~$ sudo journalctl -u isc-dhcp-server -n 10 --no-pager
dhcpd[1123]: DHCPDISCOVER from 3c:84:6a:11:22:33 via eth0.30
dhcpd[1123]: DHCPOFFER on 10.10.30.51 to 3c:84:6a:11:22:33 via eth0.30
dhcpd[1123]: DHCPREQUEST for 10.10.30.51 from 3c:84:6a:11:22:33 via eth0.30
dhcpd[1123]: DHCPACK on 10.10.30.51 to 3c:84:6a:11:22:33 via eth0.30

Sens : le serveur DHCP répond sur le VLAN caméras.
Décision : si les clients ont des adresses bizarres et que vous ne voyez pas de logs, suspectez un DHCP rogue sur ce VLAN ; activez DHCP snooping sur les switches ou verrouillez les ports sur les MAC caméras.

Task 7: Verify inter-VLAN firewall policy with counters

cr0x@server:~$ sudo nft list ruleset | sed -n '1,80p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "eth0.30" oifname "eth0.20" tcp dport { 554, 8000 } accept
    iifname "eth0.10" oifname "eth0.30" drop
    iifname "eth0.50" drop
  }
}

Sens : drop par défaut ; les caméras peuvent atteindre les serveurs sur les ports RTSP/fournisseur ; corp→caméras est bloqué ; guest est bloqué.
Décision : si la vidéo n’enregistre pas, confirmez que l’autorisation est dans la bonne direction (camera→NVR ou NVR→camera) selon votre architecture.

Task 8: Trace a packet path across VLAN and VPN

cr0x@server:~$ traceroute -n 10.20.30.10
traceroute to 10.20.30.10 (10.20.30.10), 30 hops max, 60 byte packets
 1  10.10.30.1  0.401 ms  0.322 ms  0.310 ms
 2  10.255.0.2  17.901 ms  17.872 ms  17.841 ms
 3  10.20.30.10  18.309 ms  18.292 ms  18.266 ms

Sens : le saut 2 est le pair WireGuard distant ; le routage est sain.
Décision : si vous le voyez aller vers la gateway par défaut internet, il vous manque des routes ou des AllowedIPs ; corrigez le routage avant d’accuser la caméra.

Task 9: Validate DNS behavior from a restricted VLAN

cr0x@server:~$ dig @10.10.20.53 nvr.office.local +short
10.10.20.20

Sens : le DNS interne résout le nom NVR.
Décision : si les caméras/NVR reposent sur des noms et que le DNS échoue entre VLANs, autorisez DNS depuis ce VLAN vers votre résolveur — ou arrêtez d’utiliser des hostnames pour les caméras et mettez des IPs statiques.

Task 10: Check for L2 loop symptoms (broadcast storms) via interface stats

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    987654321 1234567      0   12345       0  987654
    TX:  bytes packets errors dropped carrier collsns
    876543210 1122334      0       0       0       0

Sens : multicast/broadcast élevé (mcast) et drops peuvent indiquer une boucle ou des devices bruyants.
Décision : vérifiez l’état STP sur les switches, trouvez le port en boucle, et coupez-le. Si les drops sont sur le WAN, vous saturerez peut-être l’uplink avec la vidéo.

Task 11: Capture traffic on the camera VLAN to confirm who initiates RTSP

cr0x@server:~$ sudo tcpdump -ni eth0.30 host 10.10.20.20 and port 554 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
IP 10.10.30.51.49210 > 10.10.20.20.554: Flags [S], seq 120033, win 64240, options [mss 1460,sackOK,TS val 1200 ecr 0,nop,wscale 7], length 0
IP 10.10.20.20.554 > 10.10.30.51.49210: Flags [S.], seq 99321, ack 120034, win 65160, options [mss 1460,sackOK,TS val 2200 ecr 1200,nop,wscale 7], length 0

Sens : la caméra initie une connexion vers le NVR sur 554 ; votre règle de pare-feu devrait autoriser camera→NVR.
Décision : si vous voyez l’inverse (NVR initier), ajustez la direction du pare-feu en conséquence.

Task 12: Confirm NAT is not accidentally applied to inter-site traffic

cr0x@server:~$ sudo nft list table ip nat
table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oifname "eth0" masquerade
  }
}

Sens : masquerade s’applique uniquement sur l’interface WAN eth0, ce qui est correct.
Décision : si NAT s’applique à wg0 ou aux VLANs internes, vous casserez la politique basée sur les adresses et créerez un trafic unilatéral bizarre. Corrigez le périmètre NAT.

Task 13: Check if a camera is trying to reach the internet

cr0x@server:~$ sudo nft add rule inet filter forward iifname "eth0.30" oifname "eth0" log prefix "CAMERA-EGRESS " drop
cr0x@server:~$ sudo journalctl -k -n 5 --no-pager
kernel: CAMERA-EGRESS IN=eth0.30 OUT=eth0 SRC=10.10.30.51 DST=93.184.216.34 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=2244 DF PROTO=TCP SPT=51233 DPT=80 WINDOW=64240 SYN

Sens : la caméra a tenté une connexion HTTP sortante vers une IP publique.
Décision : laissez cette règle de drop (sans log une fois satisfait), puis décidez si la caméra a besoin d’un egress contrôlé pour les mises à jour — préférez les mises à jour manuelles.

Task 14: Validate switch trunk tagging from the Linux side (VLAN sees traffic)

cr0x@server:~$ sudo tcpdump -eni eth0 vlan 30 -c 3
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
02:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 30, p 0, ethertype ARP (0x0806), Request who-has 10.10.30.1 tell 10.10.30.51, length 46

Sens : les tags VLAN 30 sont présents ; le trunk fonctionne au moins pour ce VLAN.
Décision : si vous ne voyez pas de tags pour les VLANs attendus, corrigez le mode du port switch (trunk vs access) et la liste des VLAN autorisés.

Mode opératoire de diagnostic rapide

Quand quelque chose casse, vous n’avez pas besoin d’un génie. Vous avez besoin d’ordre. Voici la séquence qui trouve rapidement le goulot d’étranglement.

Première étape : est-ce local, inter-VLAN, ou via le VPN ?

• Depuis un hôte dans le même VLAN, pinguez l’IP cible. Si ça échoue, c’est local (commutation, DHCP, device down).
• Depuis un hôte dans un VLAN différent au même site, pinguez d’abord la gateway puis la cible. Si la gateway répond mais pas la cible, c’est pare-feu/routage/politique.
• Depuis le bureau vers l’entrepôt (ou inversement), pinguez via le VPN. Si le local marche mais le cross-site échoue, concentrez-vous sur VPN/routage/MTU.

Deuxième étape : confirmez routage et politique avant de regarder les paquets

• Vérifiez les tables de routage sur les routeurs (local et distant). Une route manquante bat presque toujours le « bug mystère ».
• Vérifiez les compteurs/logs du pare-feu pour des refus. Si vous ne journalisez pas les refus lors du déploiement, vous déboguez à l’aveugle.
• Confirmez que le NAT n’est pas appliqué au trafic interne/VPN.

Troisième étape : validez MTU et fragmentation sur le VPN

• Utilisez des pings PMTU avec -M do et ajustez le MTU sur les interfaces tunnel si nécessaire.
• Les flux vidéo qui échouent alors que les pings fonctionnent sont un symptôme classique de MTU : les petits paquets passent ; les gros sont mis en tombeau noir.

Quatrième étape : capturez le trafic seulement ensuite

• Capturez sur l’interface VLAN et sur l’interface tunnel. Si vous le voyez sur le VLAN mais pas sur le tunnel, le routage/la politique le bloque.
• Si vous le voyez sur le tunnel mais pas à destination, c’est la politique/le routage côté distant — ou la destination ment sur son état.

Cinquième étape : vérifiez que « ce n’est pas le réseau qui n’est pas le réseau »

• CPU caméra saturé, stockage NVR plein, ou DNS cassé peuvent ressembler à des problèmes réseau.
• Confirmez toujours la santé des services : le port RTSP est-il ouvert, le NVR enregistre-t-il, l’heure est-elle correcte ?

Erreurs courantes : symptôme → cause racine → correction

1) « Les caméras se déconnectent aléatoirement »

Symptôme : perte intermittente des caméras, surtout quand l’entrepôt est chargé.

Cause racine : saturation de l’uplink ou bufferbloat ; vidéo + trafic scanner se battent sur le même lien/queue.

Correction : gardez la vidéo locale au site ; appliquez du QoS pour le trafic OT/scanner ; upgradez les uplinks ; limitez les bitrates caméra ; évitez le Wi‑Fi pour des caméras fixes.

2) « Le VPN est up mais rien ne route »

Symptôme : handshake du tunnel OK, mais sous-réseaux injoignables.

Cause racine : routes manquantes, AllowedIPs/phase2 selectors incorrects, ou routage asymétrique.

Correction : assurez-vous que les deux côtés ont des routes vers les sous-réseaux VLAN de l’autre via le tunnel ; vérifiez que le pare-feu autorise le forward entre wg0 et les interfaces VLAN.

3) « Tout fonctionne sauf l’interface web du NVR à distance »

Symptôme : le ping fonctionne, mais HTTPS/HTTP time-out ou chargement partiel.

Cause racine : trou noir MTU sur le VPN ou absence de MSS clamping.

Correction : réduisez le MTU du tunnel ; activez MSS clamping sur le pare-feu ; retestez avec un ping à grosse payload et avec un navigateur réel.

4) « Le Wi‑Fi invité voit des imprimantes/serveurs »

Symptôme : les utilisateurs guest atteignent des IP internes.

Cause racine : SSID guest ponté au VLAN corp, ou ordre des règles du pare-feu le permet.

Correction : mappez le SSID guest au VLAN guest ; appliquez un refus au gateway ; vérifiez le tagging des trunks des AP et la config des switchports.

5) « Une nouvelle installation de caméras casse la moitié du réseau »

Symptôme : tempête de broadcast soudaine, CPU élevé sur les switches, perte de paquets partout.

Cause racine : boucle introduite (deux ports patchés ensemble), ou un switch bon marché faisant des choses créatives.

Correction : activez STP (et BPDU guard sur les ports d’accès) ; coupez les ports qui flap ; interdisez les switches non gérés sur les runs caméras sauf approbation explicite.

6) « Les scanners d’entrepôt sont lents après la segmentation »

Symptôme : latences applicatives sur les scanners après leur migration vers VLAN OT.

Cause racine : DNS inaccessible, ports vers les serveurs applicatifs bloqués, ou dépendance à une découverte broadcast qui ne traverse pas les VLANs.

Correction : autorisez explicitement DNS/NTP et les ports applicatifs requis ; remplacez la découverte broadcast par des enregistrements DNS ou un petit service helper ; documentez les dépendances.

7) « On ne peut plus mettre à jour le firmware des caméras »

Symptôme : les mises à jour firmware échouent après avoir bloqué l’accès Internet des caméras.

Cause racine : les updates nécessitent des endpoints cloud ou le VMS agit comme proxy que vous avez accidentellement bloqué.

Correction : mettez à jour via le NVR/VMS si supporté ; autorisez temporairement l’egress vers des destinations spécifiques pendant des fenêtres de maintenance ; loggez et retirez la règle ensuite.

Trois mini-récits d’entreprise tirés du terrain

Incident causé par une mauvaise hypothèse : « Le VPN est chiffré, donc c’est sûr »

Une entreprise de taille moyenne a ajouté un entrepôt et a déployé un VPN site-à-site. Le plan était simple : « connecter les réseaux ».
Ils ont routé le /16 complet du bureau vers l’entrepôt et vice versa. Aucun changement de segmentation. Aucun filtrage significatif. Le VPN était considéré comme la frontière de sécurité.

Ça a bien marché jusqu’à ce qu’un PC d’entrepôt — utilisé pour imprimer des étiquettes et occasionnellement « lire des e‑mails » — attrape un infostealer ordinaire.
Le malware a fait ce que font les malwares : il a scanné le réseau, trouvé des partages et un vieux RDP, et est allé droit dans l’environnement du bureau.
Le VPN n’a pas causé la brèche ; il a supprimé les frictions.

La partie la plus douloureuse n’était pas la remédiation. C’était la réunion post-incident où tout le monde a réalisé qu’ils avaient traité le « transport chiffré »
comme de la « segmentation ». Ce sont deux problèmes différents. Le chiffrement protège les paquets de l’écoute ; il n’empêche pas un hôte compromis d’être indiscret.

Le correctif fut peu glamour : scinder l’entrepôt en VLAN OT, caméras et admin ; verrouiller les flux inter-VLAN ; restreindre le VPN aux seuls sous-réseaux nécessaires ;
et forcer l’administration distante via un subnet VPN dédié avec MFA. Rien de fancy. Juste des frontières qui reflètent l’intention.

Optimisation qui s’est retournée : « Centralisons tout l’enregistrement caméra sur le WAN »

Une autre organisation voulait une « vue unique » pour la vidéo. Ils ont placé le NVR/VMS dans la salle serveur du bureau et ont streamé toutes les caméras d’entrepôt via le VPN.
Sur le papier : gestion plus simple, un stockage, un plan de sauvegarde.

En pratique : le lien WAN est devenu le chemin critique pour la sécurité physique. Quand l’entrepôt était occupé, les flux caméra se dégradaient.
Quand l’ISP a eu une défaillance, l’enregistrement de l’entrepôt a été perdu. Personne n’était content, y compris l’équipe sécurité à qui on avait promis « plus de fiabilité ».

Ils ont tenté d’« optimiser » en augmentant la compression VPN et en bricolant les chiffrements. Le CPU a monté, la latence a empiré, et la vidéo n’a pas progressé.
Ils heurtaient le tunnel alors que la vraie contrainte était physique : la bande passante et le queueing sur l’uplink.

La solution finale fut prévisible : un enregistreur local en entrepôt avec rétention locale, plus une réplication planifiée des événements de mouvement et des sous-flux basse résolution vers le bureau.
La vue centralisée est restée possible, mais n’était plus un point de défaillance unique. Le WAN est devenu un amplificateur, pas une exigence.

Pratique ennuyeuse mais correcte qui a sauvé la mise : « Documenter les VLANs et tester vraiment »

Un distributeur retail avait un bureau, deux entrepôts, et un prestataire sécurité qui avait besoin d’accéder occasionnellement aux vues caméra.
Leur lead réseau a exigé une matrice écrite : VLANs, subnets, gateways, scopes DHCP, et un tableau simple des flux autorisés.
Personne n’était emballé. Ça ressemblait à de la bureaucratie avec des étapes en plus.

Des mois plus tard, un switch de l’Entrepôt A est tombé et a dû être remplacé rapidement. Un prestataire a installé le remplaçant et — parce que les prestataires sont humains —
a mal taggé le trunk : les caméras ont atterri dans le VLAN corp. Tout « fonctionnait », mais c’était incorrect.

La raison pour laquelle ça a été détecté vite : la matrice de flux documentée et un script de validation de base que l’équipe lançait après tout changement.
Le script vérifiait que les devices du VLAN caméras ne pouvaient pas atteindre Internet et que le VLAN corp ne pouvait pas toucher les IP caméras directement.
Le test a échoué immédiatement. Ils ont corrigé la config du trunk avant que les images de sécurité ne deviennent silencieusement un canal d’exfiltration non surveillé.

La leçon n’était pas « les prestataires sont mauvais ». La leçon est que des contrôles ennuyeux — documentation, tests répétables, et politique default-deny — transforment les erreurs en alertes,
pas en incidents.

Listes de contrôle / plan étape par étape

Phase 1 : Décisions de conception (faites ceci avant de toucher aux câbles)

1. Définir les zones de confiance : Corp, Servers, Cameras, Warehouse/OT, Guest, Management.
2. Choisir un plan d’adressage cohérent par site (ex. 10.10/16 bureau, 10.20/16 entrepôt) et /24 par VLAN.
3. Décider où place le NVR/VMS (préférez l’enregistrement local par site ; la vue centrale est optionnelle).
4. Décider du modèle VPN : hub-and-spoke sauf fortes raisons contraires.
5. Rédiger une matrice allowlist : quel VLAN peut atteindre quel service (ports) et dans quelle direction.

Phase 2 : Build switching (L2)

1. Créer les VLANs sur les switches ; nommez-les clairement (CAMERAS, GUEST, MGMT).
2. Configurer les trunks entre switch et pare-feu/routeur ; n’autorisez que les VLANs nécessaires.
3. Configurer les ports access : caméras en access VLAN 30, scanners en VLAN 40, etc.
4. Activer STP et BPDU guard sur les ports edge pour réduire le rayon d’explosion en cas de boucle.
5. Si supporté, activer DHCP snooping et dynamic ARP inspection sur les VLANs utilisateur/caméras.

Phase 3 : Build routage + firewalling (L3)

1. Assigner des IP de gateway aux interfaces VLAN sur le pare-feu/routeur.
2. Définir la politique forward par défaut à deny.
3. Ajouter des autorisations explicites :
   • Caméras → ports NVR
   • Corp → applis serveurs (ERP, mail, fichiers)
   • Warehouse/OT → applis serveurs spécifiques + impression
   • Utilisateurs VPN → interfaces management (limité)
4. Bloquer l’egress du VLAN caméras vers Internet ; autoriser NTP/DNS vers services internes.
5. Activer la journalisation sur les refus entre VLANs pendant le déploiement.

Phase 4 : Intégration VPN

1. Mettre en place le tunnel site-à-site entre les pare-feux des sites.
2. Router seulement les sous-réseaux requis via le VPN.
3. Confirmer le MTU avec des pings do-not-fragment ; régler MTU/MSS clamp du tunnel si besoin.
4. Tester les flux critiques métier : scanners → ERP, NVR ↔ caméras, IT → VLAN management.

Phase 5 : Hygiène opérationnelle (la partie qui le maintient)

1. Sauvegarder les configurations pare-feu et switch après changements.
2. Garder une carte IP/VLAN en contrôle de version (même si c’est juste un fichier texte).
3. Surveiller la santé des tunnels VPN et les erreurs/drops d’interfaces.
4. Faire un contrôle d’accès trimestriel : retirer règles, prestataires et exceptions obsolètes.
5. Patch des caméras/NVR sur un calendrier ; rotation des identifiants ; désactiver les services inutilisés.

FAQ

1) Ai-je vraiment besoin d’un VLAN séparé pour les caméras ?

Oui. Les caméras présentent un risque élevé et consomment beaucoup de bande passante. Un VLAN caméra dédié réduit le risque de mouvement latéral et rend les contrôles de bande passante réalisables.
Placez le NVR/VMS derrière une frontière pare-feu, pas dans la même zone de confiance que tout le reste.

2) Puis-je simplement mettre les caméras sur le réseau invité ?

Non. Les réseaux invités sont généralement internet-only et pas conçus pour des services internes stables. De plus, vous ne voulez pas que les caméras communiquent vers Internet.
Les caméras appartiennent à un VLAN interne restreint avec accès explicite au NVR et aux services de temps/DNS.

3) Dois-je router entre VLANs sur un switch L3 ou sur le pare-feu ?

Si vous avez besoin d’un fort débit est-ouest et d’une politique simple, le L3 switching convient. Si vous voulez une politique de sécurité centralisée et auditable,
faites le routage sur le pare-feu. Beaucoup d’organisations font les deux : switch L3 pour le routage cœur, pare-feu pour la politique inter-zone via VRF ou VLAN transit.
Si vous êtes petit à moyen, le routage inter-VLAN sur le pare-feu est généralement le plus simple à opérer.

4) WireGuard est-il « plus sûr » qu’IPsec ?

La sécurité dépend davantage de la configuration et de la gestion des clés que du nom. La base de code plus petite et les valeurs par défaut modernes de WireGuard réduisent les risques d’erreurs.
IPsec est éprouvé et largement supporté. Choisissez celui que vous pouvez exploiter de façon cohérente et surveiller correctement.

5) Dois-je chiffrer le trafic à l’intérieur du LAN si j’ai déjà des VLANs ?

Les VLAN ne chiffrent pas ; ils séparent les domaines de broadcast. Si vous avez du trafic sensible (identifiants, accès vidéo), utilisez TLS/HTTPS et des protocoles sécurisés.
Pour l’accès management, utilisez SSH/HTTPS et envisagez un subnet VPN management.

6) Pourquoi ne pas étendre le VLAN bureau à l’entrepôt pour que « tout fonctionne simplement » ?

Parce que cela fait voyager les pannes. Broadcasts, boucles et mauvaises configurations deviennent des pannes inter-sites. Les designs routés sont plus prévisibles,
plus faciles à sécuriser, et plus simples à dépanner. Si un fournisseur exige la proximité L2, challengez l’exigence ou isolez-la strictement.

7) Comment donner à un prestataire sécurité l’accès aux vues caméra sans lui donner les clés de tout ?

Terminez l’accès prestataire sur un profil/subnet VPN dédié. Autorisez ce subnet à atteindre seulement l’UI VMS/NVR (et éventuellement un jump host),
pas le VLAN caméras. Journalisez l’accès. Limitez sa durée si possible. Les prestataires n’ont pas besoin de tout votre réseau ; ils ont besoin d’une porte étroite.

8) Quel est le moyen le plus simple de garder les horodatages caméra corrects ?

Fournissez un NTP interne et autorisez le VLAN caméras à y accéder. Bloquez NTP Internet arbitraire. Si vous avez plusieurs sites,
synchronisez les sources NTP de site et gardez la configuration de fuseau horaire cohérente entre VMS et caméras.

9) Comment éviter les incidents « quelqu’un a branché un switch aléatoire dans l’entrepôt » ?

Utilisez port security (limites MAC), DHCP snooping, et BPDU guard sur les ports d’accès. Étiquetez les ports. Formez les équipes facilities.
Et acceptez que cela arrive encore — surveillez-le et faites-en un petit incident, pas un gros titre.

10) Et si j’ai besoin de voir les caméras d’entrepôt depuis le bureau ?

Préférez que les utilisateurs bureau se connectent à l’UI VMS/NVR d’entrepôt via le VPN, pas un accès direct aux caméras. Si la bande passante est un enjeu,
utilisez des sous-flux pour la visualisation en direct et conservez l’enregistrement plein-résolution localement.

Conclusion : prochaines étapes pratiques

Si vous voulez que bureau + entrepôt + caméras coexistent en sécurité, faites les choses ennuyeuses de façon intentionnelle :
segmentez avec des VLANs, appliquez l’intention avec une politique de pare-feu, et utilisez le VPN comme transport — pas comme une couverture magique de sécurité.
Gardez le trafic caméra local. Routez entre sites. Journalisez les refus pendant le déploiement. Réduisez vos zones de confiance jusqu’à ce qu’elles reflètent la réalité.

Prochaines étapes que vous pouvez exécuter cette semaine :

1. Rédigez votre plan VLAN/subnet (même une page) et réservez des IDs VLAN pour la croissance.
2. Créez un VLAN caméra et migrez deux caméras en pilote ; bloquez l’egress caméra vers Internet et confirmez que le NVR enregistre toujours.
3. Restreignez le VPN site-à-site aux seuls sous-réseaux requis ; supprimez tout raccourci « router tout ».
4. Exécutez le test MTU sur le VPN et corrigez les problèmes de fragmentation avant que les utilisateurs les découvrent via une vidéo cassée.
5. Activez la journalisation des refus entre zones pendant deux semaines, puis nettoyez les règles selon ce que vous apprenez.

Le but n’est pas la perfection. C’est un réseau où les pannes sont contenues, les changements prévisibles, et où les caméras n’ont pas d’opinion sur votre posture de sécurité.