Segmentación VPN + VLAN para oficina, almacén y cámaras (sin arrepentimientos)

El modelo mental: la VPN es transporte, la VLAN es contención

La gente confunde VPNs y VLANs porque ambas “separan” cosas. Separan capas diferentes de la realidad.
Una VPN es un túnel: transporta paquetes entre sitios o clientes. Una VLAN es una herramienta de segmentación local: divide un dominio de switching
para que tus cámaras no compartan el espacio L2 con portátiles y IoT aleatorio.

Si recuerdas una regla, que sea esta: las VLAN sirven para limitar el radio del impacto; las reglas de firewall para limitar la intención; las VPN para la conectividad.
“Segmentación” sin firewall es solo gestión de cables sofisticada.

En despliegues multisede (oficina + almacén), las VLANs ocurren dentro de cada sitio, y la VPN mueve tráfico seleccionado entre sitios.
Generalmente no quieres estirar VLANs a través de la VPN salvo que tengas una razón muy específica, comprobable, y ganas de sufrir.
L2 sobre VPN es donde la esperanza va a morir.

Consejo con opinión: enruta entre VLANs en Capa 3 (firewall o switch L3), aplica la política ahí, y enruta entre sitios por la VPN.
Mantenlo aburrido. Las redes aburridas se mantienen arriba.

Una cita que vale la pena pegar en una nota adhesiva: “La esperanza no es una estrategia.” — atribuida frecuentemente a la cultura de operaciones (se repite mucho; la formulación varía).
Tómala como una idea parafraseada si has visto otra versión. El punto permanece.

Hechos interesantes y contexto histórico (lo que explica el lío actual)

• Etiquetado VLAN 802.1Q se convirtió en estándar a finales de los 90; antes de eso, las “VLAN” solían ser específicas de cada proveedor y felizmente incompatibles.
• IPsec existe desde los 90 también, diseñado originalmente para IPv6, luego adaptado al resto porque la realidad no espera.
• NAT se volvió predeterminado no porque fuera elegante, sino porque el agotamiento de IPv4 era previsible y lo ignoramos de todos modos.
• Spanning Tree Protocol (STP) existe porque los humanos son incapaces de no hacer bucles con cables.
• PoE (Power over Ethernet) impulsó la popularidad de las cámaras: un cable para energía y red hace que los equipos de instalaciones de repente “hagan redes”.
• ONVIF se creó para estandarizar la interoperabilidad de cámaras IP; ayudó, pero no hizo que la seguridad de cámaras fuera mágica.
• “Air-gapped” es anterior a la TI moderna; es un concepto de entornos clasificados. En redes corporativas suele significar “a veces se conecta al Wi‑Fi”.
• WPA2-Enterprise apareció a mediados de los 2000 y hizo práctico el autenticado por usuario en Wi‑Fi; aún está poco usado en almacenes.
• WireGuard es nuevo comparado con IPsec/OpenVPN (diseñado a mediados de los 2010), con menos código y valores por defecto sensatos.

Hay un tema: los estándares están maduros. Las fallas suelen ser humanas, organizacionales o por “apuramos la compra”.

Un diseño de referencia que funciona en edificios reales

Sitios y roles

Supón dos sitios físicos: Oficina y Almacén. También puedes tener usuarios remotos (TI/administradores) y quizá un proveedor de seguridad gestionada
que necesita acceso limitado a cámaras/NVR.

En cada sitio quieres:

• Un dispositivo de enrutamiento/firewall (puede ser un firewall dedicado o un router con funciones de firewall).
• Un switch gestionado capaz de VLANs y trunks; idealmente con PoE para cámaras/APs.
• APs inalámbricos que soporten múltiples SSID mapeados a VLANs (invitados vs corp vs escáneres).

Patrón de segmentación: “denegar por defecto, permitir por servicio”

Crea VLANs separadas por zona de confianza. El conjunto mínimo viable habitual:

• Corp: dispositivos de usuarios, portátiles, escritorios.
• Servidores: AD/DNS/NVR/ERP, lo que tu organización llame “crítico”.
• Cámaras: cámaras IP y controladores de puertas relacionados.
• Almacén/OT: escáneres, impresoras de etiquetas, terminales portátiles, equipos cercanos a PLC.
• Invitados: solo internet. Sin acceso a recursos internos.
• Gestión: interfaces de gestión de switches/APs, fuera de banda si puedes.

Luego aplica acceso inter-VLAN en tu firewall/router. Si tu switch L3 puede enrutar, bien—pero centraliza la política
si te importa la auditabilidad. “ACLs distribuidas por todas partes” es como terminas con conocimiento tribal y una persona que no puede tomarse vacaciones.

Dónde pertenece la VPN

Coloca una VPN site-to-site entre los firewalls/enrutadores de borde de Oficina y Almacén. Enruta solo las subredes que necesites.
Si te tienta enrutar 0.0.0.0/0 por el túnel por “simplicidad”, para. Eso no es simplicidad, es posponer la complejidad hasta que todo arda.

La VPN de acceso remoto para personas debería terminar en la oficina (o en un hub central) y estar sujeta a la misma política:
los usuarios aterrizan en una subred/VLAN de VPN dedicada, luego se les permite acceder a servicios concretos.

Chiste #1: Si tu VLAN de cámaras puede alcanzar la VLAN de contabilidad, felicidades—has inventado una manera cara de almacenar metraje y ransomware en el mismo lugar.

Plan de direcciones y mapa de VLAN que no odiarás después

Los buenos planes IP son aburridos. Lo aburrido es fiable. Elige un bloque RFC1918 y subdivide consistentemente por sitio.
Un patrón que escala sin volverse raro:

• Oficina: 10.10.0.0/16
• Almacén: 10.20.0.0/16

Dentro de cada sitio, usa /24 por VLAN:

• VLAN 10 Corp: 10.10.10.0/24 (Oficina), 10.20.10.0/24 (Almacén)
• VLAN 20 Servidores: 10.10.20.0/24, 10.20.20.0/24
• VLAN 30 Cámaras: 10.10.30.0/24, 10.20.30.0/24
• VLAN 40 Almacén/OT: 10.10.40.0/24 (quizá no usada), 10.20.40.0/24
• VLAN 50 Invitados: 10.10.50.0/24, 10.20.50.0/24
• VLAN 99 Gestión: 10.10.99.0/24, 10.20.99.0/24

Por qué funciona este patrón

Los humanos depuran redes. No las “optimizar”. Con direccionamiento predecible, puedes mirar una IP y saber
sitio + zona de confianza. Eso importa cuando miras logs a la noche.

Ubicación de DNS y DHCP

Coloca DNS autoritativo y DHCP en la VLAN de servidores (o en una VLAN de infraestructura dedicada). Usa relay DHCP (IP helper) en interfaces VLAN
si centralizas DHCP. A las cámaras a menudo no les gustan las opciones DHCP complicadas; mantenlo mínimo a menos que conozcas las peculiaridades del modelo.

Las IPs estáticas para cámaras e infraestructura suelen valer la pena. Si usas reservas DHCP en su lugar, exporta/respáldalas.
“Recordaremos las IPs” es un mito que se cuenta a administradores junior como Santa.

Política de firewall: qué habla con qué (y por qué)

Reglas base (con opinión)

• Invitados → interno: denegar. Siempre. Sin excepciones.
• Cámaras → internet: denegar por defecto. Permite NTP hacia tu NTP interno, y quizá endpoints de actualización del proveedor solo si no puedes actualizar offline.
• Cámaras → NVR: permitir solo los puertos necesarios (a menudo RTSP, ONVIF, específicos del proveedor). Prefiere streams iniciados por la cámara hacia el NVR si es factible.
• Corp → Cámaras: generalmente denegar. Si los usuarios necesitan ver en vivo, pasa por la app web del NVR/VMS, no acceso directo a las cámaras.
• Almacén/OT → Servidores: permitir solo los puertos de la aplicación requeridos (ERP, impresión, servicios de escáner). Nada de “any/any por los escáneres”.
• VLAN de gestión: solo la subred VPN de TI y un pequeño grupo de estaciones admin deben acceder (SSH/HTTPS/SNMP).

Entre sitios (sobre VPN)

No necesitas “confianza total site-to-site”. Necesitas servicios específicos:

• Escáneres del almacén hacia servidores ERP de la oficina
• NVR del almacén hacia almacenamiento en la oficina (si centralizas metraje)
• Admins de TI para gestionar switches/APs/firewall del almacén

Enruta y permite solo esas subredes/puertos. Si luego necesitas más, añádelo intencionalmente. Cada regla debe tener un responsable y una razón.

Logging: qué registrar sin ahogarte

Registra denegados entre VLANs durante un tiempo después del despliegue; así descubres el servicio olvidado.
Pero no registres cada permiso. Pagarás por disco y no aprenderás nada.
Registra:

• Intentos denegados de Cámaras/Invitados hacia recursos internos
• Nuevos destinos salientes desde la VLAN de cámaras (deberían ser raros)
• Eventos de túnel VPN arriba/abajo
• Denegados inter-VLAN que afecten aplicaciones críticas (Almacén/OT a Servidores)

Topologías VPN: hub-and-spoke, malla completa y “por favor no”

Hub-and-spoke (recomendado para la mayoría)

La oficina es el hub; el almacén es un spoke. Usuarios de acceso remoto terminan en el hub.
Ventajas: un lugar para gestionar políticas, menos túneles, resolución de problemas más simple.
Desventajas: tráfico hairpin si el almacén necesita alcanzar un tercer sitio; el ancho de banda del hub se vuelve crítico.

Malla completa (solo con automatización y múltiples almacenes)

La malla es viable cuando tienes gestión de configuración y monitorización sólidas. Si lo haces a mano en una GUI web,
estás construyendo una futura caída.

Extensión L2 sobre VPN (evitar)

Estirar VLANs entre sitios hace que dominios de broadcast y fallo crucen edificios. STP no se vuelve educado mágicamente a través de un túnel.
Si intentas crear “una gran LAN”, detente y pregunta qué requisito realmente resuelves—casi siempre es descubrimiento legacy o un proveedor que no sabe enrutar.

WireGuard vs IPsec (compromisos prácticos)

WireGuard es limpio y rápido, con menos opciones para equivocarse. IPsec está en todas partes y a menudo tiene aceleración por hardware, pero la configuración varía mucho por proveedor.
Cualquiera puede ser fiable. La fiabilidad viene de: enrutamiento consistente, MTU sensato y política de firewall disciplinada.

Cámaras y NVR: deja de tratarlas como impresoras

Modelo de amenaza, en lenguaje claro

Las cámaras son ordenadores con lentes. Muchas vienen con configuraciones por defecto débiles, bugs de firmware de larga duración y una sorprendente cantidad de “phone home” saliente.
Tu objetivo no es hacer las cámaras perfectas. Tu objetivo es hacer que la concesión de una cámara sea aburrida: aislada, registrada e incapaz de pivotar.

Buenas prácticas que realmente funcionan

• No permitir inbound directo desde internet a cámaras o NVR. Si necesitas visualización remota, usa VPN o un relay endurecido.
• Bloquear la salida de la VLAN de cámaras salvo NTP/DNS hacia resolutores internos y lo que expresamente apruebes.
• Usar un NVR/VMS en la VLAN de servidores o una VLAN de seguridad dedicada, no dentro de la VLAN de cámaras como una piñata.
• Deshabilitar UPnP en todas partes. Especialmente en el perímetro. UPnP es cómo los dispositivos negocian “exposición sorpresa”.
• La sincronización horaria importa: si los logs y las marcas temporales del metraje se desincronizan, las investigaciones se vuelven fan fiction.

Chiste #2: UPnP es como darle a la tostadora una llave maestra del edificio porque prometió “gestionar puertos responsablemente”.

Planificación de ancho de banda para vídeo

Las cámaras consumen ancho de banda constante. Haz los cálculos. Un puñado de cámaras 4K con bitrate decente puede saturar enlaces ascendentes y Wi‑Fi.
Mantén el tráfico de cámaras local al sitio cuando sea posible (cámaras del almacén al NVR del almacén). Si debes centralizar metraje,
considera replicación programada o substreams de menor bitrate sobre la WAN.

Problemas con multicast y descubrimiento

Algunos despliegues de cámaras dependen de descubrimiento multicast. El multicast no atraviesa VLANs automáticamente.
Evita diseños que requieran “permitir multicast en todas partes”. En su lugar, define dónde se necesita el descubrimiento (a menudo solo durante la provisión),
y luego ciérralo. Si el proveedor requiere adyacencia L2 para operación permanente, trata eso como un riesgo del producto, no como un “problema de red”.

Tareas prácticas: comandos, salidas y decisiones (12+)

Las siguientes tareas asumen que tienes cajas Linux en cada sitio (o en el firewall si es Linux-based), además de switches gestionados y un firewall.
Los comandos son intencionalmente genéricos y portables. El punto es operativo: qué ejecutar, qué esperar y qué decidir.

Tarea 1: Confirmar que las interfaces VLAN existen y están arriba

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

Significado: existen subinterfaces VLAN; VLAN 99 está abajo.
Decisión: si VLAN 99 es de gestión y debería estar activa, súbela y verifica que el trunk del switch permita VLAN 99.
Si está sin usar, elimínala para reducir confusión.

Tarea 2: Verificar direccionamiento IP en cada interfaz VLAN

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

Significado: el router tiene IPs gateway para VLAN 10 y 30.
Decisión: asegúrate de que cada VLAN tenga exactamente un gateway; si ves múltiples dispositivos anunciando gateways (salvo VRRP), invitas a enrutamiento asimétrico.

Tarea 3: Revisar la tabla de rutas para subredes del sitio y rutas VPN esperadas

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

Significado: las VLANs 30/40 del almacén son alcanzables vía wg0.
Decisión: si ves rutas demasiado amplias (como 10.20.0.0/16) cuando solo pretendías acceso a cámara/NVR, estrecha AllowedIPs / selectores phase2 y la política de firewall.

Tarea 4: Validar estado del túnel WireGuard y último handshake

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

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

Significado: el túnel está vivo; el tráfico fluye.
Decisión: si el handshake está obsoleto y los contadores de transferencia no se mueven, sospecha NAT/forwarding de puertos, bloqueos UDP por firewall o claves desajustadas.

Tarea 5: Detectar problemas de MTU con un ping controlado

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

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

Significado: el payload de 1420 bytes funciona; la MTU probablemente está bien para la sobrecarga típica de WireGuard.
Decisión: si esto falla pero tamaños menores funcionan, baja la MTU en wg0 (o en la interfaz WAN) y vuelve a probar los streams de vídeo.

Tarea 6: Confirmar leases DHCP para una VLAN (y detectar DHCP rogue)

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

Significado: el servidor DHCP responde en la VLAN de cámaras.
Decisión: si los clientes reportan direcciones raras y no ves logs, sospecha un DHCP rogue en esa VLAN; aplica DHCP snooping en switches o bloquea puertos a MACs de cámaras.

Tarea 7: Verificar la política inter-VLAN con contadores

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

Significado: drop por defecto; las cámaras pueden alcanzar servidores en puertos RTSP/vendor; corp a cámaras está bloqueado; invitados bloqueados.
Decisión: si el vídeo no se graba, confirma que el allow esté en la dirección correcta (cámara→NVR o NVR→cámara) según tu arquitectura.

Tarea 8: Trazar el camino de un paquete a través de VLAN y VPN

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

Significado: el salto 2 es el peer remoto de WireGuard; el enrutamiento es sano.
Decisión: si lo ves ir al gateway por defecto de internet, te faltan rutas o AllowedIPs; arregla el enrutamiento antes de culpar a la cámara.

Tarea 9: Validar comportamiento DNS desde una VLAN restringida

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

Significado: DNS interno resuelve el hostname del NVR.
Decisión: si cámaras/NVR dependen de nombres y DNS falla entre VLANs, permite DNS desde esa VLAN hacia tu resolutor—o deja de usar hostnames y usa IPs estáticas para cámaras.

Tarea 10: Buscar síntomas de bucle L2 (tormentas de broadcast) vía estadísticas de interfaz

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

Significado: alto multicast/broadcast (mcast) y drops pueden indicar un bucle o dispositivos ruidosos.
Decisión: revisa el estado STP en switches, encuentra el puerto en bucle y cállalo. Si los drops están en WAN, quizá estés saturando el uplink con vídeo.

Tarea 11: Capturar tráfico en la VLAN de cámaras para confirmar quién inicia RTSP

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

Significado: la cámara inicia conexión al NVR en 554; tu regla de firewall debería permitir cámara→NVR.
Decisión: si ves lo contrario (NVR iniciando), ajusta la dirección de la regla de firewall.

Tarea 12: Confirmar que no se aplica NAT accidentalmente al tráfico entre sitios

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

Significado: masquerade se aplica solo en la interfaz WAN eth0, lo cual es correcto.
Decisión: si NAT se aplica a wg0 o VLAN internas, romperás la política basada en direcciones y crearás tráfico unidireccional raro. Corrige el alcance del NAT.

Tarea 13: Comprobar si una cámara intenta alcanzar internet

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

Significado: la cámara intentó HTTP saliente a una IP pública.
Decisión: deja esta regla de drop (sin log una vez estés satisfecho), luego decide si la cámara necesita algún egress controlado para actualizaciones—prefiere actualizaciones manuales.

Tarea 14: Validar el tagging del trunk del switch desde el lado Linux (la VLAN ve tráfico)

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

Significado: las etiquetas VLAN 30 están presentes; el trunk funciona al menos para esa VLAN.
Decisión: si no ves etiquetas para las VLAN esperadas, arregla el modo de puerto del switch (trunk vs access) y la lista de VLANs permitidas.

Guía rápida de diagnóstico

Cuando algo se rompe, no necesitas un genio. Necesitas orden. Aquí la secuencia que encuentra el cuello de botella rápido.

Primero: ¿es local, inter-VLAN o a través de la VPN?

• Desde un host en la misma VLAN, haz ping a la IP objetivo. Si falla, es local (switching, DHCP, dispositivo caído).
• Desde un host en otra VLAN del mismo sitio, haz ping al gateway y luego a la meta. Si el gateway funciona pero la meta falla, es firewall/enrutamiento/política.
• Desde oficina al almacén (o viceversa), haz ping a través de la VPN. Si lo local funciona pero intersitio falla, centra en VPN/enrutamiento/MTU.

Segundo: confirma enrutamiento y política antes de mirar paquetes

• Revisa las tablas de rutas en los routers (local y remoto). Faltas de ruta ganan al “bug misterioso” casi siempre.
• Revisa contadores/logs del firewall por denegados. Si no registras denegados durante el despliegue, debuggearás a ciegas.
• Confirma que NAT no se aplica al tráfico interno/VPN.

Tercero: valida MTU y fragmentación a través de la VPN

• Usa pings PMTU con -M do y ajusta MTU en interfaces de túnel si es necesario.
• Streams de vídeo que fallan mientras pings funcionan es síntoma clásico de MTU: paquetes pequeños funcionan; grandes quedan en agujeros negros.

Cuarto: solo entonces captura tráfico

• Captura en la interfaz VLAN y en la interfaz del túnel. Si lo ves en VLAN pero no en túnel, el enrutamiento/política lo está bloqueando.
• Si lo ves en el túnel pero no en el destino, es política/enrutamiento del lado remoto—o el destino miente sobre estar arriba.

Quinto: comprueba que “la red no es la red”

• CPU de la cámara al máximo, almacenamiento NVR lleno o DNS roto pueden parecer problemas de red.
• Siempre confirma salud de servicio: ¿el puerto RTSP está abierto, el NVR graba, la hora es correcta?

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

1) “Las cámaras se desconectan aleatoriamente”

Síntoma: pérdida intermitente de cámaras, especialmente cuando el almacén está ocupado.

Causa raíz: saturación del uplink o bufferbloat; vídeo + tráfico de escáner compitiendo en el mismo enlace/cola.

Solución: mantén el vídeo local al sitio; aplica QoS para tráfico OT/escáner; mejora uplinks; limita bitrates de cámaras; evita Wi‑Fi para cámaras fijas.

2) “La VPN está arriba pero no enruta nada”

Síntoma: handshake del túnel ok, pero subredes inalcanzables.

Causa raíz: rutas faltantes, AllowedIPs/selectores phase2 erróneos, o enrutamiento asimétrico.

Solución: asegúrate de que ambos lados tengan rutas hacia las subredes VLAN del otro vía el túnel; verifica que el firewall permita forward entre wg0 e interfaces VLAN.

3) “Todo funciona excepto la UI web del NVR desde remoto”

Síntoma: el ping funciona, pero HTTPS/HTTP hace timeout o carga parcialmente.

Causa raíz: agujero negro MTU sobre la VPN o falta de MSS clamping.

Solución: baja MTU del túnel; habilita MSS clamping en el firewall; vuelve a probar con ping de payload grande y tráfico real de navegador.

4) “El Wi‑Fi de invitados puede ver impresoras/servidores”

Síntoma: usuarios invitados alcanzan IPs internas.

Causa raíz: SSID de invitados puenteado a la VLAN corp, o el orden de reglas de firewall lo permite.

Solución: mapea el SSID de invitados a la VLAN de invitados; aplica deny en el gateway; verifica tagging en AP y configuración de puertos del switch.

5) “La instalación de una nueva cámara rompe la mitad de la red”

Síntoma: tormenta de broadcast súbita, CPU alta en switches, pérdida de paquetes en todas partes.

Causa raíz: se introdujo un bucle (dos puertos conectados), o un switch barato hace cosas creativas.

Solución: habilita STP (y BPDU guard en puertos de acceso); apaga puertos que hagan flap; no permitas switches no gestionados en los tendidos de cámaras salvo aprobación explícita.

6) “Los escáneres del almacén van lentos tras la segmentación”

Síntoma: retrasos en la app de escáner tras mover escáneres a VLAN OT.

Causa raíz: falta de acceso DNS, puertos bloqueados hacia servidores de apps, o dependencia de descubrimiento broadcast que no cruza VLANs.

Solución: permite explícitamente DNS/NTP y puertos de app requeridos; reemplaza descubrimiento por broadcast con registros DNS o un servicio auxiliar; documenta dependencias.

7) “Ya no podemos actualizar firmware de cámaras”

Síntoma: actualizaciones fallan tras bloquear acceso a internet de cámaras.

Causa raíz: las actualizaciones requieren endpoints en la nube o el VMS actúa como proxy que bloqueaste accidentalmente.

Solución: actualiza vía NVR/VMS si es soportado; permite temporalmente egress a destinos específicos durante ventanas de mantenimiento; registra y quita la regla después.

Tres mini-historias corporativas desde el terreno

Incidente por una suposición equivocada: “La VPN está cifrada, así que es segura”

Una empresa mediana añadió un almacén y desplegó una VPN site-to-site. El plan era simple: “conectar las redes”.
Enrutaron todo el /16 de la oficina al almacén y viceversa. Sin cambios de segmentación. Sin firewall significativo. La VPN era la frontera de seguridad.

Funcionó de maravilla hasta que un PC del almacén—usado para imprimir etiquetas y ocasionalmente “revisar el correo”—captó un infostealer commodity.
El malware hizo lo que hace: escaneó la red, encontró shares y un RDP antiguo, y entró al entorno de oficina.
La VPN no causó la brecha; removió fricción.

Lo más doloroso no fue la remediación. Fue la reunión post-incidente donde todos se dieron cuenta de que habían tratado “transporte cifrado”
como “segmentación”. Son problemas diferentes. El cifrado protege paquetes de la escucha; no impide que un host comprometido sea malicioso.

La solución fue poco glamorosa: dividir el almacén en VLANs OT, cámaras y gestión; endurecer flujos inter-VLAN; restringir la VPN a subredes necesarias;
y forzar administración remota por una subred VPN dedicada con MFA. Nada fancy. Solo límites que corresponden a la intención.

Optimización que salió mal: “Centralicemos todo el grabado de cámaras por WAN”

Otra org quiso un “single pane of glass” para vídeo. Colocaron el NVR/VMS en la sala de datos de la oficina y transmitieron todas las cámaras del almacén por la VPN.
En papel: gestión más fácil, un sistema de almacenamiento, un plan de backup.

En la práctica: el enlace WAN se volvió camino crítico para seguridad física. Cuando el almacén se ponía ocupado, los streams se degradaban.
Cuando el ISP tuvo una bajada, el almacén perdió grabación por completo. Nadie estuvo contento, incluyendo seguridad que esperaba “más fiabilidad”.

Intentaron “optimizar” aumentando compresión VPN y retocando cifrados. La CPU subió, la latencia empeoró y el vídeo no mejoró.
Estaban afinando el túnel cuando la restricción real era física: ancho de banda y colas en el uplink.

La solución final fue predecible: un grabador local en el almacén con retención local, más replicación programada de eventos de movimiento y substreams a la oficina.
La vista central siguió siendo posible, pero dejó de ser punto único de fallo. La WAN pasó a ser un potenciador, no un requisito.

Práctica aburrida pero correcta que salvó el día: “Documenta las VLANs y prueba como si importara”

Un distribuidor minorista tenía una oficina, dos almacenes y un proveedor de seguridad que ocasionalmente necesitaba acceso a vistas de cámaras.
Su lead de red insistió en una matriz escrita: VLANs, subredes, gateways, ámbitos DHCP y una tabla simple de flujos permitidos.
Nadie se emocionó. Parecía burocracia con pasos extras.

Meses después, un switch en Almacén A murió y hubo que reemplazarlo rápido. Un contratista instaló el reemplazo y—porque los contratistas son humanos—
etiquetó mal el trunk: las cámaras aterrizaron en la VLAN corp. Todo “funcionaba”, pero estaba mal.

La razón por la que se detectó rápido: la matriz de flujos documentada y un script de validación básico que el equipo ejecutaba tras cualquier cambio.
El script comprobaba que los dispositivos de la VLAN de cámaras no pudieran alcanzar internet y que la VLAN corp no pudiera acceder directamente a IPs de cámaras.
La prueba falló inmediatamente. Arreglaron la configuración del trunk antes de que el metraje de seguridad se convirtiera en un canal de exfiltración no monitorizado.

La lección no fue “contratistas malos”. La lección fue que controles aburridos—documentación, pruebas repetibles y políticas deny por defecto—convierten errores en alertas,
no en incidentes.

Listas de verificación / plan paso a paso

Fase 1: Decisiones de diseño (haz esto antes de tocar cables)

1. Define zonas de confianza: Corp, Servidores, Cámaras, Almacén/OT, Invitados, Gestión.
2. Elige un plan IP consistente por sitio (p. ej., 10.10/16 oficina, 10.20/16 almacén) y /24 por VLAN.
3. Decide dónde vive el NVR/VMS (preferible grabación local por sitio; vista central opcional).
4. Decide el modelo VPN: hub-and-spoke a menos que tengas fuertes razones en contra.
5. Escribe una matriz allowlist: qué VLAN puede alcanzar qué servicio (puertos) en qué dirección.

Fase 2: Construcción de switching (L2)

1. Crea VLANs en switches; nómbralas claramente (CAMERAS, GUEST, MGMT).
2. Configura trunks entre switch y firewall/router; permite solo las VLANs necesarias.
3. Configura puertos de acceso: cámaras en access VLAN 30, escáneres en VLAN 40, etc.
4. Habilita STP y BPDU guard en puertos de borde para reducir el radio de la tormenta por bucles.
5. Si es soportado, habilita DHCP snooping y dynamic ARP inspection en VLANs de usuario/cámaras.

Fase 3: Construcción de enrutamiento + firewall (L3)

1. Asigna IPs gateway a interfaces VLAN en firewall/router.
2. Establece política por defecto de forward a deny.
3. Añade allows explícitos:
   • Cámaras → puertos NVR
   • Corp → apps servidor (ERP, email, servicios de archivos)
   • Almacén/OT → apps servidor específicos + impresión
   • Usuarios VPN → interfaces de gestión (limitado)
4. Bloquea egress de la VLAN de cámaras a internet; permite NTP/DNS a servicios internos.
5. Activa logging en denegados entre zonas clave durante el despliegue.

Fase 4: Integración VPN

1. Levanta el túnel site-to-site entre firewalls de sitio.
2. Enruta solo subredes requeridas a través de la VPN.
3. Confirma MTU con pings do-not-fragment; ajusta MTU/MSS del túnel si hace falta.
4. Prueba flujos críticos de negocio: escáneres al ERP, NVR a cámaras, TI a VLAN de gestión.

Fase 5: Higiene operativa (la parte que lo mantiene funcionando)

1. Respalda configuraciones de firewall y switches tras cambios.
2. Mantén un mapa IP/VLAN en control de versiones (aunque sea un archivo de texto).
3. Monitorea la salud de túneles VPN y errores/drops de interfaces.
4. Realiza revisiones trimestrales de accesos: elimina reglas, proveedores y excepciones viejas.
5. Parchea cámaras/NVR según cronograma; rota credenciales; deshabilita servicios no usados.

Preguntas frecuentes (FAQ)

1) ¿Realmente necesito una VLAN separada para cámaras?

Sí. Las cámaras son de alto riesgo y alto consumo de ancho de banda. Una VLAN de cámaras dedicada reduce el riesgo de movimiento lateral y hace factibles controles de ancho de banda.
Coloca el NVR/VMS detrás de una frontera de firewall, no en la misma zona de confianza que todo lo demás.

2) ¿Puedo poner las cámaras en la red de invitados?

No. Las redes de invitados suelen ser solo internet y no están diseñadas para servicios internos estables. Además, no quieres que las cámaras hablen con internet.
Las cámaras pertenecen a una VLAN interna restringida con acceso explícito al NVR y servicios de tiempo/DNS.

3) ¿Ruteo entre VLANs en un switch L3 o en el firewall?

Si necesitas alto throughput este-oeste y política simple, un switch L3 está bien. Si necesitas política de seguridad centralizable y auditable,
enruta en el firewall. Muchas orgs hacen ambas cosas: switch L3 para enrutamiento core, firewall para política inter-zona via VRFs o VLAN de tránsito.
Si eres pequeño-mediano, enrutar en el firewall suele ser más fácil de operar.

4) ¿WireGuard es “más seguro” que IPsec?

La seguridad depende más de la configuración y gestión de claves que del nombre. El código más pequeño y default modernos de WireGuard ayudan a reducir errores.
IPsec está probado y ampliamente soportado. Elige el que puedas operar de forma consistente y monitorizar correctamente.

5) ¿Necesito cifrar tráfico dentro de la LAN si ya tengo VLANs?

Las VLANs no cifran; separan dominios de broadcast. Si tienes tráfico sensible (credenciales, acceso a vídeo), usa TLS/HTTPS y protocolos seguros.
Para acceso de gestión, usa SSH/HTTPS y considera una subred VPN de gestión.

6) ¿Por qué no extender la VLAN de oficina al almacén para que “simplemente funcione”?

Porque hace que las fallas viajen. Broadcasts, bucles y malas configuraciones se vuelven outages cross-site. Los diseños enrutados son más predecibles,
fáciles de asegurar y de depurar. Si un proveedor requiere adyacencia L2, cuestiona el requisito o aíslalo fuertemente.

7) ¿Cómo doy acceso a un proveedor de seguridad a vistas de cámaras sin darles las llaves de todo?

Termina el acceso de proveedor en un perfil/subred VPN dedicada. Permite que esa subred alcance solo la UI del VMS/NVR (y quizá un jump host),
no la VLAN de cámaras. Registra el acceso. Limítalo en el tiempo si es posible. Los proveedores no necesitan toda tu red; necesitan una puerta estrecha.

8) ¿Cuál es la forma más simple de mantener marcas de tiempo correctas en cámaras?

Proporciona NTP interno y permite que la VLAN de cámaras lo alcance. Bloquea NTP arbitrario de internet. Si tienes múltiples sitios,
sincroniza las fuentes NTP por sitio y mantén la configuración de zona horaria consistente entre VMS y cámaras.

9) ¿Cómo evito incidentes tipo “alguien enchufó un switch aleatorio en el almacén”?

Usa port security (límite de MACs), DHCP snooping y BPDU guard en puertos de acceso. Etiqueta puertos. Educa a equipos de facilities.
Y acepta que esto seguirá pasando—así que monitoréalo y haz que sea un incidente pequeño, no un titular.

10) ¿Qué pasa si necesito ver cámaras del almacén desde la oficina?

Prefiere que usuarios de oficina se conecten a la UI del VMS/NVR del almacén sobre la VPN, no acceso directo a cámaras. Si el ancho de banda preocupa,
usa substreams para la visualización en vivo y mantén grabaciones en alta resolución localmente.

Conclusión: próximos pasos prácticos

Si quieres que oficina + almacén + cámaras convivan de forma segura, haz las cosas aburridas a propósito:
segmenta con VLANs, aplica intención con políticas de firewall, y usa la VPN como transporte—no como manta mágica de seguridad.
Mantén el tráfico de cámaras local. Enruta entre sitios. Registra denegados durante el despliegue. Reduce tus zonas de confianza hasta que coincidan con la realidad.

Próximos pasos que puedes ejecutar esta semana:

1. Escribe tu plan VLAN/subred (aunque sea un documento de una página) y reserva IDs de VLAN para crecimiento.
2. Crea una VLAN de cámaras y mueve dos cámaras como piloto; bloquea egress de cámaras a internet y confirma que el NVR sigue grabando.
3. Restringe la VPN site-to-site a subredes necesarias; elimina atajos de “enrutar todo”.
4. Ejecuta la prueba MTU a través de la VPN y corrige fragmentación antes de que los usuarios la descubran con vídeo roto.
5. Activa logging de denegados entre zonas por dos semanas, luego limpia reglas según lo que aprendas.

El objetivo no es la perfección. Es una red donde las fallas están contenidas, los cambios son predecibles y las cámaras no tienen opinión sobre tu postura de seguridad.