Vidéosurveillance via VPN : accédez à votre DVR/NVR de façon fiable sans l’exposer à Internet

Le vrai modèle de menace (et pourquoi la redirection de ports est un piège)

La plupart des systèmes de vidéosurveillance échouent de deux façons : ils sont exposés, ou ils deviennent instables. Parfois les deux.
La recette habituelle est douloureusement cohérente : quelqu’un ouvre des ports depuis Internet vers le DVR/NVR, change peut‑être le mot de passe par défaut (peut‑être),
puis se demande pourquoi l’appareil reçoit une pluie de tentatives de connexion, ou pourquoi un bug de firmware devient un incident externe.

Votre DVR/NVR n’est pas un service durci exposé à Internet. C’est un appareil. Il tourne souvent sur un vieux Linux embarqué, a une interface web d’origine douteuse,
et vient avec des fonctionnalités « utiles » comme UPnP et des relais P2P du fournisseur — parfaites pour les démonstrations, catastrophiques pour le risque.

Ce que vous protégez

• Remplissage d’identifiants et attaque par force brute sur les ports web/RTSP/SDK. Vos utilisateurs réutilisent des mots de passe ; les attaquants réutilisent des listes.
• Surfaces de gestion exposées : interfaces web, telnet/ssh (parfois cachés), services ONVIF et ports SDK spécifiques au fournisseur.
• Fonctions d’accès distant silencieuses comme le cloud P2P et UPnP qui rouvrent l’exposition après que vous avez « corrigé » le problème.
• Mouvement latéral : une fois le DVR compromis, il se trouve sur votre LAN à proximité de tout ce qui compte vraiment.
• Échecs de confidentialité et de conformité : les flux caméra sont des données personnelles dans de nombreuses juridictions ; « on a redirigé 37777 vers le DVR » n’est pas une politique.

Ce que change un VPN

Un VPN ne sécurise pas magiquement un DVR. Il réduit drastiquement la surface d’attaque en retirant le DVR d’Internet public.
Ensuite vous placez le contrôle d’accès là où il doit être : à la frontière VPN, avec une cryptographie moderne, une authentification sensée, des logs et un kill switch pour la révocation.

Le VPN est votre porte d’entrée. Le DVR reste à l’intérieur. Vous n’installez pas une porte de coffre sur un cabanon.

Blague #1 : Rediriger un port vers un DVR, c’est comme laisser vos clés sous le paillasson — sauf qu’Internet a une carte de votre paillasson.

Faits intéressants et contexte historique

1. La vidéosurveillance initiale était par conception en circuit fermé (années 1940–1960) : câbles coaxiaux, moniteurs locaux, pas de routage. « Accès distant » signifiait rallonger le câble.
2. RTSP date de la fin des années 1990 : il a standardisé le contrôle du streaming média, et les fournisseurs CCTV l’ont adopté parce que « ça suffisait ».
3. ONVIF est apparu en 2008 pour unifier l’interopérabilité des caméras IP. Cela a aidé l’intégration, mais aussi standardisé des services détectables sur le LAN.
4. UPnP (fin des années 1990) a facilité l’ouverture automatique de ports pare‑feu pour les appareils grand public — exactement ce que vous ne voulez pas pour des appliances de sécurité.
5. Les clouds P2P des fournisseurs ont explosé dans les années 2010 : ils contournent la NAT pour une visualisation mobile facile, au prix de frontières de confiance et d’absence d’audit.
6. Mirai (2016) a popularisé les botnets IoT en abusant des identifiants par défaut et des services exposés, y compris des caméras et appareils proches des DVR.
7. WireGuard (public en 2018) a rendu les VPN modernes plus simples : moins de composants, base de code réduite et généralement moins de moments « pourquoi la renégociation TLS fait ça ? ».
8. Le CGNAT mobile est devenu courant chez les opérateurs : vous ne pouvez souvent pas « ouvrir un port » même si vous le vouliez, ce qui est une bénédiction déguisée.

Architectures de référence qui fonctionnent vraiment

1) VPN « road‑warrior » vers une passerelle de site (le plus courant)

Placez une petite passerelle VPN sur le site des caméras (appliance pare‑feu, mini PC ou routeur capable).
Votre téléphone/ordinateur se connecte à la passerelle, et la passerelle vous route vers le VLAN/sous‑réseau CCTV. Le DVR/NVR n’a aucune exposition publique.

• Idéal pour : site unique, quelques utilisateurs à distance, accès prévisibles.
• Atouts : simple, auditable, pas de dépendance au cloud fournisseur.
• Pièges : routage et DNS. Les problèmes de MTU sur LTE reviennent souvent.

2) VPN site‑à‑site entre bureaux et site caméra (pour SOC/NOC)

Si vous avez une salle d’opérations de sécurité ou de supervision centrale, le site‑à‑site est plus propre. Les utilisateurs distants se connectent alors au VPN d’entreprise comme d’habitude,
et le réseau d’entreprise peut atteindre le site caméra via le tunnel.

• Idéal pour : domaines multi‑sites, supervision centrale, contrôles d’accès standardisés.
• Atouts : politique et journalisation cohérentes.
• Pièges : sous‑réseaux qui se chevauchent, contrôle des changements et « qui possède la table de routage ».

3) Hub‑and‑spoke avec un concentrateur VPN central (échelle et cohérence)

Chaque site établit un tunnel vers un nœud central (cloud ou datacenter). Les utilisateurs se connectent au même nœud central. C’est opérationnellement propre :
un endroit pour gérer l’identité, un endroit pour journaliser, un endroit pour appliquer la limitation.

• Idéal pour : nombreux sites, accès distant cohérent, gouvernance centralisée.
• Atouts : le retrait d’accès est immédiat ; vous pouvez appliquer la MFA et la posture des appareils en un seul point.
• Pièges : vous gérez maintenant un service central. Conceptez‑le sérieusement.

Ce qu’il ne faut pas faire

Évitez « serveur VPN sur le DVR » à moins d’aimer le débogage sur firmware fermé.
Évitez « ouvrir un port et whitelister l’IP du bureau » à moins que tous les utilisateurs distants ne quittent jamais le bureau.
Et évitez le P2P fournisseur quand vous avez besoin d’audit, de déterminisme ou d’une histoire de conformité qui survive une réunion avec le juridique.

Choix du VPN : WireGuard, OpenVPN, IPsec ou « cloud du fournisseur »

WireGuard : le choix par défaut en 2025

WireGuard est léger, rapide et prévisible. Il utilise de la cryptographie moderne, a une surface de configuration minimale et a tendance à bien se comporter sur des liens instables.
Pour la vidéosurveillance, ce ne sont pas des luxes. C’est la différence entre « marche depuis le parking » et « marche toujours ».

Opérationnellement, WireGuard est aussi honnête : si vous ne pouvez pas atteindre l’extrémité, vous ne pouvez pas l’atteindre. Pas de « handshake TLS réussi mais les routes n’y sont pas ».
Cette simplicité paye quand vous dépannez à 03:00.

OpenVPN : toujours utile, surtout si vous avez besoin d’intégration d’authentification d’entreprise

OpenVPN est plus ancien et plus lourd, mais il dispose d’outils matures pour la gestion des certificats et l’authentification utilisateur, et d’un long historique.
Si vous devez intégrer des systèmes existants (RADIUS, certains modèles de distribution client, appliances legacy), OpenVPN peut être le choix pragmatique.

IPsec : excellent si vous l’avez déjà partout

IPsec site‑à‑site peut être excellent, surtout avec de bons pare‑feux. Mais les problèmes d’interop, les paramètres de phase et les abstractions UI des fournisseurs
peuvent transformer un routage simple en une danse interprétative. Si votre environnement est déjà IPsec‑heavy, restez‑y. Sinon, n’allez pas y commencer juste pour accéder aux caméras.

Cloud P2P du fournisseur : pratique, opaque et risqué

Le P2P fournisseur existe parce que le NAT traversal est compliqué et que les gens veulent « scanner un QR et ça marche ».
Cela signifie aussi que votre accès vidéo peut dépendre de relais externes, de pratiques de journalisation inconnues et d’apps clientes qui se mettent à jour quand elles le décident.
Si vous tenez à la disponibilité et à la sécurité, vous voulez moins de dépendances, pas plus.

Idée paraphrasée attribuée à Gene Kranz : « Durs et compétents » est la norme — les systèmes doivent fonctionner sous pression, pas exiger des interventions héroïques.

Conception réseau : sous‑réseaux, routage, DNS et ne pas percer des trous

Séparez les caméras et l’enregistreur

Placez les caméras et le DVR/NVR sur un VLAN/sous‑réseau dédié. Pas parce que les VLAN sont magiques, mais parce qu’ils vous forcent à définir une politique.
Vous pouvez autoriser l’NVR à parler aux caméras, autoriser vos clients VPN à parler à l’NVR, et bloquer tout le reste par défaut.

Si votre enregistreur a deux NIC (LAN + caméra), utilisez‑les correctement : une face pour le trafic caméra, une face pour l’administration/l’accès client.
Sinon, séparez au moins avec des VLANs et des règles de pare‑feu.

Décidez : tunnel complet ou split‑tunnel

• Split‑tunnel : seuls les sous‑réseaux CCTV passent par le VPN. Moins de bande passante, moins de surprises. Plus d’attention pour éviter les fuites DNS ou les conflits locaux.
• Full‑tunnel : tout le trafic passe par le VPN. Plus de contrôle et de comportement cohérent, mais vous devenez l’ISP de l’utilisateur. Prévoyez la capacité.

Pour l’accès CCTV, le split‑tunnel suffit généralement si vous gérez bien le DNS et évitez les sous‑réseaux qui se chevauchent.
Pour des appareils gérés, le full‑tunnel peut être plus simple car vous pouvez faire respecter la politique et la journalisation.

Routage : rendez‑le explicite

Le VPN n’est pas de la « magie d’accès distant ». C’est du routage plus chiffrement. Si un utilisateur se connecte mais ne peut pas atteindre l’NVR, 90% du temps c’est un problème de route,
un pare‑feu, ou un problème de MTU. Les 10% restants, c’est l’NVR qui fait l’NVR.

DNS : choisissez une stratégie que vous pouvez supporter

Ne comptez pas sur les utilisateurs pour taper des adresses IP indéfiniment. Donnez à l’NVR un nom stable comme nvr.site1.lan et rendez‑le résolvable via le VPN.
Vous pouvez le faire avec un DNS interne, pousser des serveurs DNS via le VPN, ou même des entrées hosts statiques en dépannage (pas recommandé à l’échelle).

Authentification et autorisation : traitez‑les comme en production

Utilisez des identités par utilisateur quand c’est possible. Utilisez la MFA pour le VPN si vous le pouvez. Ne partagez pas un profil VPN « security@company » entre dix téléphones.
Ce n’est pas du contrôle d’accès. C’est de l’optimisme avec un logo.

Durcissement côté vidéosurveillance : DVR/NVR, caméras et problème des applications

Désactivez les fonctions d’exposition « utiles »

Sur le DVR/NVR et le routeur/pare‑feu en amont :

• Désactivez UPnP.
• Désactivez les fonctionnalités de relais P2P/cloud du fournisseur sauf si vous avez une raison formelle et une acceptation de risque.
• Désactivez la gestion distante depuis le WAN.
• Restreignez les interfaces de gestion au sous‑réseau VPN.

Verrouillez les comptes

• Créez des comptes nominatifs, pas des comptes partagés.
• Supprimez ou désactivez les comptes par défaut (ou au moins changez les identifiants et réduisez les privilèges).
• Appliquez le moindre privilège : les utilisateurs en lecture seule ne devraient pas pouvoir mettre à jour le firmware.

Firmware et synchronisation d’heure

Maintenez le firmware à jour, mais ne faites pas de « mise à jour automatique » d’un enregistreur en production sans plan de retour arrière.
Assurez‑vous aussi que l’enregistreur et les caméras ont la bonne heure via NTP. Une heure incorrecte casse les logs, les certificats et parfois l’indexation de la lecture.

Blague #2 : La seule chose plus confiante que l’interface web d’un DVR est un pilote d’imprimante — les deux se croient le service le plus important sur votre réseau.

Ingénierie de fiabilité : latence, MTU, NAT, et pourquoi la vidéo rend les réseaux menteurs

Calcul de bande passante : ne devinez pas

Un flux 1080p H.264 peut faire 2–6 Mbps selon les réglages de bitrate, le mouvement, la complexité de la scène et l’optimisme du fournisseur.
Multipliez par le nombre de vues simultanées ou de flux de lecture. Ajoutez ensuite la surcharge d’encapsulation VPN et les retransmissions sur liens dégradés.

Pour la lecture à distance, les utilisateurs zappent souvent la timeline et déclenchent des rafales de trafic. Ce n’est pas « un flux stable », c’est « accès aléatoire avec pics ».
Si votre liaison montante est asymétrique (typique câble/ADSL), l’upload du site est le goulot d’étranglement.

La latence et la gigue comptent plus que vous ne le pensez

La visualisation en direct tolère la latence dans une certaine mesure, mais pas la gigue et la perte de paquets. La lecture peut être pire : elle demande des keyframes ou saute,
et certains clients réagissent mal à la réorganisation ou au retard de paquets.

MTU : le tueur silencieux

Le VPN ajoute des en‑têtes. Sur des liens avec un path MTU plus faible (LTE, PPPoE, certains scénarios DOCSIS), vous verrez des symptômes étranges :
des pages de connexion se chargent mais la vidéo ne passe pas, ou de petits pings fonctionnent mais l’app expire.
Corriger le MTU/MSS est l’une des tâches réseau les moins glamours — et l’une des plus efficaces.

Traversal NAT : choisissez des designs déterministes

Si le site caméra est derrière une NAT que vous ne contrôlez pas, un modèle « serveur dans le cloud + site comme client » est souvent le meilleur :
le site initie le tunnel vers l’extérieur, donc aucun port entrant n’est requis.
C’est un motif propre pour les points de vente, les chantiers et tout endroit où le routeur ISP est « géré par qui l’a installé en 2017 ».

Journalisation et observabilité

Si vous ne pouvez pas répondre à « qui s’est connecté, d’où et qu’a‑t‑il atteint », vous n’avez pas un accès distant — vous avez un mystère.
Journalisez les connexions VPN, assignez des IP client stables et enregistrez les hits/blocs du pare‑feu pour les sous‑réseaux CCTV.

Tâches pratiques : commandes, sorties, et décisions

Ce sont des vérifications éprouvées sur le terrain que vous pouvez exécuter depuis une passerelle VPN Linux ou un jump host sur le VPN. Chaque tâche contient : une commande, une sortie réaliste,
ce que cela signifie et la décision suivante.

Task 1: Verify the VPN interface is up and has the right address

cr0x@server:~$ ip -brief addr show wg0
wg0             UNKNOWN        10.60.0.1/24

Signification : L’interface wg0 existe et a 10.60.0.1/24. L’état UNKNOWN est normal pour WireGuard.
Décision : Si l’interface est manquante ou a le mauvais sous‑réseau, corrigez la config WireGuard avant de chercher des problèmes caméra.

Task 2: Check WireGuard peer handshake freshness

cr0x@server:~$ sudo wg show wg0
interface: wg0
  public key: 9mQq...V1k=
  listening port: 51820

peer: pQ0w...h3c=
  endpoint: 198.51.100.24:46211
  allowed ips: 10.60.0.10/32, 10.20.30.0/24
  latest handshake: 54 seconds ago
  transfer: 1.23 GiB received, 3.88 GiB sent
  persistent keepalive: every 25 seconds

Signification : Le pair du site est vivant (handshake dans la minute). Allowed IPs inclut le sous‑réseau caméra 10.20.30.0/24.
Décision : Si le handshake est « never », vous n’êtes pas connecté — vérifiez la portée de l’endpoint, la NAT, les clés et le pare‑feu.

Task 3: Confirm routes to the CCTV subnet exist

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

Signification : Le trafic vers le sous‑réseau caméra passe par le VPN.
Décision : S’il n’y a pas de route, ajoutez‑la (ou corrigez AllowedIPs si vous utilisez WireGuard avec policy routing).

Task 4: Test basic reachability to the NVR IP

cr0x@server:~$ ping -c 3 10.20.30.50
PING 10.20.30.50 (10.20.30.50) 56(84) bytes of data.
64 bytes from 10.20.30.50: icmp_seq=1 ttl=63 time=34.8 ms
64 bytes from 10.20.30.50: icmp_seq=2 ttl=63 time=35.2 ms
64 bytes from 10.20.30.50: icmp_seq=3 ttl=63 time=35.0 ms

--- 10.20.30.50 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 34.8/35.0/35.2/0.2 ms

Signification : ICMP fonctionne ; la latence est ~35ms, acceptable pour la visualisation.
Décision : Si le ping échoue, ne blâmez pas encore l’app — vérifiez le routage et le pare‑feu. Si le ping marche mais la vidéo échoue, passez aux vérifs de ports et MTU.

Task 5: Identify which ports the NVR exposes (without guessing)

cr0x@server:~$ sudo nmap -sS -Pn -p 80,443,554,8000,8080,37777 10.20.30.50
Starting Nmap 7.94 ( https://nmap.org ) at 2025-12-28 10:18 UTC
Nmap scan report for 10.20.30.50
Host is up (0.035s latency).

PORT      STATE SERVICE
80/tcp    open  http
443/tcp   closed https
554/tcp   open  rtsp
8000/tcp  open  http-alt
8080/tcp  closed http-proxy
37777/tcp filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 1.42 seconds

Signification : Interface web sur 80, RTSP sur 554, service fournisseur sur 8000. Le port 37777 est filtré (probablement bloqué par le pare‑feu).
Décision : Assurez‑vous que seuls les ports requis soient atteignables depuis les clients VPN ; bloquez le reste. Si votre client a besoin de 37777, vous avez trouvé la cause.

Task 6: Confirm firewall policy is doing what you think

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif "lo" accept
    ct state established,related accept
    iif "wg0" tcp dport { 22, 80, 554, 8000 } accept
    iif "wg0" icmp type echo-request accept
    counter log prefix "DROP input " drop
  }

  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    iif "wg0" oif "lan0" ip daddr 10.20.30.0/24 accept
    iif "lan0" oif "wg0" ip saddr 10.20.30.0/24 accept
  }
}

Signification : Politique par défaut drop, permissions explicites depuis le VPN vers le sous‑réseau CCTV. C’est la bonne forme.
Décision : Si les règles de forwarding manquent, les clients VPN se connectent mais n’atteignent pas les caméras. Ajoutez les règles forward minimales.

Task 7: Verify IP forwarding is enabled on the VPN gateway

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

Signification : La machine routage IPv4 est activée.
Décision : Si c’est 0, activez et persistez via /etc/sysctl.d/. Sans cela, « le VPN marche » mais rien derrière ne fonctionne.

Task 8: Check NAT (only if you intentionally NAT VPN clients to the CCTV LAN)

cr0x@server:~$ sudo nft list table ip nat
table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oif "lan0" ip saddr 10.60.0.0/24 masquerade
  }
}

Signification : Les adresses sources des clients VPN sont masquées en sortie lan0.
Décision : Le NAT est un palliatif quand l’NVR/côté caméra ne peut pas router vers le sous‑réseau VPN. Préférez le routage, mais le NAT est acceptable si nécessaire.

Task 9: Test TCP connectivity to the recorder web UI

cr0x@server:~$ curl -I --max-time 3 http://10.20.30.50/
HTTP/1.1 200 OK
Server: uc-httpd/1.0.0
Content-Type: text/html
Content-Length: 4132

Signification : HTTP répond rapidement. Le chemin est ouvert.
Décision : Si cela time‑out, vérifiez pare‑feu et routes. Si ça renvoie 401/403, c’est de l’authentification/app, pas du réseau.

Task 10: Check RTSP reachability (common for VMS integrations)

cr0x@server:~$ timeout 3 bash -c 'echo > /dev/tcp/10.20.30.50/554' && echo "rtsp port open"
rtsp port open

Signification : Le port 554 est joignable au niveau TCP.
Décision : Si le TCP est bloqué mais que vous attendiez RTSP, ouvrez‑le uniquement aux clients nécessaires ou proxyfiez‑le via le VMS, pas pour tout le monde.

Task 11: Look for MTU problems with “do not fragment” pings

cr0x@server:~$ ping -c 3 -M do -s 1420 10.20.30.50
PING 10.20.30.50 (10.20.30.50) 1420(1448) bytes of data.
ping: local error: message too long, mtu=1420

--- 10.20.30.50 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2032ms

Signification : Votre MTU effectif est plus petit que prévu ; les gros paquets ne passeront pas sans fragmentation.
Décision : Abaissez le MTU WireGuard (par ex. 1280–1380) ou clamppez le MSS TCP sur la passerelle. Cela règle souvent « l’UI se charge, la vidéo échoue ».

Task 12: Measure loss and jitter with mtr

cr0x@server:~$ mtr -rwzc 50 10.20.30.50
Start: 2025-12-28T10:24:40+0000
HOST: server                          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.60.0.10                     0.0%    50   32.1  34.9  31.8  78.2  8.6
  2.|-- 10.20.30.50                     2.0%    50   35.0  36.7  33.9  92.4  9.9

Signification : 2% de perte vers l’NVR. La vidéo va saccader ; la lecture va rendre la vie difficile.
Décision : Inspectez la qualité du lien sur le site (backhaul Wi‑Fi, ISP, LTE). Envisagez de réduire le bitrate ou d’activer des sous‑flux adaptatifs.

Task 13: Confirm the NVR is actually listening on the expected ports (from the NVR LAN)

cr0x@server:~$ ssh admin@10.20.30.1 "sudo ss -lntp | head"
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      128    0.0.0.0:80         0.0.0.0:*     users:(("uc-httpd",pid=1142,fd=5))
LISTEN 0      128    0.0.0.0:554        0.0.0.0:*     users:(("rtspd",pid=1188,fd=7))
LISTEN 0      128    0.0.0.0:8000       0.0.0.0:*     users:(("vendor_sdk",pid=1210,fd=9))

Signification : Les services sont liés sur toutes les interfaces. Si les clients distants ne peuvent pas se connecter, ce n’est pas parce que l’NVR n’écoute pas.
Décision : Concentrez‑vous sur le routage/pare‑feu/NAT. Si les ports n’écoutent pas, corrigez la config ou l’état du service de l’NVR.

Task 14: Check conntrack exhaustion on the VPN gateway (yes, video can do this)

cr0x@server:~$ sudo conntrack -S | egrep 'entries|max'
entries  28712
max  262144

Signification : Beaucoup de marge. Si entries approche max, de nouvelles connexions peuvent échouer de façon intermittente.
Décision : Si vous êtes proche du max, augmentez les limites conntrack et/ou réduisez le bruit (désactivez la découverte, réduisez le polling client, limitez les viewers concurrents).

Task 15: Verify time sync on the VPN gateway (helps logs and cert validation)

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

Signification : L’heure est synchronisée. Bien.
Décision : Si ce n’est pas synchronisé, corrigez NTP. Une heure incorrecte rend le dépannage impossible et peut casser des VPNs basés sur TLS.

Task 16: Capture traffic to see whether the app is even trying (and what it’s trying)

cr0x@server:~$ sudo tcpdump -ni wg0 host 10.20.30.50 and '(tcp port 80 or tcp port 554 or tcp port 8000)' -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
10:29:44.112233 IP 10.60.0.23.51234 > 10.20.30.50.80: Flags [S], seq 188231231, win 64240, options [mss 1360,sackOK,TS val 123 ecr 0], length 0
10:29:44.145678 IP 10.20.30.50.80 > 10.60.0.23.51234: Flags [S.], seq 9981122, ack 188231232, win 65160, options [mss 1460,sackOK,TS val 456 ecr 123], length 0
10:29:44.145900 IP 10.60.0.23.51234 > 10.20.30.50.80: Flags [.], ack 1, win 64240, options [TS val 124 ecr 456], length 0

Signification : SYN/SYN‑ACK/ACK complète. La connectivité existe ; le client tente HTTP.
Décision : Si vous voyez des SYN sans réponses, c’est un pare‑feu/routage. Si vous ne voyez aucun paquet, c’est le routage/DNS client ou la config split‑tunnel.

Guide de diagnostic rapide

Quand l’accès CCTV à distance échoue, vous pouvez perdre des heures dans les paramètres d’app. Ne le faites pas. Trouvez le goulot vite avec une séquence prévisible.

Première étape : confirmez que le tunnel est réel

• Sur le serveur/passerelle VPN : vérifiez la fraîcheur du handshake (wg show ou le status OpenVPN).
• Sur le client : confirmez qu’il a reçu l’IP VPN attendue et les routes.
• Décision : si le tunnel n’est pas en place, arrêtez. Corrigez les clés, la portée de l’endpoint, la NAT/port ou l’auth.

Deuxième étape : confirmez le routage vers le sous‑réseau CCTV

• Vérifiez la table de routage sur le serveur et le client.
• Pingez l’IP de l’NVR depuis un hôte connu‑bon sur le VPN.
• Décision : si le ping échoue, ce n’est pas un « problème NVR ». C’est routage/pare‑feu/NAT.

Troisième étape : confirmez les ports et la politique

• Scannez seulement les ports attendus depuis le côté VPN (nmap).
• Validez les règles du pare‑feu et le forwarding.
• Décision : n’ouvrez que ce dont vous avez besoin ; si l’app requiert un port SDK fournisseur, autorisez‑le seulement depuis les clients VPN.

Quatrième étape : suspectez MTU et perte

• Lancez des pings DF et mtr vers l’NVR.
• Décision : si les gros paquets échouent ou si la perte est significative, ajustez MTU/MSS, réduisez le bitrate ou réparez la liaison WAN.

Cinquième étape : incriminez l’application, prudemment

• Utilisez tcpdump pour confirmer ce que le client tente.
• Essayez un accès alternatif (UI web vs application mobile vs RTSP).
• Décision : si le réseau est bon, le problème vient probablement de l’auth, du firmware, des réglages codec ou d’un bug client.

Erreurs courantes : symptômes → cause racine → correction

1) « Le VPN se connecte mais je n’atteins pas l’NVR »

Syndromes : Le VPN indique connecté ; l’app expire ; le ping vers l’NVR échoue.

Cause racine : Route manquante vers le sous‑réseau CCTV ou forwarding absent sur la passerelle VPN.

Correction : Ajoutez la route (ou les AllowedIPs WireGuard) et activez net.ipv4.ip_forward=1. Ajoutez des règles de forwarding pare‑feu pour wg0 → LAN CCTV.

2) « L’UI web se charge mais la vidéo en direct est noire »

Syndromes : La connexion marche ; les menus s’affichent ; le flux refuse de démarrer ou gèle immédiatement.

Cause racine : Problèmes MTU/MSS, ou ports de streaming/SDK requis bloqués.

Correction : Réduisez le MTU WireGuard (essayez 1380 puis 1320) et/ou clamppez le MSS. Confirmez RTSP/ports SDK avec nmap et autorisez‑les uniquement depuis le sous‑réseau VPN.

3) « Ça marche en Wi‑Fi, échoue en cellulaire »

Syndromes : Depuis la connexion domicile ça marche ; sur LTE ça échoue ou est très lent.

Cause racine : CGNAT opérateur + contraintes MTU + optimisations agressives d’économie d’énergie/réseau sur l’OS mobile.

Correction : Utilisez un VPN tolérant la NAT (WireGuard avec persistent keepalive). Fixez un MTU conservateur. Autorisez le VPN mobile à fonctionner en arrière‑plan.

4) « Coupures aléatoires toutes les quelques minutes »

Syndromes : La vue en direct se déconnecte périodiquement ; la reconnexion règle le problème.

Cause racine : Timeout de mappage NAT, keepalives manquants, ou tables d’état du routeur amont saturées.

Correction : Activez le persistent keepalive WireGuard (ex. 25s) sur les clients roaming et les pairs site. Vérifiez les timeouts UDP du routeur ISP.

5) « On a désactivé le P2P mais ça revient sans cesse »

Syndromes : Le DVR apparaît de nouveau en ligne dans le cloud du fournisseur ; des connexions sortantes réapparaissent après des mises à jour.

Cause racine : Une mise à jour de firmware a réinitialisé les réglages, ou plusieurs menus contrôlent la même fonctionnalité.

Correction : Bloquez le trafic sortant du VLAN CCTV vers Internet sauf NTP (et peut‑être les serveurs de mise à jour que vous autorisez explicitement). Traitez le DVR comme non fiable.

6) « La lecture est inutilisable, la vue en direct va bien »

Syndromes : La vue en direct est correcte ; le scrubbing de la lecture bloque ; la timeline charge lentement.

Cause racine : La lecture requiert des rafales et des seeks ; l’uplink sature ou le bufferbloat du WAN ajoute de la latence.

Correction : Appliquez QoS sur l’uplink site, limitez le bitrate pour la lecture distante, et utilisez des sous‑flux pour l’aperçu. Si possible, exportez les clips côté serveur au lieu de streamer la lecture brute.

7) « Un seul utilisateur peut se connecter à la fois »

Syndromes : Le deuxième utilisateur échoue ; ou le premier se fait déconnecter.

Cause racine : Profil/clé VPN partagé ou limites de licence/session du DVR.

Correction : Émettez des clés VPN uniques par utilisateur/appareil. Vérifiez les limites de session de l’NVR et créez des utilisateurs NVR distincts.

8) « L’équipe sécurité dit que le VPN est OK, mais l’équipe caméra dit que c’est le VPN »

Syndromes : Ping‑pong de blâme ; pas de propriétaire clair ; l’incident traîne.

Cause racine : Pas d’observabilité partagée : pas de logs, pas de captures de paquets, pas de SLO défini.

Correction : Centralisez les logs VPN, enregistrez les rejets du pare‑feu, définissez ce que « fonctionner » signifie (temps jusqu’à la première image, perte acceptable), et testez depuis un hôte connu‑bon.

Trois mini‑histoires d’entreprise issues du terrain

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

Une entreprise de taille moyenne avait une config « temporaire » : l’installateur a redirigé des ports vers l’NVR pour que des cadres puissent voir les caméras du hall depuis chez eux.
L’équipe IT a supposé que les ports redirigés étaient des « ports obscurs fournisseur » et donc peu risqués. Personne ne les a consignés.

Des mois plus tard, un audit a signalé un trafic sortant suspect depuis le VLAN de l’enregistreur. L’NVR parlait à des IP aléatoires, à des heures aléatoires.
L’ingénieur sécurité a d’abord vérifié le pare‑feu. Rien d’évident. La deuxième étape : un scan depuis l’extérieur.
C’est là qu’ils ont vu l’UI web de l’NVR saluer tout Internet comme un stagiaire enthousiaste.

La mauvaise hypothèse était subtile : « Notre ISP bloque les connexions entrantes sauf sur demande. » Cela avait été vrai des années auparavant pour un autre plan ISP.
Le plan actuel autorisait l’entrée, et le routeur frontal avait UPnP activé. L’NVR a ouvert ses propres ports après qu’une mise à jour de firmware a réinitialisé les paramètres.

La correction n’a pas été héroïque. Ils ont désactivé UPnP, supprimé toutes les forwards, désactivé le P2P et mis une passerelle WireGuard devant.
Le vrai travail a été procédural : ils ont créé une règle interdisant l’exposition WAN des appareils CCTV, et ajouté un scan externe à la checklist mensuelle.

Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux

Une chaîne de retail voulait un accès plus rapide depuis le siège. Quelqu’un a jugé que le VPN était « une surcharge », ils sont passés au split tunneling avec un routage agressif :
seule l’IP de l’NVR était routée, pas le sous‑réseau caméra. L’idée était de réduire la bande passante et de garder le reste du site inaccessible. Raisonnable sur le papier.

Puis l’app mobile a commencé à échouer de façon imprévisible. La vue en direct fonctionnait parfois, la lecture rarement, et l’export de clips était une pièce de monnaie.
L’équipe a cherché le firmware NVR, accusé l’ISP, et même remplacé le modèle de routeur sur quelques sites.

Le coupable : l’app ne parlait pas uniquement à l’IP de l’NVR. Après la négociation initiale, elle tirait aussi des flux directement depuis les IP des caméras.
Avec le sous‑réseau caméra non routé, l’app arrivait à mi‑parcours puis tombait dans le vide. Différentes versions d’app se comportaient différemment.

L’« optimisation » avait aussi cassé le DNS : l’app résolvait un nom local vers une IP publique quand elle était hors VPN, donc elle essayait parfois d’atteindre une adresse WAN inexistante.
La correction a été de router tout le sous‑réseau CCTV sur le VPN, puis de restreindre l’accès via le pare‑feu (autoriser le sous‑réseau utilisateur vers l’NVR + RTSP si nécessaire, bloquer tout le reste).
Moins malin. Plus correct.

Mini‑histoire 3 : La pratique ennuyeuse qui a sauvé la situation

Sur un site logistique, ils ont déployé une petite passerelle WireGuard avec des règles strictes : drop par défaut, autoriser les clients VPN sur les ports requis de l’NVR, et journaliser les rejets.
Ils ont aussi réservé l’IP de l’NVR via DHCP et documenté le VLAN caméra dans un runbook d’une page.
Rien de fancy. Juste de la supervision adulte.

Une nuit, la visualisation distante a planté pendant une revue d’incident. L’ingénieur de garde n’avait pas de temps pour la magie de l’app.
Il a vérifié le handshake WireGuard : OK. Ping vers l’NVR : OK. Vérif de port : 8000 soudainement fermé.
Cela a orienté le diagnostic loin du VPN et directement vers l’enregistreur.

Les logs de rejets n’ont montré aucun bloc nouveau. La passerelle était calme. L’NVR, en revanche, avait redémarré après une micro‑coupure et revenu avec un service à moitié démarré.
Parce que l’équipe avait des contrôles de base et un chemin connu‑bon, le diagnostic a pris des minutes au lieu d’une réunion interminable.

Ils ont redémarré le service, ajouté l’NVR à une petite onduleur, et configuré la passerelle pour alerter quand l’NVR cesse de répondre sur les ports requis.
Pratique ennuyeuse : des baselines, des logs et un UPS. Cela a sauvé la situation parce que ça a réduit l’espace de recherche.

Listes de contrôle / plan pas à pas

Étape par étape : construire l’accès CCTV via VPN (sans exposition Internet)

1. Inventoriez ce que vous avez. Listez le modèle NVR, le sous‑réseau caméra, la méthode d’accès distant actuelle et quels clients doivent fonctionner (app mobile, UI web, VMS).
2. Supprimez l’exposition WAN. Supprimez toutes les redirections de ports vers DVR/NVR. Désactivez UPnP sur le routeur frontal. Vérifiez depuis l’extérieur que rien ne répond.
3. Choisissez une architecture. Pour un site, VPN road‑warrior vers une passerelle site suffit. Pour de nombreux sites, hub‑and‑spoke est généralement plus propre.
4. Créez un VLAN/sous‑réseau CCTV. Placez les caméras et l’NVR là‑dedans, ou au moins l’NVR. Documentez les adresses et la passerelle par défaut.
5. Déployez la passerelle VPN. Préférez une boîte dédiée que vous gérez (appliance pare‑feu ou mini PC Linux). Évitez d’exécuter des « services » sur l’NVR.
6. Définissez les routes. Assurez‑vous que les clients VPN ont une route vers le sous‑réseau CCTV. Évitez les sous‑réseaux qui se chevauchent entre sites.
7. Appliquez la politique du pare‑feu. Deny par défaut. Autorisez les clients VPN uniquement sur les ports NVR requis (et uniquement vers le sous‑réseau CCTV).
8. Décidez routage vs NAT. Préférez le routage. Utilisez le NAT si le côté CCTV ne peut pas apprendre des routes vers les clients VPN.
9. Réparez le DNS. Fournissez un nom stable pour l’NVR et rendez‑le résolvable via le VPN. Poussez des DNS internes aux clients VPN.
10. Durcissez l’enregistreur. Désactivez P2P, désactivez la gestion WAN, créez des utilisateurs nominatifs, réduisez les privilèges, configurez NTP.
11. Testez depuis trois réseaux. Wi‑Fi bureau, connexion domicile, et cellulaire. Le cellulaire est l’endroit où les rêves MTU viennent mourir.
12. Opérationnalisez. Journalisation, scans périodiques depuis le VPN, sauvegardes de config, et procédure claire de révocation des clés VPN et des comptes NVR.

Checklist de contrôle des changements (parce que « ça marchait la semaine passée » n’est pas un indicateur)

• Exportez/snapshot de la config passerelle VPN avant les changements.
• Consignez les routes et règles pare‑feu actuelles.
• Planifiez les mises à jour firmware DVR/NVR ; ne les faites pas en pleine gestion d’incident.
• Après toute mise à jour, revérifiez : UPnP off, P2P off, ports requis up, synchronisation d’heure correcte.
• Gardez un plan de rollback : config VPN connue‑bonne et image de la passerelle sauvegardée.

Checklist sécurité (sévérité minimale viable)

• Identités VPN par utilisateur ; révoquez à l’offboarding.
• MFA sur le VPN si possible.
• Pas de comptes admin DVR partagés pour la consultation quotidienne.
• Restreindre l’accès des clients VPN aux seuls sous‑réseaux CCTV (moindre privilège).
• Bloquer l’Internet sortant depuis le VLAN CCTV par défaut, autoriser seulement l’essentiel (ex. NTP).
• Journaliser les connexions VPN et les rejets pare‑feu ; conservez les logs assez longtemps pour enquêter.

FAQ

1) Ai‑je vraiment besoin d’un VPN ? Ne puis‑je pas simplement rediriger un port et utiliser un mot de passe fort ?

Vous pouvez, mais vous pariez que le DVR/NVR n’a pas de failles exploitables à distance et que son authentification est robuste. C’est un pari coûteux.
Le VPN réduit l’exposition et vous donne un contrôle centralisé de l’accès. Traitez le DVR comme un service interne, parce que c’en est un.

2) WireGuard ou OpenVPN pour la vidéosurveillance ?

WireGuard pour la plupart des déploiements : plus simple, moins de pièces, comportement généralement meilleur sur les réseaux roaming.
Choisissez OpenVPN si vous avez des intégrations d’authentification d’entreprise existantes difficiles à reproduire, ou si votre environnement standardise sur lui.

3) Dois‑je utiliser le split tunneling ?

Si vous gérez beaucoup d’appareils utilisateurs divers, le split tunneling vous évite de devenir leur fournisseur d’accès.
Mais vous devez éviter les sous‑réseaux qui se chevauchent et veiller à ce que le DNS résolve des adresses internes via le VPN. Pour des appareils gérés, le full‑tunnel est souvent plus simple.

4) Mon application NVR fonctionne localement mais pas via VPN. Pourquoi ?

Causes courantes : l’app s’attend à joindre directement les IP des caméras (pas seulement l’NVR), un port fournisseur requis est bloqué, ou le MTU bloque de plus gros paquets.
Vérifiez les routes vers tout le sous‑réseau CCTV, confirmez les ports avec un scan ciblé et testez le MTU avec des pings DF.

5) Est‑il acceptable de NATer les clients VPN vers le LAN caméra ?

C’est acceptable quand le routage n’est pas faisable (par ex. vous ne pouvez pas ajouter de route côté NVR ou le routeur amont est verrouillé).
Le compromis est l’observabilité et l’attribution par client : l’NVR verra tout l’accès comme venant de l’IP de la passerelle. Préférez le routage quand possible.

6) Comment empêcher le DVR d’appeler les services cloud du fournisseur ?

Désactivez P2P/cloud dans l’UI, puis faites‑le respecter au niveau réseau : bloquez l’accès sortant à Internet depuis le VLAN CCTV par défaut.
Autorisez NTP si nécessaire, et soyez explicite sur tout le reste.

7) Puis‑je utiliser un concentrateur VPN cloud si le site n’a pas d’IP publique ?

Oui. C’est souvent le meilleur modèle : le site initie un tunnel sortant vers le concentrateur, donc aucun port entrant n’est requis sur le site.
Les utilisateurs se connectent aussi au concentrateur. Déterministe, NAT‑friendly et plus simple à standardiser.

8) Quelle est la manière la plus rapide pour savoir si le goulot est la liaison ISP ?

Vérifiez la perte/gigue avec mtr, puis observez ce qui se passe quand plusieurs viewers se connectent. Si la perte augmente ou la latence bondit sous charge,
vous saturez l’uplink ou souffrez de bufferbloat. Corrigez avec QoS, bitrates plus bas, sous‑flux ou un meilleur circuit.

9) Dois‑je exposer RTSP via VPN ?

Seulement si vous avez un client ou un VMS qui utilise RTSP. Si le client NVR utilise un port SDK propriétaire, vous n’aurez peut‑être pas besoin de RTSP du tout.
Exposez l’ensemble minimal de ports requis, au minimum de clients VPN nécessaires.

10) Que penser des outils d’accès Zero Trust à la place d’un VPN ?

Ils peuvent fonctionner, mais beaucoup sont encore du « VPN sous un autre nom » avec des couches politiques supplémentaires. Si vous en avez déjà un avec une identité forte et des contrôles d’appareil,
cela peut bien convenir. Sinon, WireGuard plus un durcissement strict du pare‑feu est souvent plus simple et plus prévisible.

Conclusion : prochaines étapes pratiques

Si votre DVR/NVR est accessible depuis Internet public aujourd’hui, considérez‑le comme une dette technique avec intérêts.
La correction n’est pas compliquée : retirez l’exposition, placez une bordure VPN que vous contrôlez devant, routez délibérément, et verrouillez la politique au minimum.
Testez ensuite sur le pire réseau que vous trouverez (cellulaire) et ajustez le MTU avant que vos utilisateurs ne le fassent en se plaignant.

Prochaines étapes que vous pouvez faire cette semaine :

• Auditez et supprimez toutes les redirections de ports et règles UPnP liées à la vidéosurveillance.
• Mettez en place une passerelle WireGuard et routez un sous‑réseau CCTV dédié via celle‑ci.
• Implémentez un pare‑feu default‑deny avec des autorisations explicites pour les ports NVR requis.
• Désactivez le P2P fournisseur et bloquez l’Internet sortant depuis le VLAN CCTV par défaut.
• Exécutez le guide de diagnostic rapide une fois, documentez les sorties de référence et conservez‑les pour les incidents futurs.

Rendez‑le ennuyeux. L’ennuyeux est fiable. La fiabilité est ce que vous vouliez quand vous avez installé des caméras au départ.