Seguimiento de Sesiones de Inquilinos y Atribución de Abuso en WiFi para MDU: Mapeo de Flujos de Meraki a la Identidad de Purple iPSK

Para atribuir el uso indebido en una red de MDU con una sola IP pública, se deben unir dos registros. La exportación de flujo de Meraki MX asigna la IP pública, el puerto de origen traducido y la marca de tiempo a una IP interna, MAC y VLAN. La identidad iPSK de Purple y los registros de contabilidad de RADIUS asignan esa MAC y VLAN a un departamento. Guarde ambos durante 365 días, sujeto a asesoría legal.

¿Qué hace realmente la atribución de uso indebido en una red de MDU?

Purple Multi-Tenant WiFi ofrece a cada residente de una unidad de vivienda múltiple (MDU), un bloque de renta para construir (BTR) o una residencia estudiantil una red privada que se siente como la banda ancha de su hogar. Detrás de esa experiencia se encuentra un hecho arquitectónico ineludible. Cada residente sale del edificio a través de la misma dirección WAN pública, utilizando la traducción de direcciones de puerto (PAT). PAT es una forma de NAT en la que muchos hosts internos comparten una IP pública, distinguidos únicamente por el puerto de origen que asigna la puerta de enlace. Cuando un titular de derechos de autor, un departamento de abuso o un oficial de policía lo busca, ven una sola IP. Esperan un suscriptor detrás de ella. Usted tiene cientos.

La atribución de uso indebido reconstruye esa asignación perdida. Esto se hace a partir de dos planos de datos independientes: los flujos de red de la puerta de enlace y los registros de identidad de Purple. Ninguno de los dos es suficiente por sí solo. Al unirse por la dirección MAC, la VLAN y el tiempo, lo llevan de una IP y un puerto públicos a un departamento específico.

Por qué una sola IP pública rompe la atribución

Un aviso típico bajo la Ley de Derechos de Autor del Milenio Digital de los EE. UU. (DMCA), 17 U.S.C. § 512, contiene tres campos: IP pública, puerto de origen y marca de tiempo. RFC 6302, la guía de la IETF para servidores orientados a Internet, recomienda registrar el puerto de origen y una marca de tiempo precisa precisamente porque el direccionamiento compartido hace que la IP por sí sola sea ambigua. Su trabajo es honrar ese diseño. Si sus registros contienen el puerto traducido y un reloj disciplinado, el aviso se vuelve respondible. Si no es así, podrá identificar el edificio y nada más.

Qué aporta iPSK

Esta guía asume que ya sabe qué es iPSK (Identity Pre-Shared Key). Las guías de Purple "Implementación de iPSK para IoT seguro" e "iPSK vs 802.1X: una comparación" cubren los requisitos previos. En resumen, iPSK emite a cada inquilino una contraseña única en un SSID compartido, y el servidor RADIUS vincula esa clave a una identidad. RADIUS (Remote Authentication Dial-In User Service, RFC 2865) autentica la sesión. La contabilidad de RADIUS (RFC 2866) registra cuándo comienza, cuánto dura y cuándo se detiene. Esta guía cubre la capa operativa superior: convertir esos registros de identidad en pruebas que pueda entregar a su asesor legal.

¿Qué necesita antes de comenzar?

Necesita tener cuatro cosas preparadas antes de que llegue el primer aviso. Construirlas después del hecho no funciona, porque la evidencia que necesita ya habrá desaparecido.

1. Un diseño de VLAN por iPSK. La clave de cada inquilino coloca sus dispositivos en un segmento dedicado de capa 3 antes del límite de NAT.
2. Una exportación de flujo desde el Meraki MX que contenga direccionamiento pre-NAT y post-NAT con marcas de tiempo.3. Purple RADIUS Accounting habilitado, además de una exportación regular del mapeo de iPSK a inquilino.
3. Una política de retención aprobada por el departamento legal y NTP ejecutándose en cada dispositivo de la cadena.

Por qué una VLAN por iPSK supera a un SSID compartido plano

Una VLAN (LAN virtual) es un segmento lógico de capa 2, definido en IEEE 802.1Q, que aísla un grupo de dispositivos de otro. La respuesta RADIUS de Purple puede asignar una VLAN por iPSK, de modo que cada departamento termine en su propia subred. Esa subred se convierte en un segundo identificador independiente. Incluso si se falsea o se aleatoriza una dirección MAC, la IP de origen interna sigue identificando el segmento del departamento.

Diseño	Granularidad de atribución	Sobrevive a la aleatorización de MAC	Aislamiento de inquilinos	Para quién es adecuado
SSID compartido plano, una PSK	Solo el edificio	No	Ninguno por defecto	Red WiFi para clientes de cafeterías pequeñas o vestíbulos, no residencial
SSID compartido, iPSK, sin VLAN	De MAC del dispositivo a inquilino	Parcialmente, mediante el registro de contabilidad en el momento de la sesión	Solo aislamiento de clientes	Paso intermedio durante la migración
iPSK con VLAN por inquilino	Subred del departamento y MAC	Sí, la subred sigue identificando el departamento	Segmentación de capa 3 por departamento	MDU, BTR, alojamiento para estudiantes, departamentos ejecutivos
802.1X con credenciales por persona	Individuo designado	Sí	Política por usuario	Oficinas corporativas multi-inquilino con dispositivos gestionados

Para complejos residenciales, el uso de una VLAN por iPSK es la opción predeterminada adecuada. Ofrece dos identificadores que deben coincidir: la VLAN y la MAC. El estándar 802.1X (el estándar de control de acceso basado en puertos de IEEE) llega al individuo. Sin embargo, presenta dificultades con las consolas de videojuegos, smart TVs y otros dispositivos que traen los residentes.

¿Cómo se configuran las dos capturas de datos?

Captura 1: flujos de red desde el Meraki MX

El Meraki MX puede enviar datos de eventos y flujos mediante Syslog (RFC 5424) y exportar registros de tráfico mediante NetFlow versión 9 (RFC 3954). Configure ambos en el Meraki Dashboard dentro de la configuración de informes del dispositivo. Siga la propia documentación de Cisco Meraki para conocer las rutas de menú vigentes.

Lo que importa es el conjunto de campos que llega a su colector. Para cada conexión traducida necesita:

• IP de origen interna y puerto de origen
• Dirección MAC del cliente, o una vinculación confiable de IP a MAC desde los registros de DHCP
• VLAN o subred de origen
• IP pública posterior a NAT y puerto de origen traducido
• Marcas de tiempo de inicio y finalización, con resolución de milisegundos cuando el exportador lo admita

El puerto posterior a NAT es el campo que los operadores suelen notar que falta con mayor frecuencia. En IPFIX (RFC 7011), los elementos de información relevantes son postNATSourceIPv4Address y postNAPTSourceTransportPort, ambos definidos en el registro IPFIX de la IANA. Antes de confiar en la exportación, capture una muestra. Confirme que su firmware complete el puerto traducido. Si no lo hace, su alternativa es combinar el firewall del MX y el Syslog de flujo con un registro de traducción NAT de un dispositivo ascendente que sí lo registre. Resuelva esto antes de que sea necesario.

Empareje los datos de flujo con los registros de concesión de DHCP. Las concesiones le brindan una vinculación de IP a MAC limitada en el tiempo. Esa vinculación es su red de seguridad cuando un registro de flujo incluye la IP pero no la MAC.

Capture 2: identidad desde Purple

Purple aporta la mitad de la identidad para la unión de datos. Los registros de RADIUS Accounting contienen la MAC del cliente en el atributo Calling-Station-Id, el punto de acceso en Called-Station-Id, y los tiempos de inicio y finalización de la sesión. El proceso de Accounting es una parte estándar de la configuración de RADIUS de Purple en todos los proveedores compatibles. El artículo de soporte de Purple para Avaya muestra una configuración típica, con el accounting habilitado y un intervalo de accounting provisional establecido.

Ese mismo artículo señala un detalle que puede arruinar su unión de datos. Los proveedores dan formato a las direcciones MAC de manera diferente: con guiones y en mayúsculas en uno, con dos puntos y en minúsculas en otro. Normalice cada MAC a un único formato al momento de la ingesta, en ambos planos de datos.

La segunda entrada de identidad es el mapa de iPSK a inquilino: qué clave pertenece a qué departamento y qué VLAN asigna. Exporte esto diariamente desde Purple. De esta manera, conservará una instantánea con fecha de quién poseía cada clave en el día en cuestión, no solo de quién la posee hoy. Los arrendamientos cambian. Una clave que hoy pertenece al departamento 4.12 puede haber pertenecido a un residente anterior hace seis meses.

Cómo crear el pipeline usted mismo

Si aún no centraliza el Syslog de Meraki, un pipeline ligero de código abierto es suficiente. Una pequeña máquina virtual de Linux basta para la mayoría de las propiedades de un solo sitio.

1. Colector. Ejecute Fluentd o Logstash. Escuche en el puerto UDP 514, el puerto Syslog asignado por la IANA, y en el puerto NetFlow de su elección; el puerto UDP 2055 es la convención común. Logstash analiza NetFlow v9 e IPFIX con su códec netflow.
2. Normalización en la ingesta. Convierta todas las marcas de tiempo a UTC. Convierta todas las MAC a un solo formato. Etiquete cada registro con el sitio y la VLAN.
3. Almacenamiento. Dirija los datos a Elasticsearch o Grafana Loki. En Elasticsearch, una política de gestión del ciclo de vida del índice (ILM) rota los índices diariamente y los elimina al alcanzar su límite de retención. En Loki, el compactador aplica un período de retención. De cualquier manera, la eliminación es automática y auditable.
4. Instantánea de identidad. Programe una tarea cron diaria que extraiga de Purple el mapa activo de iPSK a inquilino. Escríbalo en una tabla de búsqueda local con fecha. Mantenga las instantáneas con el mismo programa de retención que los flujos.
5. Control de acceso. Restrinja el acceso a las consultas al personal designado. Registre cada búsqueda. Estos registros identifican a los residentes, por lo que debe tratarlos como datos personales de acuerdo con el GDPR.

El resultado: al momento de recibir una citación legal, usted ejecuta la unión de datos de forma offline, contra sus propios datos, sin esperar a ningún tercero.

¿Cómo responder a un aviso de abuso?

Cuando llegue un aviso, ejecute el mismo flujo de trabajo cada vez.

Aviso de abuso
(IP pública, puerto de origen, marca de tiempo)
        |
        v
[1] Registro de flujo de Meraki
    coincidir IP posterior a NAT + puerto traducido
    dentro de la tolerancia de diferencia de reloj +/- 
        |
        v
(IP interna, MAC, VLAN)
        |
        v
[2] Purple RADIUS Accounting
    comparar MAC con sesión activa en marca de tiempo
        |
        v
[3] Captura fechada de iPSK por inquilino
    comparar iPSK + VLAN en esa fecha
        |
        v
Departamento / ocupante registrado

Tres comprobaciones mantienen el resultado defendible:

• Disciplina de zona horaria. Primero convierta la marca de tiempo de la notificación a UTC. Muchas notificaciones llegan en la hora local del remitente.
• Coincidencia entre identificadores. La VLAN del registro de flujo debe coincidir con la VLAN que asigna la iPSK. Una discrepancia significa que algo anda mal. Deténgase e investigue antes de señalar a nadie.
• El asesor legal decide la divulgación. Su resultado es un registro de atribución interno. Si se debe divulgar o no, notificar al residente o rechazar la solicitud, es una decisión legal.

Ejemplo práctico: de la notificación al departamento

Esta cadena utiliza direcciones de documentación (RFC 5737) y valores ficticios.

1. Notificación. Un titular de derechos informa un evento de intercambio de archivos desde la IP 203.0.113.10, puerto de origen 41822, a las 22:17:05 UTC del 14 de marzo.
2. Consulta de flujo. Busca en el índice de flujo del MX la IP post-NAT 203.0.113.10 y el puerto traducido 41822, entre las 22:17:03 y las 22:17:07. Un registro coincide. Origen interno 10.40.12.37, puerto 51544, VLAN 412.
3. IP a MAC. El registro de concesiones DHCP muestra la IP 10.40.12.37 vinculada a la MAC 3C-22-FB-1A-7E-09 desde las 19:02 hasta las 23:58 de ese día.
4. Consulta de identidad. Purple RADIUS Accounting muestra esa MAC con una sesión activa desde las 19:02 hasta las 00:41. La sesión se autenticó con la iPSK asignada a la VLAN 412.
5. Búsqueda de inquilino. La captura de iPSK del 14 de marzo asocia esa clave y la VLAN 412 con el departamento 4.12. Entrega la cadena al asesor legal.

Cada salto es un registro con marca de tiempo de un sistema independiente. Esa independencia es lo que hace que la cadena sea creíble.

¿Cómo comprueba que la cadena funciona?

No espere a que llegue una notificación real para descubrir un vacío. Realice un simulacro trimestral:

• Desde un dispositivo de prueba en una iPSK conocida, abra una conexión a un servidor externo que usted controle. Registre la IP pública, el puerto y la hora de los registros de ese servidor.
• Ejecute todo el flujo de trabajo a ciegas, comenzando únicamente desde el registro del lado del servidor.
• Confirme que llega al departamento de prueba correcto. Tome nota de cuánto tiempo tomó.
• Verifique que el registro más antiguo en cada índice se encuentre en su límite de retención y no más allá. La retención excesiva es un problema de GDPR por derecho propio.

Si el simulacro falla, la causa más común es un puerto post-NAT faltante o un desfase en el reloj. Ambos se detallan a continuación.

¿Qué rompe la cadena de atribución y cómo se soluciona?

Desviación del reloj

La unión depende del tiempo. Los puertos traducidos se reutilizan en cuestión de segundos en una puerta de enlace con mucho tráfico, por lo que unos pocos segundos de desviación pueden hacer que coincida el flujo incorrecto. Apunte el MX, sus puntos de acceso, el recolector y cualquier dispositivo NAT ascendente a las mismas fuentes NTP (Network Time Protocol, RFC 5905). Registre todo en UTC. Genere una alerta cuando la desviación de cualquier dispositivo supere un segundo. Si dos flujos coinciden dentro de su ventana de tolerancia, informe la ambigüedad al asesor legal en lugar de elegir uno.

NAT de grado de operador ascendente

Algunos ISP colocan su WAN detrás de un NAT de grado de operador (CGNAT, descrito en RFC 6888). La dirección pública de su MX es entonces privada por sí misma. El aviso llevará la dirección y el puerto compartidos del ISP. Solo el ISP puede mapear eso a su WAN, y solo sus logs pueden mapear su WAN a un departamento. Sus registros se convierten en el único registro de atribución dentro del edificio. Pregunte a su ISP si se encuentra detrás de un CGNAT y solicite una IP pública dedicada donde sea posible.

Intercambio de PSK entre inquilinos

Si un residente le da su iPSK a un vecino, ambos hogares aparecen como un solo departamento. Implemente el registro obligatorio de dispositivos: limite los dispositivos por iPSK y requiera que los residentes registren los nuevos dispositivos a través de Purple. Revise las claves cuyo recuento de dispositivos o sesiones concurrentes aumente repentinamente. Rote una clave el mismo día de la mudanza como parte de su proceso de altas, cambios y bajas de inquilinos.

Aleatorización de direcciones MAC

Las versiones actuales de iOS y Android presentan una MAC privada por red de forma predeterminada, y algunas configuraciones la rotan. Es por eso que usted se asocia al registro de RADIUS Accounting activo en la marca de tiempo, no a un registro estático de dispositivos inscritos. Con VLAN por iPSK, la subred sigue identificando al departamento incluso cuando una MAC es nueva.

¿Cuánto tiempo debe conservar los logs?

La retención es una cuestión legal. Acuérdelo con un asesor legal local antes de configurar cualquier cosa. Como base de trabajo, la mayoría de los operadores conservan los registros de flujo e identidad durante 365 días. Eso cubre el tiempo que suele tardar en llegar una citación civil o una solicitud policial.

Dos presiones empujan en direcciones opuestas. Según el Artículo 5(1)(e) del GDPR, solo puede conservar los datos personales durante el tiempo que requiera la finalidad. En el Reino Unido, la Investigatory Powers Act de 2016 limita los avisos de retención de datos a 12 meses. En los EE. UU., las citaciones de la DMCA § 512(h) pueden llegar mucho después del evento. Escriba el periodo acordado en su aviso de privacidad y en los términos del contrato de arrendamiento. Luego, deje que la retención de ILM o Loki lo aplique automáticamente.

¿Cuánto cuesta y qué obtiene a cambio?

La arquitectura DIY funciona en una máquina virtual modesta más almacenamiento. Calcule el tamaño del almacenamiento midiendo una semana de volumen de flujo, multiplicándolo por 52 y agregando un margen de seguridad. La contribución de Purple, la capa de identidad iPSK y RADIUS Accounting, se ejecuta en los puntos de acceso que ya posee. Purple es independiente del hardware en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet, sin necesidad de reemplazar equipos existentes.

El retorno se mide en la prevención de interrupciones. Dos escenarios ilustrativos muestran la diferencia.

Escenario 1: departamentos con servicios en un complejo hotelero

Un bloque de 180 departamentos amueblados con servicios, operado junto con una operación de hotel, recibió repetidos avisos de derechos de autor en una red compartida plana. Al no tener forma de atribuirlos, el operador envió una advertencia por correo electrónico a cada residente. Esto generó quejas y el ISP amenazó con suspender el servicio. El operador migró a una VLAN por iPSK en su infraestructura Meraki existente y configuró el flujo de Logstash mencionado anteriormente. El siguiente aviso se resolvió a un solo departamento en menos de 20 minutos. Solo se contactó a ese residente y no se necesitaron más advertencias para todo el edificio.

Escenario 2: viviendas del sector público para trabajadores esenciales

Un bloque de 90 departamentos para trabajadores esenciales, propiedad del ayuntamiento y cercano a un hospital, recibió una solicitud de datos policiales sobre una IP pública y un puerto. El equipo de vivienda tenía iPSK y VLANs por departamento, pero solo guardaba 30 días de registros. El evento ocurrió fuera de ese plazo. Tras una revisión legal, el equipo extendió la retención a 365 días, agregó la captura de identidad diaria y comenzó a realizar simulacros trimestrales. Una solicitud posterior fue respondida en un plazo de un día hábil, identificando un departamento específico, con cada salto documentado para los asesores legales.

Dónde encaja esto en su infraestructura general

El mismo problema ocurre en las oficinas corporativas multi-inquilino. Un operador de coworking, o un proveedor de SaaS que opera una infraestructura compartida entre clientes inquilinos, se enfrenta a una sola IP pública y muchas organizaciones detrás de ella. Purple Staff WiFi aplica allí el mismo modelo centrado en la identidad, típicamente con 802.1X y Microsoft Entra ID, Okta o Google Workspace como fuente de identidad. La integración de flujos descrita aquí se traslada sin cambios. El mismo patrón sirve para desarrollos de uso mixto de retail con departamentos sobre tiendas, y sectores de healthcare que operan viviendas para el personal.

Para más información, consulte las guías de Purple Multi-Tenant WiFi e iPSK de Purple, "Implementing iPSK for secure IoT" e "iPSK vs 802.1X: a comparison". Si está comparando proveedores de RADIUS en la nube para esta función, lea IronWiFi Alternatives for Enterprise Deployments.

Preguntas frecuentes

¿Necesitamos reemplazar nuestro hardware Meraki para obtener una atribución a nivel de inquilino?

No. Purple se integra sobre sus puntos de acceso Cisco Meraki y dispositivos MX existentes como una superposición en la nube. Usted habilita iPSK con asignación de VLAN a través del RADIUS de Purple, activa RADIUS Accounting y configura la exportación de flujos en el MX. El mismo enfoque funciona en HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. El gateway solo necesita exportar el direccionamiento pre-NAT y post-NAT con marcas de tiempo.

¿Purple almacena los registros de flujo de Meraki por nosotros?

No. Purple conserva la mitad de la cadena correspondiente a la identidad: asignaciones de iPSK, mapeo de VLAN y sesiones de RADIUS Accounting. Los registros de flujo y NAT de Meraki permanecen en un recopilador controlado por usted, ya sea Elasticsearch, Grafana Loki o un SIEM existente. Esa división lo mantiene a usted a cargo de la retención, el control de acceso y la divulgación. Esas son decisiones que debe tomar su asesor legal, no un tercero.

¿Cuánto tiempo debemos conservar los registros de flujo y de identidad?

La mayoría de los operadores conservan ambos durante 365 días, pero la retención es una decisión legal de su asesoría jurídica. El Artículo 5(1)(e) del GDPR limita la retención a lo que requiera la finalidad. En el Reino Unido, los avisos de retención de datos en virtud de la Investigatory Powers Act 2016 tienen un límite de 12 meses. Cualquiera que sea el periodo que acuerde, publíquelo en su aviso de privacidad y aplique la eliminación automática con la retención de ILM o Loki.

¿Es compatible con el GDPR el registro del tráfico de residentes?

Sí, siempre que registre los metadatos de conexión, no el contenido, y los trate como datos personales. Registre una base legal, que normalmente son intereses legítimos o una obligación legal, e indique la finalidad y el periodo de retención en su aviso de privacidad. Restrinja el acceso a las consultas al personal designado y audite cada búsqueda. Purple cuenta con la certificación ISO 27001 y cumple con el GDPR, por lo que la parte de identidad ya se encuentra dentro de un marco de control certificado.

¿Qué pasa si un residente comparte su iPSK con un vecino?

Las claves compartidas fusionan dos hogares en el registro de un solo departamento, por lo que debe evitarlas. Limite el número de dispositivos por iPSK y requiera que los residentes registren los nuevos dispositivos a través de Purple. Esté atento a los aumentos repentinos en el recuento de dispositivos o en las sesiones simultáneas. Con VLAN por iPSK, la clave compartida todavía se asigna al segmento de un departamento. Esto le da a su asesoría jurídica un punto de partida defendible, con una advertencia documentada.

¿Podemos responder a una citación judicial si nuestro ISP utiliza NAT de grado de operador?

Sí, pero solo si sus propios registros están completos. Detrás de CGNAT, la notificación lleva la dirección compartida del ISP. El ISP asigna eso a su WAN, y sus registros deben asignar su WAN a un departamento. Sus registros son entonces el único registro de atribución dentro del edificio. Solicite a su ISP una IP pública dedicada siempre que sea posible y mantenga una disciplina estricta de NTP.

¿Cuánto esfuerzo requiere implementar un canal de registro DIY?

Un ingeniero de redes competente puede poner en marcha el canal de código abierto en una máquina virtual de Linux. Eso cubre un colector Fluentd o Logstash, almacenamiento de Elasticsearch o Loki, una política de retención automatizada y una exportación de identidad diaria desde Purple. El mayor esfuerzo es la validación. Confirme que el firmware de su MX exporta el puerto de origen traducido, luego realice un simulacro de atribución a ciegas antes de confiar en el canal para una notificación real.