Seguimiento de sesiones de inquilino y atribución de uso indebido en WiFi MDU: mapeo de flujos de Meraki a la identidad iPSK de Purple

Para atribuir abusos en una red MDU con una única IP pública, se deben unir dos registros. La exportación de flujos de Meraki MX asocia la IP pública, el puerto de origen traducido y la marca de tiempo con una IP interna, una dirección MAC y una VLAN. Los registros de identidad iPSK de Purple y de contabilidad RADIUS asocian esa MAC y esa VLAN con un apartamento. Guarde ambos registros durante 365 días, sujeto a asesoramiento legal.

¿Qué hace exactamente la atribución de abusos en una red MDU?

Purple Multi-Tenant WiFi ofrece a cada residente de una unidad de viviendas múltiples (MDU), edificio de alquiler residencial (BTR) o residencia de estudiantes una red privada con una experiencia idéntica a la de la banda ancha doméstica. Detrás de esa experiencia se esconde una realidad arquitectónica ineludible. Todos los residentes salen 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 única IP pública, distinguiéndose únicamente por el puerto de origen que asigna la puerta de enlace. Cuando el titular de un derecho de autor, un departamento de abusos o un agente de policía realizan una búsqueda, ven una sola IP y esperan que haya un solo abonado detrás. Sin embargo, usted tiene cientos.

La atribución de abusos reconstruye esa asociación perdida. Lo 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 unirlos mediante la dirección MAC, la VLAN y el tiempo, le permiten pasar de una IP y un puerto públicos a un apartamento concreto.

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

Una notificación típica en virtud de la Ley de Derechos de Autor del Milenio Digital de EE. UU. (DMCA), 17 U.S.C. § 512, contiene tres campos: IP pública, puerto de origen y marca de tiempo. El documento RFC 6302, la guía del IETF para servidores con acceso a Internet, recomienda registrar el puerto de origen y una marca de tiempo precisa debido a que el direccionamiento compartido hace que la IP por sí sola sea ambigua. Su trabajo es respetar ese diseño. Si sus registros contienen el puerto traducido y un reloj preciso, la notificación se puede responder. Si no los contienen, podrá identificar el edificio y nada más.

Qué aporta iPSK

Esta guía asume que usted ya sabe qué es iPSK (Identity Pre-Shared Key). Las guías de Purple "Implementing iPSK for secure IoT" y "iPSK vs 802.1X: a comparison" cubren los requisitos previos. En resumen, iPSK emite para 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. RADIUS Accounting (RFC 2866) registra cuándo se inicia, 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 equipo legal.

¿Qué necesita antes de empezar?

Necesita tener preparadas cuatro cosas antes de que llegue la primera notificación. Configurarlas a posteriori no funcionará, ya que las pruebas que necesita habrán desaparecido.

1. Un diseño de VLAN por iPSK. La clave de cada inquilino introduce sus dispositivos en un segmento dedicado de capa 3 antes del límite de NAT.
2. Una exportación de flujos de Meraki MX que contenga el direccionamiento pre-NAT y post-NAT con marcas de tiempo.3. Purple RADIUS Accounting habilitado, además de una exportación periódica del mapa de iPSK a inquilino.
3. Una política de retención aprobada por el asesor 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 apartamento termine en su propia subred. Esa subred se convierte en un segundo identificador independiente. Incluso si una dirección MAC se falsea o se aleatoriza, la IP de origen interna sigue identificando el segmento del apartamento.

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 edificio	No	Ninguno por defecto	Cafetería pequeña o red de invitados en vestíbulo, no residencial
SSID compartido, iPSK, sin VLAN	MAC del dispositivo al inquilino	Parcialmente, a través del registro de accounting en el momento de la sesión	Solo aislamiento de clientes	Paso intermedio durante la migración
iPSK con VLAN por inquilino	Subred del apartamento y MAC	Sí, la subred sigue identificando al apartamento	Segmentación de capa 3 por apartamento	MDU, BTR, alojamiento para estudiantes, apartamentos con servicios
802.1X con credenciales por persona	Individuo nominal	Sí	Política por usuario	Oficinas corporativas multi-inquilino con dispositivos gestionados

Para complejos residenciales, la opción de VLAN por iPSK es la configuración predeterminada correcta. Ofrece dos identificadores que deben coincidir: la VLAN y la MAC. 802.1X (el estándar IEEE de control de acceso basado en puertos) llega al individuo. Sin embargo, presenta dificultades con videoconsolas, televisiones inteligentes 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ú actuales.

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 asociación IP a MAC fiable de los registros DHCP
• VLAN o subred de origen
• IP pública post-NAT y puerto de origen traducido
• Marcas de tiempo de inicio y fin, con resolución de milisegundos cuando el exportador lo admita

El puerto post-NAT es el campo que los operadores suelen echar en falta con más frecuencia. En IPFIX (RFC 7011), los elementos de información relevantes son postNATSourceIPv4Address y postNAPTSourceTransportPort, ambos definidos en el registro IANA IPFIX. Antes de confiar en la exportación, capture una muestra. Confirme que su firmware rellena el puerto traducido. Si no lo hace, su alternativa es combinar el firewall de MX y el Syslog de flujos con un registro de traducción NAT de un dispositivo ascendente que sí lo registre. Solucione esto antes de que lo necesite. Combine los datos de flujo con los registros de concesión de DHCP. Las concesiones le ofrecen una asignación de IP a MAC limitada en el tiempo. Esa asignación es su red de seguridad cuando un registro de flujo incluye la IP pero no la MAC.

Captura 2: identidad desde Purple

Purple aporta la parte de la identidad de la combinación. 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 las horas de inicio y finalización de la sesión. Accounting es una parte estándar de la configuración de RADIUS de Purple en todos los fabricantes compatibles. El artículo de soporte de Purple para Avaya muestra una configuración típica, con accounting activado y un intervalo de accounting provisional establecido.

Ese mismo artículo señala un detalle que puede arruinar su combinación. Los fabricantes formatean las direcciones MAC de forma diferente: en mayúsculas y separadas por guiones en unos, en minúsculas y separadas por dos puntos en otros. Normalice cada MAC a un único formato durante la ingesta, en ambos planos de datos.

La segunda entrada de identidad es el mapa de iPSK a inquilino: qué clave pertenece a qué apartamento y qué VLAN asigna. Exporte esto diariamente desde Purple. Así dispondrá de una instantánea con fecha de quién tenía cada clave el día en cuestión, y no solo de quién la tiene hoy. Los contratos de alquiler cambian. Una clave que hoy pertenece al piso 4.12 puede haber pertenecido a un residente anterior hace seis meses.

Construya la canalización usted mismo

Si aún no centraliza el Syslog de Meraki, una canalización ligera de código abierto puede cubrirlo. Una pequeña máquina virtual Linux es suficiente para la mayoría de las instalaciones en 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 elegido; UDP 2055 es la convención habitual. 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 único 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 el límite de retención. En Loki, el compactador impone un periodo de retención. En cualquier caso, 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 consulta local con fecha. Conserve 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 conforme al GDPR.

El resultado: cuando reciba un requerimiento judicial, podrá realizar la combinación de forma offline, con sus propios datos, sin tener que esperar a terceros.

¿Cómo responder a una notificación de infracción?

Cuando llegue una notificación, ejecute siempre el mismo flujo de trabajo.

Notificación de infracción
(IP pública, puerto de origen, marca de tiempo)
        |
        v
[1] Registro de flujo de Meraki
    coincidencia de IP post-NAT + puerto traducido
    dentro de la tolerancia del reloj +/- 
        |
        v
(IP interna, MAC, VLAN)
        |
        v
[2] Purple RADIUS Accounting
    hacer coincidir MAC con sesión activa en la marca de tiempo
        |
        v
[3] Captura con fecha del iPSK-a-inquilino
    hacer coincidir iPSK + VLAN en esa fecha
        |
        v
Apartamento / ocupante registrado

Tres comprobaciones hacen que el resultado sea defendible:

• Disciplina horaria. Convierta primero la marca de tiempo de la notificación a UTC. Muchas notificaciones llegan en la hora local del remitente.
• Concordancia entre identificadores. La VLAN del registro de flujo debe coincidir con la VLAN que asigna el iPSK. Una discrepancia significa que algo va 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. Revelar la información, notificar al residente o rechazar la solicitud es una decisión legal.

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

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

1. Notificación. Un titular de derechos informa de un evento de uso compartido de archivos desde 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 flujos de 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 concesión DHCP muestra 10.40.12.37 vinculado 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 el iPSK asignado a la VLAN 412.
5. Búsqueda de inquilino. La captura de iPSK del 14 de marzo asocia esa clave y la VLAN 412 al apartamento 4.12. Entrega la cadena al asesor legal.

Cada paso 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 se comprueba que la cadena funciona?

No espere a recibir una notificación real para descubrir un fallo. Realice un simulacro trimestral:

• Desde un dispositivo de prueba en un iPSK conocido, 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 apartamento de prueba correcto. Anote cuánto tiempo ha tardado.
• Compruebe que el registro más antiguo de cada índice se encuentra en su límite de retención y no más allá. La retención excesiva de datos es un problema de GDPR por derecho propio.

Si el simulacro falla, la causa más común es la pérdida de un puerto post-NAT o un desfase horario. Ambos casos se explican a continuación.

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

Desviación del reloj

La vinculació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 dar lugar a una coincidencia con el flujo equivocado. Configure el MX, sus puntos de acceso, el recopilador y cualquier dispositivo NAT ascendente con las mismas fuentes NTP (Network Time Protocol, RFC 5905). Registre todo en UTC. Active una alerta cuando el desfase de cualquier dispositivo supere un segundo. Si dos flujos coinciden dentro de su margen de tolerancia, informe de la ambigüedad al asesor legal en lugar de elegir uno.

NAT de grado de operador (CGNAT) ascendente

Algunos proveedores de servicios de internet (ISP) sitúan su WAN detrás de un NAT de nivel de operador (CGNAT, descrito en RFC 6888). La dirección pública de su MX es, por lo tanto, privada. La notificación llevará la dirección compartida y el puerto del ISP. Solo el ISP puede mapear eso a su WAN, y solo sus registros pueden mapear su WAN a un apartamento. Sus registros se convierten en el único registro de atribución dentro del edificio. Pregunte a su ISP si está detrás de un CGNAT y solicite una IP pública dedicada siempre que pueda.

Compartir PSK entre inquilinos

Si un residente da su iPSK a un vecino, ambos hogares aparecen como un solo apartamento. Aplique el registro de dispositivos: limite los dispositivos por iPSK y exija a los residentes que registren los nuevos dispositivos a través de Purple. Revise las claves cuyo número de dispositivos o sesiones concurrentes aumente repentinamente. Rote una clave el mismo día de la mudanza, como parte de su proceso de altas, bajas y modificaciones.

Aleatorización de MAC

Las versiones actuales de iOS y Android presentan una MAC privada por red de forma predeterminada, y algunos ajustes la rotan. Es por esto que 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 apartamento incluso cuando la MAC es nueva.

¿Cuánto tiempo se deben conservar los registros?

La retención es una cuestión legal. Acuérdelo con su asesoría jurídica local antes de configurar nada. 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.

Existen dos presiones 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 2016 limita las notificaciones 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 las condiciones del contrato de alquiler. Después, deje que la retención de ILM o Loki lo aplique automáticamente.

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

La infraestructura de desarrollo propio 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 añadiendo 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 del servicio. Dos escenarios ilustrativos muestran la diferencia.

Escenario 1: apartamentos con servicios en un complejo hotelero

Un bloque de 180 apartamentos con servicios integrados, gestionado junto con una operación de hotel, recibía repetidos avisos por infracción 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 provocó quejas y el ISP amenazó con suspender el servicio. El operador migró a una configuración de VLAN por cada iPSK en su infraestructura Meraki existente y puso en marcha el flujo de trabajo de Logstash descrito anteriormente. El siguiente aviso se resolvió identificando un único apartamento en menos de 20 minutos. Solo se contactó con ese residente y no se necesitaron más advertencias para todo el edificio.

Escenario 2: viviendas de protección oficial para trabajadores esenciales

Un bloque de 90 apartamentos para trabajadores esenciales, propiedad del ayuntamiento y situado cerca de un hospital, recibió una solicitud de datos de la policía sobre una dirección IP pública y un puerto concretos. El equipo de vivienda disponía de iPSK y VLAN por apartamento, pero solo conservaba los registros durante 30 días. El evento ocurrió fuera de ese periodo. Tras una revisión legal, el equipo amplió la retención a 365 días, añadió la captura diaria de identidad y comenzó a realizar simulacros trimestrales. Una solicitud posterior se respondió en un plazo de un día laborable, identificando un apartamento concreto, con cada paso documentado para el asesor legal.

Dónde encaja esto en el resto de su infraestructura

El mismo problema surge en las oficinas corporativas multiinquilino. Un operador de coworking, o un proveedor de SaaS que gestione una infraestructura compartida entre clientes inquilinos, se enfrenta a una única IP pública y a muchas organizaciones detrás de ella. Purple Staff WiFi aplica el mismo modelo basado en la identidad en estos entornos, habitualmente con 802.1X y Microsoft Entra ID, Okta o Google Workspace como origen de identidad. La integración de flujos descrita aquí se traslada sin cambios. El mismo patrón sirve para proyectos de uso mixto de retail con apartamentos encima de las tiendas, y para infraestructuras de healthcare que gestionen alojamiento para el personal.

Para obtener más información, consulte las guías de Purple Multi-Tenant WiFi y de 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

¿Es necesario sustituir nuestro hardware de 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 capa en la nube. Solo tiene que habilitar iPSK con asignación de VLAN a través del RADIUS de Purple, activar RADIUS Accounting y configurar la exportación de flujos en el MX. El mismo enfoque funciona en HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. La puerta de enlace solo necesita exportar el direccionamiento previo a NAT y posterior a NAT con marcas de tiempo.

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

No. Purple conserva la parte de identidad de la cadena: las asignaciones de iPSK, el mapeo de VLAN y las sesiones de RADIUS Accounting. Los flujos de Meraki y los registros de NAT permanecen en un recopilador que usted controla, ya sea Elasticsearch, Grafana Loki o un SIEM existente. Esa división le permite mantener el control sobre la retención, el control de acceso y la divulgación de datos. 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 que corresponde a su asesoría jurídica. El Artículo 5(1)(e) del GDPR limita la conservació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 de 2016 están limitados a un máximo de 12 meses. Independientemente del periodo que acuerde, publíquelo en su aviso de privacidad y aplique la eliminación automática con políticas de retención de ILM o Loki.

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

Sí, siempre que registre los metadatos de conexión, no el contenido, y los trate como datos personales. Registre una base jurídica, normalmente intereses legítimos o una obligación legal, y especifique la finalidad y el periodo de conservació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 gestión de la identidad ya se encuentra dentro de un marco de control certificado.

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

Las claves compartidas unifican a dos hogares en un único registro de apartamento, por lo que debe evitarlas. Limite el número de dispositivos por iPSK y exija a los residentes que registren los nuevos dispositivos a través de Purple. Esté atento a incrementos repentinos en el recuento de dispositivos o en las sesiones concurrentes. Con VLAN por iPSK, la clave compartida se sigue asociando al segmento de un único apartamento. Esto proporciona a la asesoría jurídica un punto de partida defendible, con una salvedad 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, el aviso contiene la dirección compartida del ISP. El ISP la asocia a su WAN, y sus registros deben asociar su WAN a un apartamento. Sus registros serán 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 estricta sincronización con NTP.

¿Cuánto esfuerzo requiere desplegar una infraestructura de registro propia?

Un ingeniero de redes competente puede poner en marcha la infraestructura de código abierto en una sola máquina virtual de Linux. Esto incluye un recolector Fluentd o Logstash, almacenamiento en Elasticsearch o Loki, una política de retención automatizada y una exportación diaria de identidades desde Purple. El mayor esfuerzo radica en la validación. Confirme que el firmware de su MX exporta el puerto de origen traducido y, a continuación, realice un simulacro de atribución a ciegas antes de confiar en la infraestructura para un aviso real.