VPN de oficina para CCTV: Accede a cámaras y NVR sin IP pública

Quieres ver una cámara en vivo desde casa, o dar acceso a un gerente regional a un NVR, pero el sitio no tiene IP pública, no quiere reglas entrantes en el firewall y no desea convertirse en la noticia de mañana. Clásico.

La buena noticia: este es uno de esos problemas que la industria ya resolvió. La mala noticia: la gente sigue re-inventándolo con nubes de proveedores, reenvíos de puertos aleatorios y oraciones. Construyamos lo aburrido y correcto: una VPN de oficina que alcance los dispositivos CCTV de forma limpia—sin exponerlos a Internet público.

Lo que realmente estás construyendo (y lo que no)

“Acceder a cámaras/NVR sin IP pública” no es una solicitud de función. Es un problema de topología, más un problema de autenticación y, además, un problema de “no colapsar el enlace ascendente”.

Lo que estás construyendo es una red de superposición (VPN) que proporciona:

• Alcanzabilidad: Una ruta estable desde el portátil del operador (o la red de la oficina) hasta la VLAN de cámaras/subred del NVR.
• Identidad: Una forma de saber quién se está conectando (y de evitar que ex empleados “solo revisen una cosa”).
• Política: Reglas que permiten solo los puertos y destinos necesarios.
• Observabilidad: Registros y métricas para que puedas demostrar que funciona y diagnosticar rápidamente cuando no lo hace.

Lo que no estás construyendo:

• Un portal web accesible públicamente que reenvíe puertos de la interfaz de cámara al mundo.
• Un “reenvío de puerto rápido” a RTSP/HTTP porque alguien tiene prisa.
• Una dependencia de la nube de un proveedor que silenciosamente se convierta en tu perímetro.

La verdad cruda: la mayoría de los dispositivos CCTV no son defendibles en Internet público. Incluso los decentes traen servicios raros, OpenSSL obsoleto y código de UI que hace que tu navegador haga cosas cuestionables. Dales espacio privado, pon un portero en la puerta y asegúrate de que el portero esté sobrio.

Un chiste corto, como prometido y racionado: La forma más rápida de “asegurar” una cámara es desconectarla—también la forma más rápida de recibir una llamada de Instalaciones.

Hechos interesantes y breve historia que importan

Estos no son datos para presumir en una trivia. Cada uno de estos puntos empuja tus decisiones de diseño.

1. NAT fue una solución temporal: Network Address Translation se volvió común a mediados de los 90 principalmente porque el agotamiento de IPv4 ya se hacía notar. Las VPN crecieron en un mundo donde “sin IP pública” se volvió normal, no excepcional.
2. IPsec es anterior a la mayoría de las cámaras IP: IPsec se estandarizó a finales de los 90, mucho antes del boom de despliegues CCTV. La herramienta es madura, pero la complejidad operativa es real.
3. RTSP es más antiguo que la mayoría del firmware de cámaras: RTSP (finales de los 90) sigue siendo el protocolo central para muchas transmisiones de cámara. Funciona; también es fácil de filtrar si lo enrutas mal.
4. UPnP se diseñó para conveniencia: Hizo que las redes domésticas “simplemente funcionaran” al abrir huecos en NAT. En despliegues CCTV, UPnP es cómo publicas accidentalmente una UI de NVR a Internet.
5. Las credenciales por defecto fueron normales: Los primeros dispositivos embebidos venían con “admin/admin” como norma cultural. Muchos dispositivos modernos mejoraron, pero el ecosistema aún arrastra ese legado.
6. Los botnets amaban las cámaras: Botnets a gran escala reclutaban DVRs/NVRs y cámaras porque eran alcanzables, sin parches y siempre encendidos. Si tu método de acceso los hace alcanzables, los estás ofreciendo.
7. “Nube P2P de cámaras” es básicamente NAT traversal: Muchos proveedores dependen de conexiones salientes a un servicio de rendezvous para evitar IPs públicas. Es ingenioso, pero también significa que tu perímetro incluye a un tercero y su sistema de cuentas.
8. WireGuard es intencionalmente mínimo: Fue diseñado para reducir trampas de configuración y tamaño de código. Eso importa cuando quieres operaciones fiables, no una sesión semanal de “por qué dejó de funcionar el túnel”.
9. La mayoría de incidentes son de enrutamiento, no de criptografía: En producción, la criptografía VPN suele funcionar. Lo que falla es la propagación de rutas, caminos asimétricos, confusión de DNS y que alguien olvide que existe la VLAN de cámaras.

Diseños de referencia: elige uno y comprométete

Tienes tres patrones sensatos. Elige según escala, límites de confianza y quién controla el borde de red en cada sitio CCTV.

Diseño A: Acceso remoto hub-and-spoke (oficina o nube como hub)

Es la solución trabajadora. Cada sitio establece un túnel VPN saliente a un hub (firewall de oficina o una pequeña VM en una VPC de nube). Los usuarios remotos se conectan al hub y luego enrutan a los sitios.

Pros: Un endpoint público estable (el hub). No hay reglas entrantes en los sitios. Registro y política centralizados.

Contras: El hub se convierte en una dependencia crítica. Debes planificar capacidad. Debes aplicar principio de menor privilegio para que un solo usuario no tenga las llaves de todos los sitios.

Diseño B: VPN sitio a sitio entre oficina y sitios de cámaras

IPsec clásico o WireGuard sitio a sitio. Los usuarios están en la red de la oficina; la oficina enruta a subredes de cámaras a través de túneles.

Pros: Más limpio cuando toda la visualización ocurre desde redes corporativas (SOC, equipo de seguridad). Mínima dispersión de software cliente.

Contras: No ayuda a individuos remotos a menos que primero hagan VPN a la oficina. Y sí, puede estar bien—solo admite que ese es el plan.

Diseño C: Acceso estilo zero-trust (proxy de identidad a la UI del NVR)

Expones una UI interna (usualmente la app web del NVR) a través de un proxy con conciencia de identidad. Las cámaras permanecen privadas; el proxy aplica SSO/MFA y política.

Pros: Controles de identidad fuertes. No acceso de red amplio. Excelente historia de auditoría.

Contras: Más difícil para visualización RTSP cruda, descubrimiento ONVIF o herramientas que esperan alcance tipo L2. Algunas apps NVR se comportan mal detrás de proxies.

Para la mayoría de empresas medianas y entornos multi-sitio retail/industrial, recomiendo Diseño A (hub-and-spoke) con WireGuard, más una política estricta de firewall entre clientes VPN y VLANs de cámaras. Es aburrido en el mejor sentido.

Modelo de seguridad: trata las cámaras como IoT hostil

Asume que cada cámara/NVR:

• ejecuta paquetes desactualizados,
• trae demasiados servicios expuestos,
• registra pobremente,
• y ocasionalmente realiza tráfico “phone home” que no pediste.

Así que tu objetivo de diseño no es solo “hacerlo accesible.” Es “hacerlo accesible solo por rutas controladas y solo para usuarios aprobados.”

Reglas estrictas que te mantienen fuera de problemas

• No ingreso directo desde Internet a subredes CCTV. Si debes publicar algo, publica un proxy autenticado, no un puerto de cámara.
• Separa CCTV de endpoints corporativos. Separación por VLAN/subred con reglas de firewall. Las cámaras no necesitan hablar con nómina.
• No túnel completo del video a menos que lo quieras de verdad. Unos pocos streams de 8 Mbps convertirán tu VPN en una presentación de diapositivas. Usa túneles divididos con rutas explícitas.
• Bloquea puertos de gestión. Permite RTSP solo a estaciones de visualización, permite HTTPS solo a administradores, bloquea SMB/Telnet/FTP (sí, todavía aparecen).
• Haz la identidad real. Llaves/certs por usuario, MFA en la VPN o en el sistema de identidad superior, y revocación rápida.
• Registra en el punto de estrangulamiento. El hub debe ser donde puedas responder: quién accedió a qué NVR, cuándo y desde dónde.

Una cita, usada con moderación porque las citas a menudo sustituyen al pensamiento: La esperanza no es una estrategia. — James Cameron

Guía de WireGuard: hub-and-spoke bien hecho

WireGuard encaja bien para acceso CCTV porque es estable bajo NAT, rápido y tiene una superficie de configuración pequeña. No gestiona usuarios por ti; necesitarás un plan para ciclo de vida de claves, control de acceso y auditoría.

Ejemplo de diseño de red

• Hub (IP pública): 203.0.113.10, interfaz WireGuard wg0 con subred VPN 10.44.0.0/24
• Sitio A (sin IP pública): VLAN de cámaras 10.10.50.0/24, el router del sitio ejecuta cliente WireGuard con IP VPN 10.44.0.10
• Usuario remoto: portátil cliente WireGuard con IP VPN 10.44.0.101

Idea clave: el router del sitio establece un túnel saliente al hub. El usuario remoto también se conecta al hub. El hub enruta entre ellos, pero solo según lo permitan las reglas de firewall.

Enrutamiento: haz las rutas explícitas

No confíes en “más o menos funciona”. Haz que el hub sepa qué sitio posee qué subred de cámaras.

• El hub tiene una ruta a 10.10.50.0/24 vía el peer 10.44.0.10
• El usuario remoto recibe (o configura localmente) una ruta a 10.10.50.0/24 vía wg0
• El router del sitio tiene una ruta de vuelta a la subred VPN 10.44.0.0/24 vía WireGuard

Política de firewall: restringe por destino y puerto

En el hub, trata la interfaz VPN como una red no confiable. Porque lo es. Permite solo lo que necesites:

• HTTPS a la interfaz web del NVR (a menudo 443 o un puerto del proveedor)
• RTSP al NVR/cámaras (554 o puerto definido por el proveedor)
• ONVIF (comúnmente 80/8899/3702 UDP, varía mucho)

Bloquea todo lo demás, especialmente movimiento lateral entre sitios.

DNS: tus usuarios escribirán nombres, no subredes

Si quieres que “nvr-site-a.corp” resuelva sobre la VPN, necesitas DNS dividido o un servidor DNS por la VPN. No lo arregles con registros DNS públicos apuntando a IP privadas si te gustan los portátiles confundidos en hoteles.

Identidad y acceso

WireGuard usa claves. Eso es bueno. Pero aún necesitas:

• Claves por usuario (no “security-team.conf” compartido)
• Proceso de rotación y revocación de claves
• MFA en algún lugar: o en un gateway VPN superior (si WireGuard está detrás de un portal), o emitiendo acceso de corta duración vía un broker de identidad/SSO. Si no puedes hacer MFA directamente en WireGuard, aún puedes aplicarlo en el sistema que distribuye las configuraciones y controla quién las recibe.

Segundo chiste corto, último: Una clave VPN compartida es como un cepillo de dientes compartido—técnicamente funciona, pero te arrepentirás.

Tareas prácticas con comandos: verificar, decidir, arreglar

Esta sección es deliberadamente práctica. Cada tarea incluye: un comando, salida de ejemplo, qué significa y la decisión que tomas a partir de ello. Todos los ejemplos asumen Linux en el hub; adáptalos según sea necesario.

Tarea 1: Confirma que la interfaz WireGuard está activa y los peers hacen handshake

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

Significado: “latest handshake” te indica vida. Si son minutos/horas, el túnel está abajo o inactivo sin keepalive.

Decisión: Si un sitio detrás de NAT envejece, configura PersistentKeepalive=25 en ese peer (lado del sitio). Si la IP del endpoint cambia mucho, confirma el comportamiento del dispositivo NAT.

Tarea 2: Valida el reenvío IP del kernel en el hub

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

Significado: Si esto es 0, el hub no enruta tráfico entre peers VPN y subredes de sitio.

Decisión: Fíjalo a 1 y persiste en /etc/sysctl.conf o un drop-in.

Tarea 3: Comprueba que la ruta a la subred de cámaras exista en el hub

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

Significado: El hub cree que 10.10.50.0/24 es alcanzable vía wg0. Si no lo ves, probablemente no incluíste esa subred en AllowedIPs del peer del sitio en el hub.

Decisión: Añade la subred a AllowedIPs del peer (en la configuración del hub) para que el hub sepa a dónde enviar el tráfico.

Tarea 4: Confirma que el firewall del hub permite el reenvío desde clientes VPN a la subred del sitio

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

Significado: Política por defecto drop. Solo TCP 443 y 554 hacia la subred de cámaras están permitidos desde clientes VPN.

Decisión: Si los usuarios necesitan descubrimiento ONVIF, puede que necesites permitir UDP específicos, pero agrégalos intencionalmente y verifica el impacto.

Tarea 5: Prueba alcance a un NVR desde el 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

Significado: El enrutamiento básico funciona hub → sitio. Si ping falla pero TCP funciona, ICMP podría estar bloqueado en el firewall del sitio. Eso no es automáticamente incorrecto.

Decisión: No exijas ping como “obligatorio”. Prefiere comprobaciones de servicio (HTTPS/RTSP) como prueba real.

Tarea 6: Verifica puertos de servicio desde el hub (HTTPS y 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!

Significado: Los puertos son alcanzables. Si HTTPS funciona pero RTSP falla, probablemente olvidaste permitir 554, o el NVR transmite en otro puerto.

Decisión: Ajusta reglas de firewall para coincidir con el uso real del proveedor y documenta. “Abrir todos los puertos” no es documentación.

Tarea 7: Comprueba que el router del sitio esté enrutando tráfico desde la VPN a la VLAN de cámaras (desde el 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

Significado: Hop 1 es el endpoint WireGuard del sitio (router), hop 2 es el NVR. Ese es el camino esperado.

Decisión: Si la traza se detiene en el hop 1, el router del sitio no está reenviando a la VLAN o tiene un firewall que lo descarta. Arregla en el borde del sitio, no en el hub.

Tarea 8: Valida la ruta inversa (la subred del sitio puede devolver a clientes 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

Significado: Ves SYN, SYN-ACK, ACK. Eso prueba que el tráfico de retorno viene de vuelta por el túnel. Si solo ves SYNs sin SYN-ACK, el lado del sitio no tiene ruta de vuelta o está bloqueando.

Decisión: Añade/repara la ruta en el router del sitio para 10.44.0.0/24 vía wg0, o arregla firewall/NAT del sitio.

Tarea 9: Comprueba problemas de MTU (el clásico “todo conecta pero el video salta”)

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

Significado: Con DF establecido (-M do), paquetes de tamaño 1400 funcionan extremo a extremo. Si falla a cierto tamaño, tienes restricciones de MTU en el camino (común con PPPoE, LTE o encapsulación apilada).

Decisión: Reduce MTU de WireGuard (por ejemplo a 1360 o 1280) en clientes/routers del sitio y vuelve a probar estabilidad.

Tarea 10: Observa el ancho de banda e identifica al consumidor real

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

Significado: Aumentos de drops bajo carga se correlacionan con problemas de buffering o saturación de CPU. Combínalo con estadísticas de CPU y contadores de interfaz.

Decisión: Si los drops suben durante visualización, limita la tasa de streams, reduce streams concurrentes o escala CPU/instancia del hub. Las VPNs no inventan ancho de banda.

Tarea 11: Verifica comportamiento de resolución DNS para nombres de 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

Significado: DNS está configurado a un resolvedor del lado VPN (10.44.0.1) y con alcance en la interfaz VPN. Eso evita que “DNS públicos en Wi‑Fi adivinen tus nombres privados”.

Decisión: Si los nombres no resuelven, arregla DNS dividido: o empuja DNS vía configuración del cliente VPN o ejecuta un resolvedor accesible por la VPN.

Tarea 12: Confirma que no estás encaminando el video por la WAN de la oficina accidentalmente

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

Significado: Ves IP cliente VPN a IP NVR directamente, no NATeada a otra subred. Eso es bueno; mantiene la política inteligible y los logs útiles.

Decisión: Si ves NAT que no pretendías, audita reglas iptables/nft NAT y elimina reglas de masquerade “temporales” que se volvieron permanentes.

Tarea 13: Prueba que la VLAN de cámaras del sitio no está enrutando a Internet vía la VPN (sí, sucede)

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

Significado: El peer del sitio solo anuncia su IP VPN y su subred de cámaras. Si alguna vez ves 0.0.0.0/0 o rangos corporativos amplios aquí sin razón, alguien está convirtiendo tu VPN en ruta por defecto.

Decisión: Mantén AllowedIPs estrictos. Si necesitas más subredes, enuméralas explícitamente y revisa el radio de impacto.

Tarea 14: Valida sincronización de tiempo (porque TLS y logs son inútiles cuando el tiempo está mal)

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

Significado: Tiempo sincronizado hace tu rastro de auditoría defendible y evita sorpresas de “certificado TLS aún no válido/expirado” al proxyar UIs de NVR.

Decisión: Arregla NTP donde puedas (hub, routers de sitio, NVRs si lo soportan). Si dispositivos no pueden hacer NTP confiable, cuenta con ello en respuesta a incidentes.

Guía rápida de diagnóstico

Cuando “el acceso a cámaras está roto”, puedes perder horas rebotando entre equipos. No lo hagas. Usa una secuencia estricta que estreche el cuello de botella rápidamente.

Primero: ¿está vivo el túnel?

• Revisa wg show en el hub: ¿tienes handshake reciente para el peer del sitio y el peer del usuario?
• Si no hay handshake: es NAT/firewall/alcanzabilidad del endpoint o desajuste de claves. No “el NVR está caído”.

Segundo: ¿el enrutamiento es correcto en ambas direcciones?

• Desde el hub, ip route get 10.10.50.20 debería escoger wg0.
• Usa tcpdump en wg0 mientras un usuario intenta acceso. Si el SYN sale pero no vuelve SYN-ACK: el router/NVR del sitio está roto en el lado de retorno.
• Ejecuta traceroute -n desde el hub al NVR y mira dónde se detiene.

Tercero: ¿la política/firewall está bloqueando lo correcto?

• En el hub: verifica que la cadena forward permita los puertos requeridos hacia la subred del sitio.
• En el sitio: verifica que la VLAN de cámaras permita entrada desde la subred VPN y permita tráfico de retorno.
• Recuerda: reglas “established,related” no ayudan si el SYN inicial nunca llega al destino.

Cuarto: ¿es rendimiento (MTU, pérdida de paquetes, saturación) en vez de alcance?

• Prueba MTU con pings DF de distintos tamaños.
• Revisa drops en wg0 e interfaces WAN.
• Confirma cuántos streams concurrentes y qué bitrate se están extrayendo.

Quinto: Peculiaridades de la aplicación (UI NVR, autenticación RTSP, descubrimiento ONVIF)

• HTTPS alcanzable no significa “login funciona”. Desfase de tiempo y ajustes TLS pueden romper la UI.
• RTSP puede requerir manejo TCP/UDP según el cliente; algunos clientes por defecto usan UDP y quedan bloqueados.
• ONVIF discovery usa multicast/broadcast que no atraviesa VPNs enrutadas sin auxiliares. Prefiere conexión por IP directa para uso remoto.

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

Estos son los que aparecen repetidamente en flotas reales, no en diagramas de marketing.

1) “La VPN conecta, pero las cámaras no cargan”

Síntoma: El usuario muestra “conectado” en el cliente VPN; la UI web del NVR agota tiempo; ping puede funcionar.

Causa raíz: Existen rutas en el hub, pero el firewall de forwarding descarta TCP 443/554; o el router del sitio bloquea la subred VPN hacia la VLAN de cámaras.

Solución: Añade reglas explícitas de forward allow en el hub y en el borde del sitio para subred y puertos de destino requeridos. Valida con nc -vz y tcpdump.

2) “Funciona desde el servidor hub pero no desde portátiles”

Síntoma: El hub puede alcanzar el NVR; el cliente remoto no.

Causa raíz: La configuración del cliente carece de ruta a la subred de cámaras (túnel dividido no configurado); AllowedIPs muy estrechos en el cliente; o DNS apunta a un resolvedor público.

Solución: Empuja/define AllowedIPs en el cliente para incluir las subredes de cámaras. Asegura que DNS esté con alcance VPN y que el nombre resuelva a IP privada.

3) “El video salta, la UI es lenta, pero ping está bien”

Síntoma: Login funciona; un stream funciona; múltiples streams saltan o se congelan.

Causa raíz: Límites de CPU del hub, saturación de uplink WAN en el sitio, o fragmentación/blackholing MTU bajo carga.

Solución: Reduce bitrate/resolución para perfiles remotos; habilita substreams; ajusta MTU; escala instancia del hub; evita tunelizar todo el tráfico.

4) “Todo se rompe cuando cambia el ISP en el sitio”

Síntoma: El sitio queda oscuro tras el cambio de ISP; no hay handshake.

Causa raíz: El peer del sitio no alcanza al hub por firewall/NAT upstream; reglas antiguas tenían puerto del hub en lista blanca; o el sitio asumía “puerto abierto” frágil.

Solución: Asegura salida UDP al puerto del hub (por ejemplo 51820). Usa PersistentKeepalive para NAT. Documenta requisitos del ISP.

5) “Dos sitios no pueden estar en línea al mismo tiempo”

Síntoma: Levantar el Sitio B hace que las rutas del Sitio A desaparezcan o el tráfico fluctúe.

Causa raíz: Subredes superpuestas (ambos sitios usan 192.168.1.0/24, etc.) o AllowedIPs solapados en el hub.

Solución: Deja de usar direccionamiento superpuesto para acceso enrutado. Si renumerar es imposible, usa NAT en el borde del sitio (con cuidado) o despliega VRFs por sitio—ambas son trabajo, elige tu dolor conscientemente.

6) “ONVIF discovery funciona en la oficina pero no sobre VPN”

Síntoma: La herramienta de descubrimiento no encuentra nada remotamente; IP directa funciona.

Causa raíz: ONVIF discovery usa multicast/broadcast que no atraviesa VPN enrutada por defecto.

Solución: Usa IP directa/listas de hosts para acceso remoto. Si discovery es obligatorio, despliega un proxy de descubrimiento en sitio o usa gestión centrada en el NVR.

7) “Usuarios aleatorios alcanzan cámaras que no deberían”

Síntoma: Un usuario con acceso VPN puede escanear VLANs de cámaras en varios sitios.

Causa raíz: Política VPN plana; la cadena forward del hub permite rangos amplios de destino; no hay reglas por grupos.

Solución: Segmenta pools VPN por rol; aplica restricciones de destino en el hub; considera jump hosts por sitio o un proxy de identidad para la UI.

Tres micro-historias corporativas desde el campo

Micro-historia 1: El incidente causado por una asunción equivocada

Una empresa con algunos almacenes desplegó una solución “simple”: cada router de sitio hacía un túnel al oficina central, y el SOC podía ver cámaras. Funcionó. Durante meses. Todos se relajaron, que es como la falla se vuelve sorpresa.

Entonces un almacén contrató un nuevo ISP. El sitio aún tenía “internet”, así que el registro local de cámaras estaba bien. Pero el acceso remoto murió. Instalaciones informó “VPN caída”, TI respondió “problema del ISP” y Seguridad escaló porque necesitaban imágenes para una investigación.

La suposición equivocada: “Salida a Internet significa salida UDP en nuestro puerto elegido.” El nuevo módem del ISP hizo “seguridad útil” bloqueando UDP saliente excepto puertos comunes, y nadie lo notó durante la instalación. El túnel nunca volvió a hacer handshake.

Perdieron medio día discutiendo quién lo tenía. La solución tomó diez minutos: mover WireGuard a un puerto permitido y permitir explícitamente UDP saliente desde el router del sitio. La solución real tomó más tiempo: actualizar la lista de verificación de despliegue para incluir “validar egress UDP al hub” y requerir una comprobación de handshake post-corte como puerta de aprobación.

Micro-historia 2: La optimización que se volvió en su contra

Otra organización decidió que su VM hub estaba “sobreaprovisionada”. La redujeron para ahorrar, porque la VPN “solo enruta”. Alguien miró gráficos de throughput promedio y declaró victoria.

Dos semanas después, durante un incidente regional, varios gerentes abrieron vistas en vivo simultáneamente. La CPU del hub se saturó, paquetes se perdieron y los usuarios experimentaron “fluctuación de cámaras”. Parecía problema de cámara, luego uplink del sitio, luego NVR—porque a los humanos les encanta culpar al borde.

Lo que pasó: overhead de encriptación + conntrack + logging + ráfaga de streams concurrentes empujaron la instancia reducida más allá de su límite cómodo. El uso promedio era irrelevante; la carga tenía picos agudos. CCTV es por naturaleza explosivo—la gente no mira 24/7, estampida durante incidentes.

El traspié no fue solo la reducción; fue la falta de pruebas de carga y la ausencia de un SLO claro (“X streams concurrentes a Y bitrate con Z latencia”). Revirtieron el tamaño de instancia, limitaron streams no esenciales y añadieron un “perfil de bajo ancho de banda” para usuarios remotos. Luego lo mantuvieron; gastar un poco en holgura es más barato que un puente de incidentes a las 2 a.m.

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

Una empresa tenía una práctica aburrida: cada sitio CCTV tenía un esquema de direccionamiento estándar (sin solapamientos), cada túnel de sitio tenía una subred de cámaras documentada y cada cambio requería ejecutar un script de validación desde el hub.

Durante una tormenta, varios sitios perdieron energía y regresaron. Un subconjunto de routers de sitio reinició en estado degradado: WAN estaba arriba, pero la interfaz para la VLAN de cámaras no volvió correctamente debido a una peculiaridad de negociación de switch. Localmente, el personal aún veía algunos feeds por cache y conectividad parcial. Remotamente, parecía “VPN pero sin cámaras”.

El on-call no adivinó. Ejecutó las mismas comprobaciones: handshake OK, ruta OK, TCP SYN sale, no SYN-ACK. Eso puso inmediatamente el problema en el lado del sitio, no en el hub. Llamaron al técnico de campo con una instrucción exacta: reinicia el puerto del switch y verifica que la interfaz VLAN esté arriba. Sin divagaciones.

Porque el entorno estaba estandarizado, arreglaron múltiples sitios rápido. La parte “aburrida”—subredes consistentes, enrutamiento consistente, comprobaciones consistentes—impidió que el corte se convirtiera en una danza interpretativa de conocimiento tribal.

Listas de verificación / plan paso a paso

Si haces esto como un “proyecto de TI”, se expandirá. Hazlo como un despliegue operacional con puertas claras.

Paso 1: Inventario y expectativas de tráfico

• Lista la VLAN/subred de cámaras y la(s) IP(s) del NVR de cada sitio.
• Documenta qué puertos se requieren: HTTPS, RTSP, puertos SDK del proveedor, sincronización horaria.
• Estima espectadores remotos concurrentes y bitrate esperado (stream principal vs substream).
• Decide si necesitas acceso a cámaras directamente, o solo a la UI del NVR. Prefiere UI del NVR para usuarios remotos; centraliza autenticación y limita movimiento lateral.

Paso 2: Elige la ubicación del hub y el modelo de fallas

• Hub en oficina está bien si el internet de oficina es resiliente y monitorizado.
• Hub en la nube está bien si lo puedes operar como producción (parches, backups, IaC, monitorización).
• Decide si necesitas uno o dos hubs para redundancia. Si el acceso a cámaras es crítico, un único hub es una única excusa.

Paso 3: Plan de direccionamiento que no te sabotee después

• Asigna una subred VPN dedicada (p. ej., 10.44.0.0/24).
• Asegura que la subred de cámaras de cada sitio sea única en la flota. Si ya tienes solapamientos, prioriza renumerar o aislar vía NAT/VRF con documentación clara.
• Reserva bloques IP para roles de usuario si vas a aplicar política por IP origen (p. ej., 10.44.0.100/26 para operadores, 10.44.0.200/27 para administradores).

Paso 4: Construye el hub con valores por defecto restrictivos

• Habilita WireGuard, reenvío IP y política de firewall estricta (forward por defecto drop).
• Registra denegados (con limitación de tasa) para depurar sin inundar.
• Configura DNS para clientes VPN (DNS dividido) si quieres nombres amigables.
• Decide cómo distribuyes configs y rotas claves. Configs manuales no escalan más allá de “unas pocas personas y un on-call”.

Paso 5: Incorporar un sitio piloto de extremo a extremo

• Levanta el túnel del sitio y confirma estabilidad de handshake (incluye PersistentKeepalive si hay NAT).
• Verifica alcance hub→NVR y comprobaciones de puertos.
• Verifica alcance cliente remoto→NVR y comprobaciones de puertos.
• Mide un stream real y nota impacto en CPU y ancho de banda en hub y WAN del sitio.

Paso 6: Despliega políticas, no solo conectividad

• Implementa reglas por destino por sitio: usuarios que no necesitan Sitio A no deberían alcanzarlo.
• Implementa reglas por rol: espectadores vs administradores.
• Bloquea movimiento lateral: evita que subredes cliente VPN se comuniquen entre sí salvo que sea explícitamente necesario.

Paso 7: Operacionaliza

• Monitorización: edad de handshake, CPU del hub, drops de interfaz, throughput, comprobaciones TCP básicas a NVRs críticos.
• Alertas: “túnel del sitio caído”, “hub saturado”, “aumentan los drops de paquetes”.
• Runbooks: incluye la guía rápida de diagnóstico y los comandos exactos que ejecutarás.
• Control de cambios: un pequeño ajuste de configuración puede enrutar a la mitad de tu red a un agujero negro.

Preguntas frecuentes

1) ¿Realmente necesito una VPN? ¿No puedo usar la nube P2P del proveedor?

Puedes, pero estás tercerizando tu perímetro y tu rastro de auditoría. Si tienes requisitos de cumplimiento o quieres controlar quién puede acceder a qué, una VPN (o proxy de identidad) es la opción operativa más segura por defecto.

2) ¿Qué pasa si el sitio no tiene IP pública y está detrás de CGNAT?

Está bien para hub-and-spoke mientras el sitio pueda abrir conexiones salientes al hub. WireGuard funciona bien aquí; usa PersistentKeepalive para que los mapeos NAT no expiren.

3) ¿Debería usar IPsec en lugar de WireGuard?

Usa lo que tu equipo pueda operar de forma confiable. IPsec es ubicuo y suele venir integrado en firewalls; también es más fácil de malconfigurar y más difícil de depurar. WireGuard es más simple y suele ser más predecible. Si tu borde ya soporta IPsec bien y tienes gente que lo conoce, IPsec es perfectamente válido.

4) ¿Puedo acceder a cámaras directamente por VPN, o solo al NVR?

Prefiere NVR para visualización remota: menos endpoints expuestos, autenticación centralizada y menos probabilidad de que alguien toque UIs web de cámaras al azar. El acceso directo a cámaras a veces es necesario para puesta en marcha o diagnóstico; encuádralo detrás de política solo para administradores.

5) ¿Por qué falla ONVIF discovery sobre VPN?

El descubrimiento suele depender de multicast/broadcast que no cruza redes enrutadas por defecto. Las VPNs suelen ser enrutadas. Solución: conecta por IP/listas de hosts, o despliega tooling en sitio que haga descubrimiento local.

6) ¿Necesito túnel dividido?

Por lo general sí. Túnel divide solo las subredes de cámaras/NVR por la VPN. Tunelizar todo el tráfico hace del hub un punto de estrangulamiento para navegación ajena y puede arruinar el rendimiento durante eventos de video.

7) ¿Cómo evito que un sitio alcance cámaras de otro sitio?

En el hub, aplica política de forwarding que permita a clientes VPN alcanzar solo subredes de destino específicas. También mantén AllowedIPs estrictos por peer. Supón “si se puede enrutar, alguien eventualmente lo escaneará”.

8) ¿Cuál es el registro mínimo que debería tener?

Como mínimo: eventos de conexión (handshakes de peers o establecimiento de sesión), logs de allow/deny del firewall (limitados por tasa) y una tabla que mapée identidad VPN (clave/usuario) a política de acceso. Sin eso, la respuesta a incidentes se vuelve arte interpretativo.

9) ¿Puedo poner el hub en la nube si las cámaras están en LAN privadas?

Sí. Los sitios inician túneles salientes al hub en la nube; los usuarios se conectan al hub; las rutas se intercambian en el hub. El hub en la nube se convierte en punto de encuentro. Trátalo como infraestructura de producción: parchea, monitoriza y haz backup de configuraciones.

10) ¿Cómo manejo subredes de cámaras solapadas entre sitios?

Renumera si puedes. Si no puedes, usa NAT en el borde del sitio (traduce cada sitio a una “subred virtual” única) o aísla con VRFs. NAT añade complejidad y puede romper algunos protocolos de descubrimiento, pero a veces es el mal menor para una solución retroactiva.

Conclusión: próximos pasos que puedes hacer esta semana

Si quieres acceso CCTV seguro sin IPs públicas, deja de negociar con la física y empieza a controlar tu topología.

1. Elige un diseño de referencia: hub-and-spoke es el valor práctico por defecto para CCTV multi-sitio.
2. Estandariza el direccionamiento: subredes de cámaras únicas por sitio, subred VPN dedicada, puertos documentados.
3. Implementa WireGuard (o IPsec) con política estricta: drop por defecto, permite solo puertos requeridos, bloquea movimiento lateral.
4. Operacionaliza desde el día uno: monitorización de handshakes, comprobaciones de rutas, comprobaciones de puertos y un runbook corto que un on-call pueda seguir a las 3 a.m.
5. Pilota un sitio, mide ancho de banda y CPU del hub, luego despliega con lista de verificación y puertas de aprobación.

Haz lo aburrido y correcto. Tu yo futuro estará encantado, lo cual es raro en infraestructura.