VPN de bureau pour vidéosurveillance : accéder aux caméras et NVR sans IP publique

octobre 19, 2025 • février 3, 2026 • Lecture : 31 min • Views: 11

Cet article vous a aidé ?

Vous voulez afficher une caméra en direct depuis chez vous, ou donner à un responsable régional l’accès à un NVR, mais le site n’a pas d’IP publique, ne veut pas d’entrées de pare-feu entrantes et ne souhaite pas devenir le sujet d’un titre de presse demain. Classique.

La bonne nouvelle : c’est un problème que l’industrie a déjà résolu. La mauvaise nouvelle : des gens le réinventent sans cesse avec des clouds fournisseurs, des redirections de ports hasardeuses et des prières. Construisons la solution ennuyeuse et correcte : un VPN de bureau qui atteint proprement les dispositifs CCTV — sans les exposer à l’internet public.

Ce que vous construisez réellement (et ce que vous ne construisez pas)

« Accéder aux caméras/NVR sans IP publique » n’est pas une demande de fonctionnalité. C’est un problème de topologie, plus un problème d’authentification, plus un problème de « ne pas saturer la liaison montante ».

Ce que vous construisez est un réseau de superposition (VPN) qui fournit :

Accessibilité : une route stable depuis l’ordinateur d’un opérateur (ou le réseau du bureau) vers le VLAN des caméras/sous‑réseau NVR.
Identité : un moyen de savoir qui se connecte (et d’empêcher d’anciens employés de « juste vérifier une chose »).
Politique : des règles qui n’autorisent que les ports nécessaires et uniquement les destinations nécessaires.
Observabilité : journaux et métriques pour prouver que ça fonctionne et diagnostiquer rapidement quand ça ne fonctionne pas.

Ce que vous ne construisez pas :

Un portail web exposé publiquement qui redirige les ports d’interface des caméras vers le monde.
Un « transfert de port rapide » vers RTSP/HTTP parce que quelqu’un est pressé.
Une dépendance à un cloud fournisseur qui devient en silence votre périmètre.

Voici la vérité sans fioritures : la plupart des dispositifs CCTV ne sont pas défendables sur l’internet public. Même les meilleurs embarquent des services étranges, des OpenSSL obsolètes et du code d’interface qui fait faire des choses douteuses à votre navigateur. Donnez‑leur un espace privé, placez un videur à la porte, et assurez‑vous que le videur soit sobre.

Une petite blague, comme promis et rationnée : La façon la plus rapide de « sécuriser » une caméra est de la débrancher — aussi la façon la plus rapide de recevoir un appel des Services Généraux.

Faits intéressants et courte histoire qui comptent

Ce ne sont pas des anecdotes de quiz. Chacun de ces éléments oriente vos décisions de conception.

Le NAT était une solution temporaire : la traduction d’adresses réseau est devenue courante au milieu des années 1990 principalement parce que l’épuisement des adresses IPv4 était déjà visible. Les VPN ont grandi dans un monde où « pas d’IP publique » est devenu la norme, pas l’exception.
IPsec précède la plupart des caméras IP : IPsec a été standardisé à la fin des années 1990, bien avant l’explosion des déploiements CCTV grand public. Les outils sont matures, mais la complexité opérationnelle est réelle.
RTSP est plus ancien que la plupart des firmwares : RTSP (fin des années 1990) reste le protocole central pour de nombreux flux caméra. Il fonctionne ; il est aussi facile à fuiter si vous le routez mal.
UPnP a été conçu pour la commodité : il faisait que les réseaux domestiques « fonctionnent simplement » en ouvrant des trous dans le NAT. Dans les déploiements CCTV, UPnP est souvent la façon dont vous publiez accidentellement une interface d’administration NVR sur internet.
Les identifiants par défaut étaient la norme : les premiers appareils embarqués étaient livrés avec « admin/admin » comme norme culturelle. Beaucoup d’appareils modernes ont progressé, mais l’écosystème traîne encore cet héritage.
Les botnets adoraient les caméras : historiquement, de gros botnets recrutaient des DVR/NVR et des caméras parce qu’ils étaient joignables, non patchés et toujours allumés. Si votre méthode d’accès les rend joignables, vous les proposez volontairement.
Le « cloud P2P pour caméras » est essentiellement du NAT traversal : de nombreux fournisseurs reposent sur des connexions sortantes vers un service de rendez‑vous pour éviter les IP publiques. C’est astucieux, mais cela signifie aussi que votre périmètre inclut un tiers et son système de comptes.
WireGuard est intentionnellement minimal : il a été conçu pour réduire les pièges de configuration et la taille du code. Cela compte quand vous voulez des opérations fiables, pas une séance hebdomadaire « pourquoi le tunnel s’est arrêté ».
La plupart des incidents sont liés au routage, pas à la cryptographie : en production, la cryptographie VPN fonctionne généralement. Ce qui échoue, ce sont la propagation des routes, les chemins asymétriques, la confusion DNS et l’oubli qu’un VLAN caméra existe.

Conceptions de référence : en choisir une et s’y tenir

Vous avez trois schémas raisonnables. Choisissez en fonction de l’échelle, des frontières de confiance et de qui contrôle le point d’accès réseau à chaque site CCTV.

Design A : Accès distant hub-and-spoke (bureau ou cloud comme hub)

C’est la solution de travail. Chaque site établit un tunnel VPN sortant vers un hub (pare‑feu du bureau ou petit VM dans un VPC cloud). Les utilisateurs distants se connectent au hub, puis il y a routage vers les sites.

Avantages : Un point d’entrée public stable (le hub). Pas de règles entrantes sur les sites. Journalisation et politiques centralisées.

Inconvénients : Le hub devient une dépendance critique. Il faut prévoir sa capacité. Il faut appliquer le principe du moindre privilège pour qu’un seul utilisateur n’obtienne pas les clés de tous les sites.

Design B : VPN site-à-site entre le bureau et les sites caméra

IPsec ou WireGuard site-à-site classique. Les utilisateurs sont sur le réseau du bureau ; le bureau route vers les sous‑réseaux caméra via les tunnels.

Avantages : Plus propre quand toute la visualisation se fait depuis les réseaux corporatifs (SOC, équipe sécurité). Faible dispersion des clients.

Inconvénients : N’aide pas les individus distants à moins qu’ils ne passent d’abord par le VPN du bureau. Et oui, cela peut être acceptable — il faut juste l’admettre.

Design C : Accès de style zero‑trust (proxy d’identité vers l’UI NVR)

Vous exposez une interface interne (généralement l’application web du NVR) via un proxy conscient de l’identité. Les caméras restent privées ; le proxy applique SSO/MFA et la politique.

Avantages : Contrôles d’identité forts. Pas d’accès réseau large. Excellent historique d’audit.

Inconvénients : Plus difficile pour la visualisation RTSP brute, la découverte ONVIF ou les outils qui s’attendent à une reachabilité de type L2. Certaines applications NVR se comportent mal derrière des proxies.

Pour la plupart des entreprises de taille moyenne et des déploiements multi‑site (commerce/industrie), je recommande le Design A (hub-and-spoke) avec WireGuard, plus une politique stricte de pare‑feu entre les clients VPN et les VLAN caméras. C’est ennuyeux dans le meilleur sens du terme.

Modèle de sécurité : traiter les caméras comme des IoT hostiles

Supposez que chaque caméra/NVR :

exécute des paquets obsolètes,
livre trop de services ouverts,
journalise mal,
et effectue parfois du trafic « phone home » que vous n’avez pas demandé.

Donc votre objectif de conception n’est pas seulement « le rendre accessible ». C’est « le rendre accessible uniquement par des chemins contrôlés et seulement pour des utilisateurs approuvés ».

Règles strictes qui vous évitent des ennuis

Pas d’entrées directes depuis l’internet vers les sous‑réseaux CCTV. Si vous devez publier quelque chose, publiez un proxy authentifié, pas un port caméra.
Séparez le CCTV des terminaux corporatifs. Séparation VLAN/sous‑réseau avec règles de pare‑feu. Les caméras n’ont pas besoin de parler à la paie.
Ne tunnelisez pas tout le trafic vidéo sauf si c’est intentionnel. Quelques flux à 8 Mbps transformeront votre VPN en diaporama. Utilisez le split tunneling avec des routes explicites.
Verrouillez les ports de gestion. Autorisez RTSP seulement aux stations de visualisation, HTTPS seulement aux admins, bloquez SMB/Telnet/FTP (oui, ils apparaissent encore).
Rendez l’identité réelle. Clés/certificats par utilisateur, MFA sur le VPN ou le système d’identité en amont, et révocation rapide.
Journalisez au point d’étranglement. Le hub doit être l’endroit où vous pouvez répondre : qui a accédé à quel NVR, quand et d’où.

Une citation, utilisée avec parcimonie car les citations sont souvent un substitut à la réflexion : L’espoir n’est pas une stratégie. — James Cameron

Guide WireGuard : hub-and-spoke bien fait

WireGuard convient bien à l’accès CCTV parce qu’il est stable sous NAT, rapide et a une surface de configuration réduite. Il ne gère pas la gestion des utilisateurs pour vous ; vous aurez besoin d’un plan pour le cycle de vie des clés, le contrôle d’accès et l’audit.

Exemple de topologie réseau

Hub (IP publique) : 203.0.113.10, interface WireGuard wg0 avec sous‑réseau VPN 10.44.0.0/24
Site A (pas d’IP publique) : VLAN caméras 10.10.50.0/24, le routeur de site exécute le client WireGuard avec IP VPN 10.44.0.10
Utilisateur distant : client WireGuard sur portable avec IP VPN 10.44.0.101

Idée clé : le routeur de site établit un tunnel sortant vers le hub. L’utilisateur distant se connecte aussi au hub. Le hub route entre eux, mais uniquement comme autorisé par les règles de pare‑feu.

Routage : rendre les chemins explicites

Ne comptez pas sur le « ça marche à peu près ». Faites savoir au hub quel site possède quel sous‑réseau caméra.

Le hub a une route vers 10.10.50.0/24 via le peer 10.44.0.10
L’utilisateur distant reçoit (ou configure localement) une route vers 10.10.50.0/24 via wg0
Le routeur du site a une route de retour vers le sous‑réseau VPN 10.44.0.0/24 via WireGuard

Politique de pare‑feu : contraindre par destination et port

Au hub, traitez l’interface VPN comme un réseau non fiable. Parce qu’elle l’est. Autorisez seulement ce dont vous avez besoin :

HTTPS vers l’UI web du NVR (souvent 443 ou un port fournisseur)
RTSP vers NVR/caméras (554 ou port défini par le fournisseur)
ONVIF (souvent 80/8899/3702 UDP, varie fortement)

Bloquez tout le reste, en particulier les mouvements latéraux entre sites.

DNS : vos utilisateurs taperont des noms, pas des sous‑réseaux

Si vous voulez que « nvr-site-a.corp » se résolve via le VPN, vous avez besoin de DNS partagé ou d’un serveur DNS côté VPN. Ne piratez pas ça avec des enregistrements DNS publics pointant vers des IP privées, sauf si vous aimez embrouiller les portables dans les hôtels.

Identité et accès

WireGuard fonctionne par clés. C’est bien. Mais vous aurez encore besoin de :

Clés par utilisateur (pas de « security-team.conf » partagé)
Processus de rotation et de révocation des clés
MFA quelque part : soit au niveau d’une passerelle VPN en amont (si WireGuard est derrière un portail), soit en émettant des accès éphémères via un courtier d’identité/SSO. Si vous ne pouvez pas faire de MFA directement sur WireGuard, vous pouvez toujours appliquer le MFA sur le système qui distribue les configurations et contrôle qui les reçoit.

Deuxième petite blague, dernière : Une clé VPN partagée, c’est comme une brosse à dents partagée — techniquement ça fonctionne, mais vous allez le regretter.

Tâches pratiques avec commandes : vérifier, décider, réparer

Cette section est volontairement pratique. Chaque tâche inclut : une commande, un exemple de sortie, ce que cela signifie et la décision que vous en tirez. Tous les exemples supposent Linux sur le hub ; adaptez au besoin.

Tâche 1 : Confirmer que l’interface WireGuard est active et que les peers échangent des handshakes

cr0x@server:~$ sudo wg show
interface: wg0
  public key: 2qv...Zk=
  listening port: 51820

peer: 9mR...aQ=
  endpoint: 198.51.100.23:54321
  allowed ips: 10.44.0.10/32, 10.10.50.0/24
  latest handshake: 31 seconds ago
  transfer: 1.23 MiB received, 4.80 MiB sent

peer: Q1s...p8=
  endpoint: 203.0.113.77:61112
  allowed ips: 10.44.0.101/32
  latest handshake: 12 seconds ago
  transfer: 62.1 MiB received, 140.2 MiB sent

Sens : « latest handshake » vous indique la vivacité. S’il indique des minutes/heures, le tunnel est tombé ou inactif sans keepalive.

Décision : Si un site derrière NAT devient inactif, configurez PersistentKeepalive=25 sur ce peer (côté site). Si l’endpoint IP change fréquemment, confirmez le comportement du dispositif NAT.

Tâche 2 : Valider le forwarding IP du noyau sur le hub

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Sens : Si c’est 0, le hub ne routage pas le trafic entre peers VPN et sous‑réseaux de site.

Décision : Mettez‑le à 1 et persistez dans /etc/sysctl.conf ou un drop‑in.

Tâche 3 : Vérifier que la route vers le sous‑réseau caméra existe sur le hub

cr0x@server:~$ ip route show | grep 10.10.50.0
10.10.50.0/24 dev wg0 proto static scope link

Sens : Le hub croit que 10.10.50.0/24 est joignable via wg0. Si vous ne le voyez pas, vous n’avez probablement pas inclus ce sous‑réseau dans AllowedIPs du peer site sur le hub.

Décision : Ajoutez le sous‑réseau aux AllowedIPs du peer (dans la config du hub) pour que le hub sache où envoyer le trafic.

Tâche 4 : Confirmer que le pare‑feu du hub autorise le forwarding des clients VPN vers le sous‑réseau du site

cr0x@server:~$ sudo nft list ruleset | sed -n '1,140p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    iifname "wg0" oifname "wg0" ip saddr 10.44.0.0/24 ip daddr 10.10.50.0/24 tcp dport { 443, 554 } accept
    iifname "wg0" oifname "wg0" ct state established,related accept
    counter packets 12034 bytes 9440221 drop
  }
}

Sens : La politique est drop par défaut. Seuls TCP 443 et 554 vers le sous‑réseau caméra sont autorisés depuis les clients VPN.

Décision : Si les utilisateurs ont besoin de découverte ONVIF, vous devrez peut‑être autoriser des UDP spécifiques, mais ajoutez‑les intentionnellement et vérifiez l’impact.

Tâche 5 : Tester la connectivité vers un NVR depuis le hub (ICMP)

cr0x@server:~$ ping -c 3 10.10.50.20
PING 10.10.50.20 (10.10.50.20) 56(84) bytes of data.
64 bytes from 10.10.50.20: icmp_seq=1 ttl=63 time=32.1 ms
64 bytes from 10.10.50.20: icmp_seq=2 ttl=63 time=31.4 ms
64 bytes from 10.10.50.20: icmp_seq=3 ttl=63 time=31.8 ms

--- 10.10.50.20 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 31.4/31.8/32.1/0.3 ms

Sens : Le routage basique hub → site fonctionne. Si le ping échoue mais le TCP fonctionne, l’ICMP peut être bloqué côté site. Ce n’est pas automatiquement une erreur.

Décision : N’exigez pas le ping comme « indispensable ». Préférez des contrôles de service (HTTPS/RTSP) comme preuve réelle.

Tâche 6 : Vérifier les ports de service depuis le hub (HTTPS et RTSP)

cr0x@server:~$ nc -vz 10.10.50.20 443
Connection to 10.10.50.20 443 port [tcp/https] succeeded!
cr0x@server:~$ nc -vz 10.10.50.20 554
Connection to 10.10.50.20 554 port [tcp/rtsp] succeeded!

Sens : Les ports sont joignables. Si HTTPS réussit mais RTSP échoue, vous avez probablement oublié d’autoriser 554, ou le NVR stream sur un autre port.

Décision : Ajustez les règles de pare‑feu pour correspondre à l’usage réel du port fournisseur, et documentez‑le. « Ouvrir tous les ports » n’est pas de la documentation.

Tâche 7 : Vérifier que le routeur du site achemine réellement le trafic du VPN vers le VLAN caméra (depuis le hub)

cr0x@server:~$ traceroute -n 10.10.50.20
traceroute to 10.10.50.20 (10.10.50.20), 30 hops max, 60 byte packets
 1  10.44.0.10  29.817 ms  30.101 ms  30.229 ms
 2  10.10.50.20  31.212 ms  31.444 ms  31.389 ms

Sens : Le saut 1 est l’endpoint WireGuard du site (routeur), le saut 2 est le NVR. C’est le chemin attendu.

Décision : Si la trace s’arrête au saut 1, le routeur du site ne forwarde pas vers le VLAN ou a un pare‑feu qui le bloque. Réparez côté site, pas côté hub.

Tâche 8 : Valider le chemin inverse (le sous‑réseau site peut renvoyer vers les clients VPN)

cr0x@server:~$ sudo tcpdump -ni wg0 host 10.10.50.20 and tcp port 443 -c 6
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:11:01.102345 IP 10.44.0.101.51722 > 10.10.50.20.443: Flags [S], seq 3011221, win 64240, options [mss 1360,sackOK,TS val 101 ecr 0], length 0
12:11:01.135902 IP 10.10.50.20.443 > 10.44.0.101.51722: Flags [S.], seq 8899102, ack 3011222, win 65160, options [mss 1360,sackOK,TS val 200 ecr 101], length 0
12:11:01.136120 IP 10.44.0.101.51722 > 10.10.50.20.443: Flags [.], ack 1, win 502, options [TS val 102 ecr 200], length 0

Sens : Vous voyez SYN, SYN-ACK, ACK. Cela prouve que le trafic de retour revient par le tunnel. Si vous ne voyez que des SYN sans SYN-ACK, le côté site n’a pas de route de retour ou bloque.

Décision : Ajoutez/réparez la route sur le routeur du site pour 10.44.0.0/24 via wg0, ou corrigez les règles de pare‑feu/NAT côté site.

Tâche 9 : Vérifier les problèmes de MTU (le classique « tout se connecte mais la vidéo saccade »)

cr0x@server:~$ ping -c 3 -M do -s 1372 10.10.50.20
PING 10.10.50.20 (10.10.50.20) 1372(1400) bytes of data.
1372 bytes from 10.10.50.20: icmp_seq=1 ttl=63 time=32.4 ms
1372 bytes from 10.10.50.20: icmp_seq=2 ttl=63 time=32.0 ms
1372 bytes from 10.10.50.20: icmp_seq=3 ttl=63 time=32.3 ms

--- 10.10.50.20 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Sens : Avec DF réglé (-M do), des paquets de taille 1400 fonctionnent bout en bout. Si cela échoue à une certaine taille, vous avez des contraintes de MTU sur le chemin (commun avec PPPoE, LTE ou encapsulations multiples).

Décision : Baissez le MTU WireGuard (par exemple à 1360 ou 1280) sur les clients/routeurs de site, puis retestez la stabilité.

Tâche 10 : Surveiller la bande passante et identifier le véritable consommateur

cr0x@server:~$ ip -s link show dev wg0
6: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none
    RX:  bytes packets errors dropped  missed   mcast
      987654321  902341      0      12       0       0
    TX:  bytes packets errors dropped carrier collsns
      1928374650 1102341      0      18       0       0

Sens : Des drops qui augmentent sous charge se corrèlent avec des problèmes de buffering ou de saturation CPU. Combinez avec des stats CPU et les compteurs d’interface.

Décision : Si les drops montent pendant la visualisation, limitez le débit des flux, réduisez le nombre de flux simultanés, ou augmentez la taille CPU/instance du hub. Les VPN n’inventent pas de bande passante.

Tâche 11 : Vérifier le comportement de résolution DNS pour les noms NVR

cr0x@server:~$ resolvectl status | sed -n '1,80p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
 resolv.conf mode: stub
Current DNS Server: 10.44.0.1
       DNS Servers: 10.44.0.1

Link 3 (wg0)
Current Scopes: DNS
     Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
   DNS Servers: 10.44.0.1
    DNS Domain: corp.internal

Sens : Le DNS est configuré vers un résolveur côté VPN (10.44.0.1) et scindé sur l’interface VPN. Cela évite que des DNS publics en Wi‑Fi public résolvent mal vos noms privés.

Décision : Si les noms ne se résolvent pas, corrigez le DNS scindé : poussez le DNS via la config VPN client ou exécutez un résolveur accessible sur le VPN.

Tâche 12 : Confirmer que vous ne faites pas involontairement du hairpinning vidéo via le WAN du bureau

cr0x@server:~$ sudo conntrack -L | grep 10.10.50.20 | head
tcp      6 431999 ESTABLISHED src=10.44.0.101 dst=10.10.50.20 sport=51722 dport=443 src=10.10.50.20 dst=10.44.0.101 sport=443 dport=51722 [ASSURED] mark=0 use=1
tcp      6 431999 ESTABLISHED src=10.44.0.101 dst=10.10.50.20 sport=54012 dport=554 src=10.10.50.20 dst=10.44.0.101 sport=554 dport=54012 [ASSURED] mark=0 use=1

Sens : Vous voyez l’IP client VPN vers l’IP NVR directement, non NATée dans un autre sous‑réseau. C’est bon ; cela garde la politique intelligible et les logs utiles.

Décision : Si vous voyez un NAT non prévu, auditez les règles iptables/nft NAT et retirez les règles de masquage « temporaires » devenues permanentes.

Tâche 13 : Prouver que le VLAN caméra du site ne route pas vers l’internet via le VPN (oui, ça arrive)

cr0x@server:~$ sudo wg show wg0 allowed-ips
peer: 9mR...aQ=
  allowed ips: 10.44.0.10/32, 10.10.50.0/24
peer: Q1s...p8=
  allowed ips: 10.44.0.101/32

Sens : Le peer site n’annonce que son IP VPN et son sous‑réseau caméra. Si vous voyez 0.0.0.0/0 ou des plages corporate larges ici sans raison, quelqu’un transforme votre VPN en route par défaut.

Décision : Gardez AllowedIPs serrés. Si vous avez besoin de plus de sous‑réseaux, listez‑les explicitement et revoyez le rayon d’impact.

Tâche 14 : Valider la synchronisation temporelle (TLS et logs sont inutiles quand l’heure est fausse)

cr0x@server:~$ timedatectl
               Local time: Sun 2025-12-28 11:52:18 UTC
           Universal time: Sun 2025-12-28 11:52:18 UTC
                 RTC time: Sun 2025-12-28 11:52:18
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Sens : Un temps synchronisé rend votre piste d’audit défendable et évite les surprises « certificat TLS pas encore valide/expiré » lors du proxy de l’UI NVR.

Décision : Corrigez NTP partout où vous le pouvez (hub, routeurs de site, NVR si pris en charge). Si des dispositifs ne peuvent pas faire NTP de façon fiable, prenez cela en compte dans la réponse aux incidents.

Guide de diagnostic rapide

Quand « l’accès aux caméras est cassé », vous pouvez perdre des heures à rebondir entre équipes. Ne le faites pas. Utilisez une séquence serrée qui restreint rapidement le goulot d’étranglement.

Première étape : Le tunnel est‑il vivant ?

Vérifiez wg show sur le hub : avez‑vous un handshake récent pour le peer site et le peer utilisateur ?
Si pas de handshake : c’est NAT/pare‑feu/joignabilité endpoint ou mismatch de clé. Ce n’est pas « le NVR est tombé ».

Deuxième étape : Le routage est‑il correct dans les deux sens ?

Depuis le hub, ip route get 10.10.50.20 doit choisir wg0.
Utilisez tcpdump sur wg0 pendant qu’un utilisateur tente l’accès. Si le SYN sort mais aucun SYN-ACK ne revient : le routeur/NVR côté site a un problème de chemin de retour.
Executez traceroute -n depuis le hub vers le NVR et voyez où ça s’arrête.

Troisième étape : La politique/pare‑feu bloque‑t‑elle la bonne chose ?

Sur le hub : vérifiez que la chaîne forward autorise les ports requis vers le sous‑réseau site.
Sur le site : vérifiez que le VLAN caméra autorise les entrées depuis le sous‑réseau VPN et permet le trafic de retour.
Souvenez‑vous : les règles « established,related » n’aident pas si le SYN initial n’atteint jamais la destination.

Quatrième étape : Est‑ce un problème de performance (MTU, perte de paquets, saturation) plutôt que de joignabilité ?

Testez la MTU avec des pings DF.
Vérifiez les drops sur wg0 et les interfaces WAN.
Confirmez combien de flux concurrents et quels débits sont extraits.

Cinquième étape : Particularités applicatives (UI NVR, auth RTSP, découverte ONVIF)

HTTPS joignable ne signifie pas « connexion fonctionnelle ». Le décalage d’heure et les paramètres TLS peuvent casser l’UI.
RTSP peut nécessiter la gestion TCP/UDP selon le client ; certains clients par défaut utilisent UDP et se font bloquer.
La découverte ONVIF utilise des schémas multicast/broadcast qui ne traversent pas les VPN routés sans aides. Préférez la connexion directe par IP pour l’usage distant.

Erreurs fréquentes : symptôme → cause racine → correction

Ceux‑ci reviennent régulièrement sur des flottes réelles, pas dans les diagrammes marketing.

1) « Le VPN se connecte, mais les caméras ne se chargent pas »

Symptôme : L’utilisateur indique « connecté » dans le client VPN ; l’UI web du NVR time‑out ; le ping peut fonctionner.

Cause racine : Les routes existent sur le hub, mais le pare‑feu de forwarding bloque le TCP 443/554 ; ou le routeur du site bloque le sous‑réseau VPN vers le VLAN caméra.

Correction : Ajoutez des règles explicites forward allow sur le hub et le bord site pour le sous‑réseau de destination + ports requis. Validez avec nc -vz et tcpdump.

2) « Ça marche depuis le serveur hub mais pas depuis les portables »

Symptôme : Le hub peut atteindre le NVR ; le client distant non.

Cause racine : La config client manque la route vers le sous‑réseau caméra (split tunnel non configuré) ; AllowedIPs trop étroit sur le client ; ou le DNS pointe vers un résolveur public.

Correction : Poussez/définissez les AllowedIPs sur le client pour inclure les sous‑réseaux caméra. Assurez‑vous que le DNS est scindé et que le nom se résout en IP privée.

3) « La vidéo saccade, l’UI est lente, mais le ping est bon »

Symptôme : La connexion fonctionne ; un flux marche ; plusieurs flux saccadent ou gèlent.

Cause racine : Limites CPU du hub, saturation de la liaison montante du site, ou fragmentation/blackholing MTU sous charge.

Correction : Réduisez le bitrate/résolution des profils distants ; activez des sous‑flux ; ajustez le MTU ; augmentez l’instance hub ; évitez de full‑tunneler tout le trafic.

4) « Tout se casse quand l’ISP change au site »

Symptôme : Le site devient inaccessible après le changement d’ISP ; pas de handshake.

Cause racine : Le peer site ne peut pas atteindre le hub à cause d’un pare‑feu/NAT en amont ; d’anciennes règles autorisaient le port hub ; ou le site reposait sur l’hypothèse fragile « port ouvert ».

Correction : Assurez‑vous que les sorties UDP vers le port hub (par ex. 51820) sont autorisées. Utilisez PersistentKeepalive pour NAT. Documentez les exigences ISP.

5) « Deux sites ne peuvent pas être en ligne en même temps »

Symptôme : Mettre en route le Site B fait disparaître les routes du Site A ou provoque des basculements de trafic.

Cause racine : Sous‑réseaux qui se chevauchent (les deux sites utilisent 192.168.1.0/24, etc.) ou AllowedIPs qui se chevauchent sur le hub.

Correction : Arrêtez d’utiliser des adresses qui se chevauchent pour l’accès routé. Si le renumérotage est impossible, utilisez du NAT au bord site (prudemment) ou déployez des VRF par site — les deux impliquent du travail, choisissez votre douleur en connaissance de cause.

6) « La découverte ONVIF fonctionne au bureau mais pas via le VPN »

Symptôme : L’outil de découverte caméra ne trouve rien à distance ; l’IP directe fonctionne.

Cause racine : La découverte ONVIF utilise multicast/broadcast qui ne traverse pas par défaut les VPN routés.

Correction : Utilisez des IP/listes d’hôtes pour l’accès à distance. Si la découverte est indispensable, déployez un proxy de découverte sur site ou utilisez une gestion centrée sur le NVR.

7) « Des utilisateurs aléatoires peuvent atteindre des caméras qu’ils ne devraient pas »

Symptôme : Un utilisateur avec accès VPN peut scanner des VLAN caméras sur plusieurs sites.

Cause racine : Politique VPN plate ; la chaîne forward du hub autorise de larges plages de destination ; pas de règles par groupe.

Correction : Segmentez les pools d’adresses VPN par rôle ; appliquez des restrictions de destination au hub ; envisagez des jump hosts par site ou un proxy d’identité pour l’UI.

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

Mini‑récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise avec quelques entrepôts a déployé une solution « simple » : chaque routeur de site créait un tunnel vers le siège, et le SOC pouvait visualiser les caméras. Ça a marché. Pendant des mois. Tout le monde s’est relâché, et c’est comme ça que la défaillance devient une surprise.

Puis un entrepôt a changé d’ISP. Le site avait toujours « internet » localement, donc l’enregistrement local des caméras était OK. Mais l’accès distant est mort. Les Services Généraux ont signalé « VPN down », l’IT a répondu « souci ISP », et la sécurité a escaladé parce qu’ils avaient besoin des images pour une enquête.

La mauvaise hypothèse : « Internet sortant signifie UDP sortant sur notre port choisi ». Le nouveau modem fourni par l’ISP faisait de la « sécurité utile » en bloquant l’UDP sortant sauf sur des ports courants, et personne ne l’avait remarqué lors de l’installation. Le tunnel n’a jamais fait de handshake à nouveau.

Ils ont perdu une demi‑journée à se renvoyer la responsabilité. La correction a pris dix minutes : déplacer WireGuard vers un port autorisé et autoriser explicitement l’UDP sortant depuis le routeur site. La vraie correction a pris plus de temps : mettre à jour la check‑list de déploiement pour inclure « valider l’UDP egress vers le hub » et exiger une vérification de handshake post‑cutover comme jalon de validation.

Mini‑récit 2 : L’optimisation qui a mal tourné

Une autre organisation a jugé que leur VM hub était « surdimensionnée ». Ils l’ont réduite pour économiser, parce que le VPN « ne fait que du routage ». Quelqu’un a regardé des graphiques de débit moyen et a décrété la victoire.

Deux semaines plus tard, pendant un incident régional, plusieurs managers ont ouvert des vues en direct simultanément. Le CPU du hub est monté à 100 %, des paquets ont été perdus, et les utilisateurs ont constaté des « flapping » de caméras. Ça ressemblait d’abord à un problème caméra, puis à un souci d’uplink site, puis à un problème de NVR — parce que les humains aiment blâmer la périphérie.

Ce qui s’est réellement passé : surcharge liée au chiffrement + conntrack + journalisation + un pic de flux simultanés qui a dépassé la petite instance. L’usage moyen était hors sujet ; la charge a des pics marqués. La vidéosurveillance est par nature épisodique — les gens ne regardent pas 24/7, ils se ruent durant les incidents.

La mauvaise optimisation n’était pas seulement le redimensionnement ; c’était l’absence de tests de charge et l’absence d’un SLO clair (« X flux simultanés à Y bitrate avec Z latence »). Ils ont rétabli la taille de l’instance, limité les flux non essentiels et ajouté un profil « faible bande passante » pour les utilisateurs distants. Puis ils ont gardé cette configuration, parce que dépenser un peu pour de la marge est moins cher qu’un pont d’incident à 2h du matin.

Mini‑récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise appliquait une pratique monotone : chaque site CCTV avait un schéma d’adressage standard (pas de chevauchement), chaque tunnel site avait un sous‑réseau caméra documenté, et chaque changement nécessitait l’exécution d’un script de validation depuis le hub.

Pendant une tempête, plusieurs sites ont perdu puis récupéré l’alimentation. Un sous‑ensemble de routeurs site a redémarré dans un état dégradé : le WAN était up, mais l’interface VLAN caméra ne remontait pas correctement à cause d’un quirk de négociation de switch. Localement, le personnel voyait encore certains flux grâce au caching et à une connectivité partielle. À distance, c’était perçu comme « VPN mais pas de caméras ».

La personne de garde n’a pas deviné. Elle a exécuté les mêmes vérifications : handshake OK, route OK, SYN TCP sort, pas de SYN-ACK. Cela a immédiatement localisé le problème côté site, pas au hub. Ils ont appelé le technicien terrain avec une instruction précise : redémarrer le port de switch et vérifier que l’interface VLAN est up. Pas de tâtonnements.

Parce que l’environnement était standardisé, ils ont réparé plusieurs sites rapidement. La partie « ennuyeuse » — sous‑réseaux cohérents, routage cohérent, contrôles cohérents — a fait que la panne n’est pas devenue une danse interprétative de savoirs tribaux.

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

Si vous faites cela comme un « projet IT », ça va s’étendre. Faites‑le comme un déploiement opérationnel avec des jalons clairs.

Étape 1 : Inventaire et attentes de trafic

Listez le VLAN/sous‑réseau caméras et les IP(s) NVR de chaque site.
Documentez les ports nécessaires : HTTPS, RTSP, ports SDK fournisseur, synchronisation temporelle.
Estimez les visionneuses distantes concurrentes et le bitrate attendu (flux principal vs sous‑flux).
Décidez si vous avez besoin d’accéder aux caméras directement ou seulement à l’interface NVR. Préférez l’UI NVR pour les utilisateurs distants ; cela centralise l’authentification et limite les mouvements latéraux.

Étape 2 : Choix de l’emplacement du hub et modèle de défaillance

Le hub au bureau convient si l’internet du bureau est résilient et supervisé.
Le hub cloud convient si vous pouvez l’opérer comme de la production (patching, backups, IaC, monitoring).
Décidez si vous avez besoin d’un ou deux hubs pour la redondance. Si l’accès aux caméras est critique, un seul hub est un point de défaillance.

Étape 3 : Plan d’adressage qui ne vous sabote pas plus tard

Allouez un sous‑réseau VPN dédié (par ex. 10.44.0.0/24).
Assurez‑vous que chaque sous‑réseau caméra de site est unique dans la flotte. Si vous avez déjà des chevauchements, priorisez le renumérotage ou isolez via NAT/VRF avec documentation claire.
Réservez des blocs IP pour les rôles utilisateurs si vous allez appliquer des politiques par IP source (par ex. 10.44.0.100/26 pour opérateurs, 10.44.0.200/27 pour admins).

Étape 4 : Construire le hub avec des défauts restrictifs

Activez WireGuard, l’IP forwarding et une politique de pare‑feu stricte (default drop forward).
Journalisez les refus (avec limitation de débit) pour pouvoir déboguer sans être submergé.
Configurez le DNS pour les clients VPN (split DNS) si vous voulez des noms conviviaux.
Décidez comment vous distribuez les configs et faites tourner les clés. Les configurations manuelles ne montent pas en charge au‑delà de « quelques personnes et un on‑call ».

Étape 5 : Onboarder un site pilote bout à bout

Montez le tunnel site et confirmez la stabilité du handshake (inclure PersistentKeepalive si NATé).
Vérifiez la joignabilité hub→NVR et les contrôles de ports.
Vérifiez la joignabilité client distant→NVR et les contrôles de ports.
Mesurez un flux réel et notez l’impact CPU et bande passante sur le hub et l’uplink site.

Étape 6 : Déployer des politiques, pas seulement la connectivité

Mettez en œuvre des règles de destination par site : les utilisateurs qui n’ont pas besoin du Site A ne doivent pas y accéder.
Mettez en œuvre des règles par rôle : visionneurs vs administrateurs.
Bloquez les mouvements latéraux : empêchez les sous‑réseaux clients VPN de communiquer entre eux sauf si explicitement requis.

Étape 7 : Opérationnaliser

Monitoring : age des handshakes, CPU du hub, drops d’interface, débit, contrôles TCP basiques des NVR critiques.
Alerte : « tunnel site down », « hub surchargé », « drops paquets en hausse ».
Runbooks : inclure le guide de diagnostic rapide et les commandes exactes que vous exécuterez.
Contrôle de changement : une petite modification de config peut router la moitié de votre réseau dans un trou noir.

FAQ

1) Ai‑je vraiment besoin d’un VPN ? Ne puis‑je pas juste utiliser le cloud P2P du fournisseur ?

Vous pouvez, mais vous externalisez votre périmètre et votre piste d’audit. Si vous avez des exigences de conformité, ou si vous voulez contrôler qui peut accéder à quoi, un VPN (ou un proxy d’identité) est la valeur opérationnelle sûre par défaut.

2) Que faire si le site n’a pas d’IP publique et est derrière un CGNAT ?

Ça marche pour hub‑and‑spoke tant que le site peut établir des connexions sortantes vers le hub. WireGuard fonctionne bien ici ; utilisez PersistentKeepalive pour que les mappings NAT n’expirent pas.

3) Dois‑je utiliser IPsec plutôt que WireGuard ?

Utilisez ce que votre équipe peut exploiter de manière fiable. IPsec est omniprésent et souvent intégré aux pare‑feux ; il est aussi plus facile à mal configurer et plus difficile à déboguer. WireGuard est plus simple et tend à être plus prévisible. Si votre équipement de bord supporte bien IPsec et que vous avez des personnes qui le maîtrisent, IPsec est parfaitement valide.

4) Puis‑je accéder aux caméras directement via le VPN, ou seulement au NVR ?

Privilégiez le NVR pour la visualisation distante : moins d’endpoints exposés, authentification centralisée et moins de risque de quelqu’un qui fouille des interfaces web de caméra aléatoires. L’accès direct aux caméras est parfois nécessaire pour la mise en service ou le diagnostic ; restreignez‑le aux seuls admins.

5) Pourquoi la découverte ONVIF échoue‑t‑elle sur le VPN ?

La découverte utilise souvent du multicast/broadcast qui ne traverse pas par défaut les réseaux routés. Les VPN sont généralement routés. Solution : connexion par IP/liste d’hôtes, ou déployer un outil de découverte local sur site.

6) Ai‑je besoin du split tunneling ?

Généralement oui. Ne tunnelisez que les sous‑réseaux caméras/NVR via le VPN. Full‑tunneling tout le trafic fait du hub un goulet pour la navigation non liée et peut détruire les performances lors d’événements vidéo.

7) Comment empêcher qu’un site atteigne les caméras d’un autre site ?

Au hub, appliquez une politique de forwarding qui autorise les clients VPN à atteindre uniquement des sous‑réseaux de destination spécifiques. Gardez aussi AllowedIPs serrés par peer. Supposez que « si ça route, quelqu’un finira par le scanner ».

8) Quel est le minimum de journalisation que je devrais avoir ?

Au minimum : événements de connexion (handshakes peer ou établissement de session), logs allow/deny du pare‑feu (limités en débit), et une cartographie identité VPN (clé/utilisateur) → politique d’accès. Sans ça, votre réponse aux incidents devient une œuvre d’art interprétative.

9) Puis‑je placer le hub dans le cloud si les caméras sont sur des LAN privés ?

Oui. Les sites initient des tunnels sortants vers le hub cloud ; les utilisateurs se connectent au hub ; les routes sont échangées au hub. Le hub cloud devient votre point de rencontre. Traitez‑le comme de l’infra de production : patch, monitoring et sauvegarde des configs.

10) Comment gérer des sous‑réseaux caméra qui se chevauchent entre sites ?

Renumérotez si vous le pouvez. Si vous ne pouvez pas, utilisez NAT au bord site (traduisez chaque site dans un sous‑réseau « virtuel » unique) ou isolez avec des VRF. Le NAT ajoute de la complexité et peut casser certains protocoles de découverte, mais c’est parfois le moindre mal en retrofit.

Conclusion : prochaines étapes réalisables cette semaine

Si vous voulez un accès CCTV sécurisé sans IP publiques, cessez de négocier avec la physique et commencez par contrôler votre topologie.

Choisissez une conception de référence : hub‑and‑spoke est le défaut pratique pour le CCTV multi‑site.
Standardisez l’adressage : sous‑réseaux caméras uniques par site, sous‑réseau VPN dédié, ports documentés.
Mettez en œuvre WireGuard (ou IPsec) avec une politique stricte : drop par défaut, n’autorisez que les ports requis, bloquez le mouvement latéral.
Opérationnalisez dès le premier jour : surveillance des handshakes, vérifications de routes, contrôles de ports et un runbook court qu’un on‑call peut suivre à 3 h du matin.
Pilotez un site, mesurez la bande passante et le CPU du hub, puis déployez avec une check‑list et des jalons de validation.

Faites la chose ennuyeuse. Votre futur vous en sera reconnaissant, ce qui est rare dans l’infrastructure.