CCTV sobre VPN: Accede a tu DVR/NVR de forma fiable sin exponerlo a Internet

El verdadero modelo de amenazas (y por qué el reenvío de puertos es una trampa)

La mayoría de los sistemas CCTV fallan de dos maneras: se exponen o se vuelven inestables. A veces ambas. La receta habitual es dolorosamente consistente:
alguien reenvía puertos desde Internet hacia el DVR/NVR, quizá cambia la contraseña por defecto (quizá), y luego se pregunta por qué la caja recibe intentos masivos de inicio de sesión,
o por qué un fallo de firmware se convierte en un incidente externo.

Tu DVR/NVR no es un servicio endurecido orientado a Internet. Es un electrodoméstico. A menudo corre una versión antigua de Linux embebido, tiene una interfaz web de procedencia dudosa,
y viene con funciones “útiles” como UPnP y relés P2P del fabricante que son excelentes para demostraciones y terribles para el riesgo.

Contra qué te estás protegiendo

• Relleno de credenciales y fuerza bruta en puertos web/RTSP/SDK. Tus usuarios reutilizarán contraseñas; los atacantes reutilizarán listas.
• Superficies de gestión expuestas: interfaces web, telnet/ssh (a veces ocultos), servicios ONVIF y puertos SDK específicos de vendor.
• Funciones de acceso remoto silenciosas como P2P cloud y UPnP que reabren la exposición después de que creías haberla “arreglado”.
• Movimiento lateral: una vez comprometido el DVR, está en tu LAN junto a todo lo que realmente te importa.
• Fallas de privacidad y cumplimiento: las imágenes de cámara son datos personales en muchas jurisdicciones; “abrimos 37777 al DVR” no es una política.

Qué cambia una VPN

Una VPN no asegura mágicamente un DVR. Lo que hace es reducir drásticamente la superficie de ataque al eliminar el DVR de Internet público.
Entonces pones el control de acceso donde corresponde: en el borde de la VPN, con criptografía moderna, autenticación sensata, registros y un interruptor de muerte para desasignaciones.

La VPN es tu puerta de entrada. El DVR se queda dentro. No le pones una puerta de caja fuerte a un cobertizo.

Broma #1: Reenviar puertos a un DVR es como dejar las llaves de la casa bajo el felpudo—salvo que Internet tiene el mapa de tu felpudo.

Hechos interesantes y contexto histórico

1. El CCTV temprano era circuito cerrado por diseño (1940s–1960s): cables coaxiales, monitores locales, sin enrutamiento. “Acceso remoto” significaba un cable más largo.
2. RTSP data de finales de los 90: estandarizó el control de medios en streaming, y los fabricantes de CCTV lo adoptaron porque era “suficientemente bueno”.
3. ONVIF surgió en 2008 para unificar la interoperabilidad de cámaras IP. Ayudó a la integración, pero también estandarizó servicios detectables en LANs.
4. UPnP (finales de los 90) facilitó que dispositivos de consumo abrieran puertos en el cortafuegos automáticamente—justo lo que no quieres para aparatos de seguridad.
5. Los nubes P2P de fabricantes explotaron en los 2010: evitan NAT para ver móvil fácilmente, a costa de límites de confianza y auditabilidad.
6. Mirai (2016) popularizó botnets IoT abusando credenciales por defecto y servicios expuestos, incluidas cámaras y dispositivos tipo DVR.
7. WireGuard (público en 2018) simplificó las VPN modernas: menos partes móviles, base de código pequeña y menos momentos de “por qué renegocia TLS”.
8. CGNAT en móviles se normalizó: a menudo no puedes “simplemente abrir un puerto” aunque quisieras, lo cual es una bendición disfrazada.

Arquitecturas de referencia que realmente funcionan

1) VPN «road-warrior» hacia una pasarela en el sitio (más común)

Coloca una pequeña pasarela VPN en el sitio de las cámaras (un appliance firewall, un mini PC o un router capaz).
Tu teléfono/portátil se conecta a la pasarela, y la pasarela te enruta al VLAN/subred CCTV. El DVR/NVR no tiene exposición pública.

• Mejor para: sitio único, unos pocos usuarios remotos, patrones de acceso previsibles.
• Buenas características: simple, auditable, sin dependencia de la nube del fabricante.
• Advertencias: enrutamiento y DNS. También problemas de MTU en LTE son un sitcom recurrente.

2) VPN sitio-a-sitio entre oficinas y el sitio de cámaras (para SOC/NOC)

Si tienes una sala de operaciones de seguridad o monitorización central, sitio-a-sitio es más limpio. Los usuarios remotos se conectan a la VPN corporativa como siempre,
y la red corporativa puede alcanzar el sitio de cámaras a través del túnel.

• Mejor para: múltiples sitios, monitorización central, controles de acceso estandarizados.
• Buenas características: políticas y registros consistentes.
• Advertencias: subredes superpuestas, control de cambios y “quién posee la tabla de rutas”.

3) Hub-and-spoke con un concentrador VPN central (escala y consistencia)

Cada sitio ejecuta un túnel hacia un nodo central (nube o datacenter). Los usuarios se conectan al mismo nodo central. Esto es operacionalmente limpio:
un lugar para gestionar identidades, un lugar para registrar, un lugar para aplicar límites.

• Mejor para: muchos sitios, acceso remoto consistente, gobernanza centralizada.
• Buenas características: la baja de acceso es inmediata; puedes aplicar MFA y postura de dispositivo en un único borde.
• Advertencias: ahora ejecutas un servicio central. Diseñarlo en serio.

Qué no hacer

Evita “servidor VPN en el DVR” a menos que disfrutes depurar firmware cerrado.
Evita “abrir un puerto y poner en lista blanca la IP de la oficina” a menos que estés seguro de que cada usuario remoto nunca saldrá de la oficina.
Y evita P2P del fabricante cuando necesites auditoría, determinismo o cualquier historia de cumplimiento que sobreviva a una reunión con Legal.

Elegir la VPN: WireGuard, OpenVPN, IPsec o “nube del fabricante”

WireGuard: la elección por defecto para 2025

WireGuard es ligero, rápido y predecible. Usa criptografía moderna, tiene una superficie de configuración mínima y tiende a comportarse bien en enlaces inestables.
Para CCTV, eso no son lujos. Son la diferencia entre “funciona desde el aparcamiento” y “funciona siempre”.

Operacionalmente, WireGuard también es refrescantemente honesto: si no alcanzas el endpoint, no lo alcanzas. No hay “el apretón de manos TLS tuvo éxito pero las rutas no”.
Esa simplicidad paga dividendos cuando estás depurando a las 03:00.

OpenVPN: aún útil, sobre todo cuando necesitas integración empresarial

OpenVPN es más antiguo y pesado, pero tiene herramientas maduras alrededor de la gestión de certificados y autenticación de usuarios, y un largo historial.
Si debes integrar con infraestructuras existentes (RADIUS, ciertos modelos de distribución cliente, appliances legados), OpenVPN puede ser la opción pragmática.

IPsec: excelente cuando ya lo tienes en todas partes

IPsec sitio-a-sitio puede ser excelente, especialmente con firewalls decentes. Pero las peculiaridades de interoperabilidad, las configuraciones de fase y las abstracciones de UI del vendor
pueden convertir un enrutamiento simple en una danza interpretativa. Si tu entorno ya es IPsec-heavy, manténlo. Si no, no empieces por ahí solo para acceder cámaras.

Nube P2P del fabricante: conveniente, opaca y arriesgada

La P2P del fabricante existe porque el NAT traversal es difícil y la gente quiere “escanea un código QR y funciona”.
También significa que tu acceso de vídeo puede depender de relés externos, prácticas de registro desconocidas y apps cliente que se actualizan por su cuenta.
Si te importa la continuidad y la seguridad, quieres menos dependencias, no más.

Idea parafraseada atribuida a Gene Kranz: “Duro y competente” es el estándar—los sistemas deben comportarse bajo presión, no requerir heroísmos.

Diseño de red: subredes, enrutamiento, DNS y no abrir agujeros en las paredes

Segmenta las cámaras y el grabador

Coloca cámaras y el DVR/NVR en un VLAN/subred dedicada. No porque los VLANs sean mágicos, sino porque te obligan a definir políticas.
Puedes permitir que el NVR hable con las cámaras, permitir que tus clientes VPN hablen con el NVR y bloquear todo lo demás por defecto.

Si tu grabador tiene dos NICs (LAN + cámara), úsalas correctamente: un lado para tráfico de cámaras, otro para acceso de administración/cliente.
De lo contrario, al menos separa con VLANs y reglas de firewall.

Decide: túnel completo o dividido

• Túnel dividido: solo las subredes CCTV van por la VPN. Menos ancho de banda, menos sorpresas. Requiere más cuidado para evitar fuga de DNS o conflictos locales.
• Túnel completo: todo el tráfico va por la VPN. Más control y comportamiento consistente, pero ahora eres el proveedor de Internet del usuario. Planifica capacidad.

Para acceso CCTV, el túnel dividido suele ser suficiente si haces bien el DNS y evitas subredes solapadas.
Para dispositivos gestionados, el túnel completo puede ser más limpio porque puedes aplicar políticas y registros.

Enrutamiento: hazlo explícito

La VPN no es “magia de acceso remoto”. Es enrutamiento más cifrado. Si un usuario se conecta pero no alcanza el NVR, el 90% de las veces es un problema de rutas,
de firewall o de MTU. El otro 10% es que el NVR está siendo un NVR.

DNS: elige una estrategia que puedas soportar

No confíes en que los usuarios escriban direcciones IP para siempre. Dale al NVR un nombre estable como nvr.site1.lan y haz que sea resolvible por la VPN.
Puedes hacerlo con DNS interno, servidores DNS empujados vía VPN o incluso entradas estáticas en hosts como solución temporal (no recomendado a escala).

Autenticación y autorización: trátalo como producción

Usa identidades por usuario siempre que sea posible. Usa MFA para la VPN si puedes. No compartas un único perfil VPN “security@company” entre diez teléfonos.
Eso no es control de acceso. Es pensamiento mágico con logo.

Endurecimiento del lado CCTV: DVR/NVR, cámaras y el problema de las apps

Desactiva las funciones de exposición “útiles”

En el DVR/NVR y en el router/firewall aguas arriba:

• Desactiva UPnP.
• Desactiva P2P/relés en la nube del fabricante a menos que tengas una razón formal y aceptación de riesgo.
• Desactiva la gestión remota desde WAN.
• Restringe las interfaces de gestión a la subred de la VPN.

Bloquea las cuentas

• Crea cuentas nombradas, no compartidas.
• Elimina o desactiva cuentas por defecto (o al menos cambia credenciales y reduce privilegios).
• Aplica el principio de menor privilegio: usuarios solo de visualización no deberían poder actualizar firmware.

Firmware y sincronización de tiempo

Mantén el firmware actualizado, pero no “actualices automáticamente” un grabador en producción sin un plan de reversión.
También asegúrate de que el grabador y las cámaras tengan la hora correcta vía NTP. La hora incorrecta rompe registros, certificados y a veces el indexado de la reproducción.

Broma #2: Lo único más confiado que la interfaz web de un DVR es un controlador de impresora—ambos creen que son el servicio más importante en tu red.

Ingeniería de fiabilidad: latencia, MTU, NAT y por qué el vídeo desenmascara redes

Matemática de ancho de banda: no adivines

Una sola transmisión 1080p H.264 puede ser de 2–6 Mbps dependiendo de la configuración de bitrate, movimiento, complejidad de escena y optimismo del fabricante.
Multiplica por el número de vistas simultáneas o transmisiones de reproducción. Luego suma overhead por encapsulación VPN y retransmisiones en enlaces malos.

Para reproducción remota, los usuarios a menudo rebobinan la línea temporal y generan ráfagas de tráfico. Eso no es “una transmisión constante”, es “acceso aleatorio con picos”.
Si tu enlace ascendente es asimétrico (típico cable/ADSL), el upstream del sitio es el limitador.

La latencia y el jitter importan más de lo que crees

La vista en vivo tolera algo de latencia, pero no jitter ni pérdida de paquetes. La reproducción puede ser peor: puede solicitar keyframes o saltar,
y algunos clientes de vendor reaccionan mal al reordenamiento o a retrasos.

MTU: el asesino silencioso

La VPN añade cabeceras. En enlaces con MTU de ruta menor (LTE, PPPoE, algunos escenarios DOCSIS), verás síntomas extraños:
páginas de login que cargan pero el vídeo no, o pings pequeños que funcionan pero la app caduca.
Arreglar MTU/MSS clamping es una de las tareas menos glamorosas en redes—y una de las más efectivas.

NAT traversal: elige diseños deterministas

Si el sitio de cámaras está detrás de un NAT que no controlas, un modelo “servidor en la nube + sitio como cliente” suele ser mejor:
el sitio inicia el túnel hacia afuera, así no se requieren puertos entrantes.
Ese patrón es limpio para localizaciones retail, obras y cualquier sitio donde el router ISP esté “gestionado por quien lo instaló en 2017”.

Registro y observabilidad

Si no puedes responder “quién se conectó, desde dónde y qué alcanzó”, no tienes acceso remoto—tienes un misterio.
Registra las conexiones VPN, asigna IPs cliente estables y graba los bloqueos/aceptaciones del firewall para las subredes CCTV.

Tareas prácticas: comandos, salidas y qué decides a partir de ellas

Estos son chequeos probados en campo que puedes ejecutar desde una pasarela VPN Linux o un jump host en la VPN. Cada tarea incluye: un comando, salida realista,
lo que significa y la decisión siguiente.

Tarea 1: Verificar que la interfaz VPN esté activa y con la dirección correcta

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

Significado: La interfaz wg0 existe y tiene 10.60.0.1/24. El estado UNKNOWN es normal para WireGuard.
Decisión: Si la interfaz falta o tiene la subred equivocada, arregla la configuración de WireGuard antes de perseguir problemas de cámara.

Tarea 2: Comprobar la frescura del handshake del peer de WireGuard

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

Significado: El peer del sitio está vivo (handshake en el último minuto). Allowed IPs incluye la subred de cámaras 10.20.30.0/24.
Decisión: Si el handshake es “never”, no estás conectado—revisa alcance del endpoint, NAT, claves y firewall.

Tarea 3: Confirmar que existen rutas a la subred CCTV

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

Significado: El tráfico a la subred de cámaras va vía la VPN.
Decisión: Si no hay ruta, añádela (o corrige AllowedIPs si usas WireGuard con policy routing).

Tarea 4: Probar la alcanzabilidad básica a la IP del NVR

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

Significado: ICMP funciona; la latencia es ~35ms, adecuada para visualización.
Decisión: Si ping falla, no culpes todavía a la app—verifica enrutamiento y firewall. Si ping funciona pero el vídeo falla, pasa a comprobaciones de puertos y MTU.

Tarea 5: Identificar qué puertos expone el NVR (sin adivinar)

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

Significado: Interfaz web en 80, RTSP en 554, servicio del fabricante en 8000. El puerto 37777 está filtrado (probablemente bloqueado por firewall).
Decisión: Asegura que solo los puertos necesarios sean accesibles desde clientes VPN; bloquea el resto. Si tu cliente necesita 37777, has encontrado por qué falla.

Tarea 6: Confirmar que la política de firewall hace lo que crees

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
  }
}

Significado: Drop por defecto, permisos explícitos desde VPN hacia subred CCTV. Esa es la forma correcta.
Decisión: Si faltan reglas de reenvío, los clientes VPN se conectarán pero no alcanzarán las cámaras. Añade las reglas mínimas de forward.

Tarea 7: Verificar que el reenvío de IP esté activado en la pasarela VPN

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

Significado: La máquina enruta paquetes.
Decisión: Si es 0, actívalo y persiste en /etc/sysctl.d/. Sin ello, “la VPN funciona” pero nada detrás de ella lo hace.

Tarea 8: Comprobar NAT (solo si intencionalmente NATeas clientes VPN a la LAN CCTV)

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
  }
}

Significado: Las direcciones origen de clientes VPN se enmascaran al salir por lan0.
Decisión: NAT es un parche cuando el NVR/cámara no puede enrutar de vuelta a la subred VPN. Prefiere enrutamiento, pero NAT es aceptable cuando hace falta.

Tarea 9: Probar conectividad TCP al UI web del grabador

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

Significado: HTTP responde rápidamente. La ruta está abierta.
Decisión: Si esto caduca, revisa firewall y rutas. Si devuelve 401/403, eso es aplicación/autenticación, no red.

Tarea 10: Comprobar accesibilidad RTSP (común para integraciones VMS)

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

Significado: El puerto 554 es alcanzable a nivel TCP.
Decisión: Si TCP está bloqueado pero esperabas RTSP, ábrelo solo a los clientes necesarios o proxifícalo a través del VMS, no a todos.

Tarea 11: Buscar problemas de MTU con pings “no fragmentar”

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

Significado: Tu MTU efectiva es menor de la esperada; paquetes grandes no pasarán sin fragmentación.
Decisión: Baja el MTU de WireGuard (p.ej., 1280–1380) o aplica MSS clamping en la pasarela. Esto suele arreglar “la UI carga, el vídeo falla”.

Tarea 12: Medir pérdida y jitter con 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

Significado: 2% de pérdida hacia el NVR. El vídeo se entrecortará; la reproducción te odiará.
Decisión: Investiga la calidad del enlace en el sitio (backhaul Wi‑Fi, ISP, LTE). Considera reducir el bitrate de la transmisión o habilitar substreams adaptativos.

Tarea 13: Confirmar que el NVR realmente escucha en los puertos esperados (desde la LAN del NVR)

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))

Significado: Los servicios están ligados a todas las interfaces. Si clientes remotos no pueden conectar, no es porque el NVR no esté escuchando.
Decisión: Enfócate en enrutamiento/firewall/NAT. Si los puertos no escuchan, arregla la configuración o el estado del servicio del NVR.

Tarea 14: Comprobar agotamiento de conntrack en la pasarela VPN (sí, el vídeo puede causar esto)

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

Significado: Bastante margen. Si las entradas están cerca del máximo, las nuevas conexiones pueden fallar intermitentemente.
Decisión: Si estás cerca del máximo, aumenta límites de conntrack y/o reduce ruido (desactiva descubrimiento, reduce polling de clientes, limita visualizadores concurrentes).

Tarea 15: Verificar sincronización de hora en la pasarela VPN (ayuda en logs y validación de certificados)

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

Significado: La hora está sincronizada. Bien.
Decisión: Si no está sincronizada, arregla NTP. La hora incorrecta hace que la resolución de problemas sea imposible y puede romper VPNs basadas en TLS.

Tarea 16: Capturar tráfico para ver si la app siquiera lo intenta (y qué intenta)

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

Significado: SYN/SYN-ACK/ACK completa. La conectividad existe; el cliente intenta HTTP.
Decisión: Si ves SYNs sin replies, es firewall/enrutamiento. Si no ves ningún paquete, es enrutamiento/DNS del cliente o configuración de túnel dividido.

Guía de diagnóstico rápido

Cuando el acceso remoto CCTV falla, puedes perder horas en ajustes de apps. No lo hagas. Encuentra el cuello de botella rápido con una secuencia predecible.

Primero: confirma que el túnel es real

• En el servidor/pasarela VPN: comprueba frescura del handshake (wg show o estado de OpenVPN).
• En el cliente: confirma que recibió la IP VPN esperada y las rutas.
• Decisión: si el túnel no está arriba, para. Arregla claves, alcance del endpoint, NAT/puerto o autenticación.

Segundo: confirma el enrutamiento hacia la subred CCTV

• Revisa la tabla de rutas en servidor y cliente.
• Pingea la IP del NVR desde un host conocido y sano en la VPN.
• Decisión: si el ping falla, no es un “problema del NVR”. Es enrutamiento/firewall/NAT.

Tercero: confirma puertos y políticas

• Escanea solo los puertos esperados desde el lado VPN (nmap).
• Valida reglas de firewall y reenvío.
• Decisión: abre solo lo que necesites; si la app requiere un puerto SDK del fabricante, permítelo solo desde clientes VPN.

Cuarto: sospecha de MTU y pérdida

• Ejecuta pings DF y mtr al NVR.
• Decisión: si paquetes grandes fallan o la pérdida es significativa, ajusta MTU/MSS, reduce bitrate o arregla el enlace WAN.

Quinto: culpa a la aplicación, con cautela

• Usa tcpdump para confirmar qué intenta el cliente.
• Prueba accesos alternativos (UI web vs app móvil vs RTSP).
• Decisión: si la red está bien, el problema probablemente sea autenticación, firmware, configuraciones de códec o un bug del cliente.

Errores comunes: síntomas → causa raíz → solución

1) “La VPN conecta pero no puedo alcanzar el NVR”

Síntomas: La VPN muestra conectada; la app caduca; el ping al NVR falla.

Causa raíz: Falta la ruta a la subred CCTV o falta el reenvío en la pasarela VPN.

Solución: Añade la ruta (o WireGuard AllowedIPs) y habilita net.ipv4.ip_forward=1. Añade reglas de firewall forward para wg0 → LAN CCTV.

2) “La UI web carga pero el vídeo en vivo está en negro”

Síntomas: Login funciona; los menús cargan; la transmisión no arranca o se congela inmediatamente.

Causa raíz: Problemas de MTU/MSS, o puertos de streaming/SDK requeridos bloqueados.

Solución: Baja MTU de WireGuard (prueba 1380 luego 1320) y/o aplica MSS clamping. Confirma RTSP/puertos SDK con nmap y permite solo desde la subred VPN.

3) “Funciona en Wi‑Fi, falla en celular”

Síntomas: Desde banda ancha doméstica funciona; en LTE falla o va muy lento.

Causa raíz: CGNAT del operador + restricciones de MTU + optimizaciones agresivas de batería/red en el SO móvil.

Solución: Usa una VPN que tolere NAT (WireGuard con persistent keepalive). Ajusta MTU conservador. Asegura que la VPN móvil pueda ejecutarse en segundo plano.

4) “Se corta aleatoriamente cada pocos minutos”

Síntomas: La vista en vivo se desconecta periódicamente; reconectar lo arregla.

Causa raíz: Timeout de mapeo NAT, falta de keepalives o problemas con la tabla de estado del router aguas arriba.

Solución: Habilita persistent keepalive de WireGuard (p.ej., 25s) en clientes móviles y peers del sitio. Revisa timeouts UDP del router ISP.

5) “Desactivamos P2P pero vuelve”

Síntomas: El DVR aparece online en la nube del fabricante otra vez; conexiones salientes reaparecen tras actualizaciones.

Causa raíz: Una actualización de firmware reseteó ajustes, o múltiples menús controlan la misma función.

Solución: Bloquea tráfico saliente desde la VLAN CCTV hacia Internet excepto NTP (y tal vez servidores de actualización permitidos explícitamente). Trata al DVR como no confiable.

6) “La reproducción es inutilizable, la vista en vivo está bien”

Síntomas: La vista en vivo va bien; la reproducción y el scrubbing se cuelgan; la línea temporal carga lento.

Causa raíz: La reproducción solicita ráfagas y seeks; el uplink se satura o hay bufferbloat en el camino WAN que añade latencia.

Solución: Aplica QoS en el uplink del sitio, limita bitrate de reproducción remota y usa substreams para vista previa. Si es posible, exporta clips en el servidor en vez de transmitir la reproducción cruda.

7) “Solo un usuario puede conectarse a la vez”

Síntomas: El segundo usuario falla; o el primero es expulsado.

Causa raíz: Perfil/clave VPN compartida o límites de licencia/sesión del DVR.

Solución: Emite claves VPN únicas por usuario/dispositivo. Revisa límites de sesiones del NVR y crea usuarios NVR distintos.

8) “Seguridad dice que la VPN está bien, pero cámaras dicen que es la VPN”

Síntomas: Intercambio de culpas; sin dueño claro; el incidente se prolonga.

Causa raíz: Falta de observabilidad compartida: no hay logs, no hay capturas de paquetes, no hay SLO definido.

Solución: Centraliza logs de la VPN, registra denegaciones del firewall, define qué significa “funciona” (tiempo al primer frame, pérdida aceptable) y prueba desde un host conocido.

Tres micro-historias corporativas desde el terreno

Micro-historia 1: El incidente causado por una suposición errónea

Una empresa mediana tenía una configuración “temporal”: el instalador reenvió puertos al NVR para que ejecutivos pudieran ver las cámaras del vestíbulo desde casa.
El equipo de TI asumió que los puertos reenviados eran “puertos poco conocidos del fabricante” y por tanto de bajo riesgo. Nadie los documentó.

Meses después, una auditoría detectó tráfico saliente sospechoso desde la VLAN del grabador. El NVR hablaba con IPs aleatorias, a horas aleatorias.
El ingeniero de seguridad hizo lo que todos hacemos primero: revisó el firewall. Nada obvio. El segundo paso: ejecutó un escaneo desde fuera.
Entonces vieron la interfaz web del NVR saludando a todo Internet como un becario entusiasta.

La suposición equivocada fue sutil: “Nuestro ISP bloquea conexiones entrantes a menos que se solicite.” Eso había sido cierto años atrás para otro plan.
El plan actual permitía entrantes, y el router de borde tenía UPnP activado. El NVR abrió sus propios puertos tras una actualización de firmware que reseteó ajustes.

La solución no fue heroica. Desactivaron UPnP, eliminaron todos los forwards, deshabilitaron P2P y pusieron un gateway WireGuard delante.
El trabajo real fue de proceso: crearon una regla que dispositivos CCTV nunca deben tener exposición directa a WAN, y añadieron un escaneo externo al checklist mensual.

Micro-historia 2: La optimización que salió mal

Una cadena retail quería vistas remotas más rápidas desde HQ. Alguien decidió que la VPN era “overhead”, así que hicieron túnel dividido con rutas agresivas:
solo se enrutó la IP del NVR, no la subred de cámaras. La idea era reducir ancho de banda y mantener lo demás del sitio fuera de alcance. Razonable en papel.

Entonces la app móvil empezó a fallar de forma impredecible. La vista en vivo a veces funcionaba, la reproducción raramente, y exportar clips era una moneda lanzada al aire.
El equipo persiguió el firmware del NVR, culpó al ISP e incluso cambió modelo de router en algunos sitios.

El culpable: la app no solo hablaba con la IP del NVR. También extraía streams directamente de IPs de cámara tras la negociación inicial.
Con la subred de cámaras no enrutada, la app quedaba a medio camino y se caía del acantilado. Diferentes versiones de la app se comportaban distinto.

La “optimización” también rompió DNS: la app resolvía un nombre local a una IP pública cuando estaba fuera de la VPN, así que ocasionalmente intentaba alcanzar una dirección WAN inexistente.
Arreglarlo implicó enrutar toda la subred CCTV sobre la VPN y luego restringir acceso vía firewall (permitir subnet de usuarios al NVR + RTSP según necesidad, negar todo lo demás).
Menos ingenioso. Más correcto.

Micro-historia 3: La práctica aburrida que salvó el día

En un sitio logístico, ejecutaban una pequeña pasarela WireGuard con reglas estrictas: drop por defecto, permitir clientes VPN a puertos del NVR y registrar denegaciones.
También fijaron la IP del NVR con reserva DHCP y documentaron la VLAN de cámaras en un runbook de una página.
Nada sofisticado. Solo supervisión adulta.

Una noche, la visualización remota se rompió durante una revisión de incidente. El ingeniero on-call no tenía tiempo para vudú de apps.
Revisó el handshake de WireGuard: bien. Ping al NVR: bien. Comprobación de puertos: 8000 de repente cerrado.
Eso apuntó fuera de la VPN y directamente al grabador.

Los logs de denegación no mostraron bloqueos nuevos. La pasarela estaba tranquila. El NVR, sin embargo, se había reiniciado tras un parpadeo de energía y volvió con un servicio medio iniciado.
Porque el equipo tenía chequeos base y una ruta conocida buena, el diagnóstico tomó minutos en vez de una reunión de comité.

Reiniciaron el servicio, añadieron el NVR a una pequeña UPS y configuraron la pasarela para alertar cuando el NVR dejara de responder en puertos requeridos.
Práctica aburrida: líneas base, logs y una UPS. Salvó el día porque redujo el espacio de búsqueda.

Listas de verificación / plan paso a paso

Paso a paso: construir acceso CCTV por VPN (sin exposición a Internet)

1. Inventario de lo que tienes. Lista modelo de NVR, subred de cámaras, método actual de acceso remoto y qué clientes deben funcionar (app móvil, UI web, VMS).
2. Eliminar exposición a WAN. Borra todos los reenvíos de puerto al DVR/NVR. Desactiva UPnP en el router de borde. Verifica desde fuera que nada responde.
3. Elige una arquitectura. Para un sitio, road-warrior a una pasarela en sitio está bien. Para muchos sitios, hub-and-spoke suele ser más limpio.
4. Crea una VLAN/subred CCTV. Coloca cámaras y NVR allí, o al menos el NVR. Documenta direccionamiento y gateway por defecto.
5. Despliega pasarela VPN. Prefiere una caja dedicada que gestiones (appliance firewall o mini PC Linux). Evita ejecutar “servicios” en el NVR.
6. Define rutas. Asegura que clientes VPN tengan ruta a la subred CCTV. Evita subredes solapadas entre sitios.
7. Aplica política de firewall. Denegar por defecto. Permitir a clientes VPN solo los puertos requeridos del NVR (y solo a la subred CCTV).
8. Decide entre enrutamiento y NAT. Prefiere enrutamiento. Usa NAT si el lado CCTV no puede aprender rutas hacia clientes VPN.
9. Arregla DNS. Proporciona un nombre estable para el NVR y hazlo resolvible por la VPN. Empuja servidores DNS internos a clientes VPN.
10. Endurece el grabador. Desactiva P2P, desactiva gestión WAN, crea usuarios nombrados, reduce privilegios, ajusta NTP.
11. Prueba desde tres redes. Wi‑Fi de oficina, banda ancha doméstica y celular. El celular es donde los sueños de MTU van a morir.
12. Operacionaliza. Registros, escaneos periódicos desde la VPN, respaldos de configuraciones y un procedimiento claro de offboarding para claves VPN y cuentas NVR.

Checklist de control de cambios (porque “funcionó la semana pasada” no es una métrica)

• Snapshot/exporta la config de la pasarela VPN antes de cambios.
• Registra rutas actuales y reglas de firewall.
• Programa actualizaciones de firmware DVR/NVR; no las hagas en medio de un incidente.
• Tras cualquier actualización, re-verifica: UPnP off, P2P off, puertos requeridos up, sincronización de tiempo correcta.
• Mantén un plan de reversión: config VPN conocida buena e imagen de respaldo de la pasarela.

Checklist de seguridad (seriedad mínima viable)

• Identidades VPN por usuario; revoca al offboarding.
• MFA en la VPN si es posible.
• No usar cuentas admin compartidas del DVR para visualización diaria.
• Restringir acceso de clientes VPN solo a subredes CCTV (principio de menor privilegio).
• Bloquear salida a Internet desde la VLAN CCTV por defecto, permitir solo lo estrictamente necesario (p.ej., NTP).
• Registrar conexiones VPN y denegaciones del firewall; conserva logs el tiempo suficiente para investigar incidentes.

Preguntas frecuentes

1) ¿Realmente necesito una VPN? ¿No puedo simplemente reenviar puertos y usar una contraseña fuerte?

Puedes, pero estás apostando a que el DVR/NVR no tiene bugs explotables a distancia y que su autenticación es robusta. Esa es una apuesta cara.
La VPN reduce la exposición y te da control central sobre el acceso. Usa el DVR como un servicio interno, porque eso es lo que es.

2) ¿WireGuard u OpenVPN para CCTV?

WireGuard para la mayoría de despliegues: más simple, menos partes móviles, comportamiento generalmente mejor en redes con roaming.
Elige OpenVPN si tienes requisitos de integración de autenticación empresarial existentes difíciles de replicar, o si tu entorno ya estandariza en ello.

3) ¿Debería usar túnel dividido?

Si gestionas muchos dispositivos de usuario diversos, el túnel dividido evita que te conviertas en su ISP.
Pero debes evitar subredes solapadas y asegurar que DNS resuelva direcciones internas sobre la VPN. Para dispositivos corporativos gestionados, el túnel completo suele ser más limpio.

4) Mi app NVR funciona localmente pero no sobre VPN. ¿Por qué?

Razones comunes: la app espera alcanzar IPs de cámara directamente (no solo el NVR), falta un puerto del fabricante, o MTU rompe paquetes grandes.
Verifica rutas a toda la subred CCTV, confirma puertos con un scan dirigido y prueba MTU con pings DF.

5) ¿Está bien NATear clientes VPN a la LAN de cámaras?

Está bien cuando el enrutamiento no es factible (por ejemplo, no puedes añadir una ruta en el lado del NVR o el router aguas arriba está bloqueado).
El intercambio es observabilidad y atribución por cliente: el NVR verá todo el acceso como la IP de la pasarela. Prefiere enrutamiento cuando puedas.

6) ¿Cómo evito que el DVR llame a servicios en la nube del fabricante?

Desactiva P2P/nube en la UI, luego haz cumplir lo anterior en la capa de red: bloquea salida a Internet desde la VLAN CCTV por defecto.
Permite NTP si necesitas sincronización de tiempo, y sé explícito sobre cualquier otra excepción.

7) ¿Puedo usar un concentrador VPN en la nube si el sitio no tiene IP pública?

Sí. A menudo es el mejor patrón: el sitio inicia un túnel saliente al concentrador, así no se necesitan puertos entrantes en el sitio.
Los usuarios también se conectan al concentrador. Determinista, amigable con NAT y más fácil de estandarizar.

8) ¿Cuál es la forma más rápida de saber si el cuello de botella es el uplink del ISP?

Comprueba pérdida/jitter con mtr, luego observa qué pasa cuando múltiples visualizadores se conectan. Si la pérdida aumenta o la latencia pega picos bajo carga,
estás saturando el uplink o sufres bufferbloat. Arregla con QoS, bitrates más bajos, substreams o un circuito mejor.

9) ¿Necesito exponer RTSP sobre la VPN?

Solo si tienes un cliente o VMS que use RTSP. Si el cliente del NVR usa un puerto SDK propietario, puede que no necesites RTSP en absoluto.
Expón el conjunto mínimo de puertos requeridos, al conjunto mínimo de clientes VPN.

10) ¿Y usar herramientas de acceso Zero Trust en lugar de una VPN?

Pueden funcionar, pero muchas son todavía “VPN con otro nombre” con capas de política extra. Si ya ejecutas una con identidad fuerte y controles de dispositivo,
puede encajar muy bien. Si no, WireGuard más firewall estricto suele ser más simple y predecible.

Conclusión: próximos pasos prácticos

Si tu DVR/NVR hoy es accesible desde Internet público, trátalo como deuda técnica con interés.
La solución no es complicada: elimina la exposición, coloca un borde VPN que controles delante, enruta deliberadamente y aplica políticas al mínimo.
Luego pruébalo en la peor red que puedas encontrar (celular) y ajusta el MTU antes de que tus usuarios lo hagan por ti quejándose.

Próximos pasos que puedes hacer esta semana:

• Auditar y eliminar todos los reenvíos de puertos y reglas UPnP relacionadas con CCTV.
• Levantar una pasarela WireGuard y enrutar una subred CCTV dedicada a través de ella.
• Implementar firewall por defecto-denegar con permisos explícitos para puertos NVR requeridos.
• Desactivar P2P del fabricante y bloquear salida a Internet desde la VLAN CCTV por defecto.
• Ejecutar la guía de diagnóstico rápido una vez, documentar las salidas base y conservarlas para cuando algo falle.

Hazlo aburrido. Lo aburrido es fiable. Lo fiable es lo que querías cuando instalaste cámaras en primer lugar.