iPSK para el sector residencial multifamiliar: una guía completa para empresas
Esta guía explica cómo iPSK (Identity Pre-Shared Key) resuelve el principal reto de conectividad en los edificios residenciales multi-inquilino: ofrecer una WiFi privada, con la calidad de una red doméstica, para cada residente sobre una infraestructura compartida. Cubre la arquitectura de autenticación, los pasos de despliegue y el caso comercial para tratar la WiFi gestionada como un servicio que genera ingresos en entornos BTR y MDU.
Escuchar esta guía
Ver transcripción del podcast
- Resumen ejecutivo
- Análisis técnico detallado
- Qué hace realmente iPSK
- Por qué 802.1X no funciona para entornos residenciales
- El flujo de autenticación en detalle
- Notas de implementación de proveedores
- Guía de implementación
- Paso 1: Segmentación de red y direccionamiento IP
- Paso 2: Integración de RADIUS-as-a-Service
- Paso 3: Automatización del ciclo de vida del inquilino
- Paso 4: Planificación de RF y ubicación de los puntos de acceso
- Buenas prácticas
- Gestión del tráfico de difusión (broadcast)
- CGNAT y tipos de NAT para videojuegos
- Seguridad y conformidad con el GDPR
- Casos de estudio reales
- Caso de estudio 1: Promoción BTR de 350 unidades
- Caso de estudio 2: Residencia de estudiantes de 1.200 camas
- ROI e impacto empresarial
- Lecturas adicionales

Resumen ejecutivo
Para los operadores de Build-to-Rent (BTR), los promotores inmobiliarios y los propietarios de MDU, el WiFi ya no es un servicio complementario. Es el servicio básico que los residentes evalúan antes de firmar un contrato de alquiler. Los enfoques tradicionales fallan a gran escala: las redes PSK compartidas exponen los dispositivos de un residente a todos los vecinos, la autenticación 802.1X Enterprise bloquea los dispositivos domésticos inteligentes de los que dependen los residentes, y un router físico en cada vivienda crea graves interferencias de radiofrecuencia (RF) que reducen la velocidad de todo el edificio.
Identity PSK (iPSK) resuelve estos tres problemas. Emite una contraseña de WiFi única para cada hogar en una única red para todo el edificio. Cada contraseña se asocia a una VLAN aislada, creando una "burbuja de WiFi" privada para cada residente. Los dispositivos dentro de la burbuja se descubren entre sí (los teléfonos transmiten a los televisores, las consolas se conectan a Internet, los altavoces inteligentes responden a comandos de voz) mientras permanecen completamente invisibles para los vecinos. Purple ofrece esto como una capa de software en la nube independiente del hardware, que se ejecuta en los puntos de acceso Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks y Fortinet que ya posee. El resultado es un incremento en el alquiler de entre 15 y 30 libras por vivienda al mes, periodos de desocupación entre 5 y 10 días más cortos y una reducción del 30-50 % en los costes de conectividad por vivienda en comparación con los contratos de banda ancha individuales.
Análisis técnico detallado
Qué hace realmente iPSK
iPSK (Identity Pre-Shared Key) - conocido como PPSK por HPE Aruba, Personal Private Network por Cisco Meraki, y ePSK por Cambium y Juniper Mist - permite que un único SSID acepte miles de contraseñas diferentes simultáneamente. Cada contraseña es única para un residente u hogar. La red utiliza esa contraseña como una señal de identidad, no solo como una clave de acceso.
Cuando el dispositivo de un residente se conecta, el punto de acceso (AP) no se limita a comprobar si la contraseña es correcta. Reenvía la solicitud de autenticación a un servidor RADIUS (Remote Authentication Dial-In User Service). El servidor RADIUS valida la contraseña con el perfil del residente y devuelve un mensaje Access-Accept que contiene atributos de política específicos; el más importante es el VLAN ID asignado a ese residente. A continuación, el AP etiqueta todo el tráfico de ese dispositivo con la VLAN correcta, situándolo dentro del segmento de red aislado del residente.
Esta asignación dinámica de VLAN es el mecanismo que crea la burbuja de WiFi por residente. El teléfono, el ordenador portátil y la smart TV del Residente A comparten la misma VLAN y pueden comunicarse libremente utilizando protocolos de multidifusión y difusión (mDNS para AirPlay y Chromecast, SSDP para DLNA). Los dispositivos del Residente B se encuentran en una VLAN completamente independiente y son invisibles para el Residente A, aunque ambos hogares compartan los mismos puntos de acceso físicos.

Por qué 802.1X no funciona para entornos residenciales
IEEE 802.1X es el estándar de oro para la autenticación en redes empresariales. Requiere que cada dispositivo presente un nombre de usuario y contraseña o un certificado digital a un servidor RADIUS a través de un intercambio EAP (Extensible Authentication Protocol). El problema en los entornos residenciales es la compatibilidad de los dispositivos. Las bombillas inteligentes, los asistentes de voz, las consolas de videojuegos y la mayoría de los sensores de IoT no incluyen un suplicante 802.1X. No pueden participar en un intercambio EAP. Forzar 802.1X en una red residencial significa que los residentes no podrán conectar sus dispositivos domésticos inteligentes, lo que genera una oleada de llamadas de soporte y una insatisfacción significativa de los residentes.
iPSK utiliza WPA2 o WPA3 a nivel de cliente, algo que todos los dispositivos de consumo admiten. La lógica de identidad de nivel empresarial se ejecuta completamente en el backend entre el AP y el servidor RADIUS, de forma invisible para el dispositivo de conexión.

El flujo de autenticación en detalle
La siguiente secuencia describe lo que ocurre desde el momento en que se conecta el dispositivo de un residente:
- El dispositivo transmite una solicitud de sondeo y se asocia con el SSID.
- El dispositivo envía su contraseña durante el protocolo de acuerdo de cuatro vías de WPA2/WPA3.
- El AP intercepta la contraseña y construye un Access-Request de RADIUS, que incluye la dirección MAC del dispositivo y la contraseña como un atributo Cisco AV-Pair (
psk-modeypsk-password). - El servidor RADIUS en la nube (el RADIUS-as-a-Service de Purple) valida la contraseña con la base de datos de residentes.
- Si se realiza correctamente, el servidor RADIUS devuelve un Access-Accept con el ID de VLAN, la política de QoS y el perfil de ancho de banda para ese residente.
- El AP asigna el dispositivo a la VLAN especificada y completa la asociación.
- El dispositivo recibe una dirección IP del ámbito DHCP para esa VLAN y se conecta dentro de su segmento aislado.
Toda la secuencia se completa en menos de 500 milisegundos y es transparente para el residente.
Notas de implementación de proveedores
El concepto central está estandarizado, pero las implementaciones de los proveedores difieren en cuanto a terminología y configuración:
| Proveedor | Término utilizado | Atributo RADIUS | Notas |
|---|---|---|---|
| Cisco Meraki | Personal Private Network | Cisco-AVPair: psk-mode, psk-password | Configurado a través de Meraki Dashboard; requiere RADIUS |
| HPE Aruba | PPSK (Private PSK) | Aruba-MPSK-Passphrase | Nativo en AOS-CX y Aruba Central |
| Ruckus | DPSK (Dynamic PSK) | Ruckus-DPSK-Passphrase | Administrado a través de Ruckus One o SmartZone |
| Juniper Mist | ePSK | Juniper-MPSK-Passphrase | Nativo en la nube a través de Mist AI |
| Ubiquiti UniFi | PPSK | Tunnel-Password | Compatible con UniFi Network 7.x+ |
| Cambium | ePSK | Cambium-MPSK-Passphrase | Administrado a través de cnMaestro |
La capa RADIUS en la nube de Purple abstrae estas diferencias de los proveedores, ofreciendo una única interfaz de gestión independientemente del hardware subyacente.
-
Guía de implementación
Paso 1: Segmentación de red y direccionamiento IP
Las redes residenciales de alta densidad exigen una planificación cuidadosa de las subredes. Un hogar típico conecta entre 15 y 25 dispositivos. Un edificio de 200 viviendas puede albergar entre 3.000 y 5.000 dispositivos simultáneos en las horas punta. Una subred /24 estándar proporciona 254 direcciones IP utilizables, lo cual es insuficiente incluso para una sola planta.
Utilice subredes /20 o /21 para las VLAN de clientes. Una subred /20 proporciona 4.094 direcciones utilizables; una subred /21 proporciona 2.046. Asigne una VLAN de gestión dedicada para su infraestructura de red, una VLAN independiente para los sistemas IoT del edificio (control de accesos, CCTV, climatización) y VLAN residenciales individuales gestionadas de forma dinámica por el servidor RADIUS.
Habilite el aislamiento de clientes entre VLAN a nivel de AP, pero asegúrese de permitir la comunicación intra-VLAN para que los dispositivos dentro de la misma burbuja de residente puedan comunicarse libremente.
Paso 2: Integración de RADIUS-as-a-Service
El RADIUS en la nube de Purple elimina la necesidad de desplegar y mantener una infraestructura RADIUS local. Configure sus AP para que apunten a los endpoints RADIUS de Purple (primario y secundario para redundancia). Purple funciona con un tiempo de actividad del 99,999 %, lo que garantiza la disponibilidad de la autenticación incluso durante las ventanas de mantenimiento.
Para las propiedades que utilizan Microsoft Entra ID o Okta como proveedor de identidad, Purple se integra a través de SCIM (System for Cross-domain Identity Management) para sincronizar los perfiles de los residentes de forma automática. Esto significa que cuando se añade o elimina a un residente en su proveedor de identidad, su iPSK se aprovisiona o revoca sin intervención manual.
Paso 3: Automatización del ciclo de vida del inquilino
La eficiencia operativa de iPSK depende de la integración con su sistema de gestión de propiedades (PMS). El flujo de trabajo debe ser el siguiente:
Al firmar el contrato: El PMS activa una llamada API a Purple. Purple genera un iPSK único para la vivienda, lo almacena en el perfil del residente y envía por correo electrónico la contraseña al residente. No se requiere intervención manual de TI.
Al mudarse: El residente conecta sus dispositivos utilizando la contraseña enviada por correo electrónico. Todos los dispositivos se ubican inmediatamente en su VLAN aislada. La experiencia es idéntica a la configuración de un router de banda ancha doméstico.
Durante el contrato: El residente utiliza la aplicación de Purple para añadir nuevos dispositivos, comprobar el estado de la conectividad y gestionar su red. Los dispositivos IoT sin interfaz de usuario (enchufes inteligentes, sensores) se pueden registrar por dirección MAC a través del portal de autoservicio.
Al mudarse: El PMS activa una llamada API de revocación. Purple invalida inmediatamente el iPSK del residente. Ningún otro residente se ve afectado. La VLAN de la vivienda queda libre y lista para el próximo residente.
Paso 4: Planificación de RF y ubicación de los puntos de acceso
Reemplazar los routers por unidad con una red gestionada reduce drásticamente el número de transmisores de radio en el edificio. En un edificio de 200 unidades, eliminar 200 routers domésticos elimina una fuente significativa de interferencia de canal compartido. Despliegue AP de clase empresarial en pasillos o en ubicaciones específicas dentro de las unidades, buscando una intensidad de señal de -65 dBm o mejor en el punto más lejano de cada unidad.
Para edificios con paredes de hormigón grueso o distribuciones complejas, utilice AP de montaje en pared desplegados dentro de las unidades en lugar de AP montados en los pasillos. Coordine con las herramientas de planificación de RF del proveedor de sus AP (Cisco Meraki RF Planner, Aruba AirMatch, Ruckus SmartRF) para modelar la cobertura antes de la instalación.
-
Buenas prácticas
Gestión del tráfico de difusión (broadcast)
La alta densidad de dispositivos amplifica el tráfico de difusión. Las tramas mDNS, ARP y SSDP de miles de dispositivos pueden consumir una cantidad de tiempo de transmisión significativa. Active la conversión de Multicast a Unicast en sus AP para convertir las tramas de difusión en transmisiones unicast dirigidas. Esto reduce el desperdicio de tiempo de transmisión y mejora la duración de la batería de los dispositivos móviles.
Para mDNS específicamente, despliegue una pasarela o proxy mDNS (disponible de forma nativa en Cisco Meraki, Aruba y Ruckus) para gestionar el descubrimiento de servicios a través de las VLAN donde sea necesario, como para los servicios de impresión en todo el edificio en las zonas comunes.
CGNAT y tipos de NAT para videojuegos
El agotamiento de las direcciones IPv4 en grandes despliegues requiere el uso de NAT de grado de operador (CGNAT). Sin embargo, las configuraciones estrictas de CGNAT interrumpen el tráfico de videojuegos peer-to-peer, lo que resulta en una NAT de tipo estricto o Tipo 3 en consolas PlayStation y Xbox. Configure su pasarela para admitir UPnP (Universal Plug and Play) o PCP (Port Control Protocol) para las VLAN de los residentes. Esto permite que las consolas negocien automáticamente asignaciones de puertos abiertos sin necesidad de reglas de firewall manuales.
Seguridad y conformidad con el GDPR
Los datos de WiFi de los residentes se encuentran en un contexto de privacidad sensible. Los residentes mantienen una relación continua con el operador, y la exposición de datos se prolonga durante años en lugar de minutos. Las consideraciones clave de cumplimiento incluyen:
El aislamiento de residentes como requisito de privacidad: Bajo el GDPR, los operadores tienen el deber de diligencia de evitar que un residente acceda a los datos o dispositivos de otro. El aislamiento de VLAN de iPSK es el mecanismo técnico que satisface este requisito.
Retención de datos: Conserve los registros de conexión WiFi identificables de los residentes solo durante el tiempo que sea operativamente necesario. Seis meses es un límite máximo habitual por motivos de seguridad y cumplimiento.
Residencia de datos: Purple almacena por defecto los datos en infraestructuras ubicadas en la UE, con opciones de residencia de datos específicas para el Reino Unido tras el Brexit. Purple cuenta con las certificaciones ISO 27001, GDPR y Cyber Essentials.
Consentimiento: Los residentes deben aceptar una política de uso aceptable clara durante el proceso de incorporación. El portal de autoservicio de Purple incluye flujos de consentimiento configurables.
-
Casos de estudio reales
Caso de estudio 1: Promoción BTR de 350 unidades
Un promotor inmobiliario que gestionaba un complejo BTR de 350 unidades en una importante ciudad del Reino Unido se enfrentaba a tres problemas: 350 routers de consumo individuales que generaban graves interferencias de RF, una espera media de 72 horas para la activación de la banda ancha que retrasaba las mudanzas y un equipo de soporte que dedicaba el 40 % de su tiempo a incidencias relacionadas con el WiFi.
El operador desplegó el Multi-Tenant WiFi de Purple en todo el edificio utilizando los AP de Cisco Meraki existentes. Purple se integró con el PMS existente de la propiedad a través de la API. Tras la firma del contrato de arrendamiento, los residentes recibieron su iPSK único por correo electrónico. El día de la mudanza, la conectividad fue instantánea. El entorno de RF mejoró significativamente con la retirada de los 350 routers de consumo, y las velocidades medias en todo el edificio aumentaron un 35 %. Las incidencias de soporte relacionadas con el WiFi disminuyeron un 60 % en los primeros tres meses, lo que se atribuyó al portal de gestión de dispositivos en autoservicio y a la eliminación de los problemas de emparejamiento de dispositivos inteligentes.
Caso de estudio 2: Residencia de estudiantes de 1.200 camas
Un proveedor de alojamiento para estudiantes construido para tal fin (PBSA) necesitaba incorporar a 1.200 estudiantes en un solo fin de semana al inicio del año académico. El sistema anterior de PSK compartido requería que el personal distribuyera manualmente hojas de contraseñas y gestionara cientos de llamadas de soporte de estudiantes que no podían conectar sus videoconsolas y televisiones inteligentes.
Con iPSK desplegado a través de Purple en puntos de acceso de HPE Aruba, cada estudiante recibió su contraseña única con su paquete de bienvenida antes de su llegada. Los estudiantes registraron sus dispositivos sin pantalla (consolas, televisiones inteligentes) a través de la aplicación de Purple durante la semana anterior a la mudanza. El fin de semana de llegada, el equipo de TI gestionó menos de 20 llamadas de soporte de conectividad entre los 1.200 estudiantes, una reducción del 94 % en comparación con el año anterior. La configuración del proxy mDNS resolvió todos los problemas de emparejamiento de Chromecast y AirPlay que anteriormente habían generado el mayor volumen de incidencias.
ROI e impacto empresarial
Para los operadores de BTR y MDU, el caso financiero para el WiFi con iPSK gestionado es evidente. La investigación de la British Property Federation y los propios datos de Purple de más de 80.000 centros activos respaldan los siguientes puntos de referencia:
| Métrica | Punto de referencia | Fuente |
|---|---|---|
| Incremento del alquiler por unidad al mes | £15 - 30 | British Property Federation / Datos de Purple |
| Reducción del periodo de desocupación | 5 - 10 días | Datos de clientes de Purple |
| Reducción de costes por puerta frente a banda ancha individual | 30 - 50 % | Datos de clientes de Purple |
| Clasificación del WiFi en las encuestas de servicios de BTR | Top 5 | British Property Federation |
El impacto en los ingresos operativos netos (NOI) se compone de tres vectores: el incremento directo del alquiler, la reducción de la pérdida de ingresos por periodos de desocupación y la reducción de los costes de soporte de TI. En un edificio de 200 unidades con un incremento de £20 por unidad al mes, el aumento de los ingresos anuales es de £48.000. La eliminación de 200 routers de consumo con un coste medio de sustitución de £80 cada uno ahorra £16.000 solo en hardware en un ciclo de cinco años, sin tener en cuenta el ahorro de energía y el tiempo de mantenimiento.
El modelo de precios de Purple es por unidad y por mes, sin contratos de banda ancha vinculados, lo que significa que el operador captura todo el valor del servicio de WiFi en lugar de compartirlo con un ISP externo.
-
Lecturas adicionales
Para temas relacionados con el diseño de redes, consulte Three SSIDs to rule them all: guest, Passpoint, and IoT WiFi y la guía de referencia iPSK: una guía completa para empresas . Para conocer la plataforma subyacente, explore Guest WiFi y WiFi Analytics . Purple presta servicio a operadores de los sectores de Hospitality , Retail , Healthcare y Transport .
Definiciones clave
iPSK (Identity Pre-Shared Key)
Un mecanismo de autenticación inalámbrica que asigna una contraseña única a cada usuario o dispositivo en un único SSID. La contraseña actúa como una señal de identidad, activando la asignación dinámica de VLAN a través de un servidor RADIUS.
La tecnología que hace posible el aislamiento de la red por residente en entornos BTR y MDU. También llamada PPSK (HPE Aruba), Personal Private Network (Cisco Meraki) o ePSK (Cambium, Juniper Mist).
VLAN (Virtual Local Area Network)
Un segmento de red lógico que agrupa dispositivos en un dominio de difusión aislado, independientemente de su ubicación física en la red.
En despliegues de iPSK, a cada residente se le asigna una VLAN dedicada. Este es el mecanismo técnico que evita que los dispositivos de un residente se comuniquen con los de otro.
RADIUS (Remote Authentication Dial-In User Service)
Un protocolo de red que proporciona autenticación, autorización y contabilidad (AAA) centralizadas para el acceso a la red. Definido en RFC 2865.
El motor de backend que valida las contraseñas de iPSK y devuelve asignaciones de VLAN dinámicas a los puntos de acceso. Purple proporciona RADIUS-as-a-Service, eliminando la necesidad de una infraestructura RADIUS local.
Asignación dinámica de VLAN
El proceso mediante el cual un servidor RADIUS indica a un punto de acceso que coloque un dispositivo autenticado en una VLAN específica, según los atributos de identidad del usuario devueltos en el mensaje Access-Accept.
El mecanismo que crea la burbuja de WiFi por residente en despliegues de iPSK. El ID de VLAN se devuelve como un atributo RADIUS (Tunnel-Private-Group-ID) en la respuesta de autenticación.
802.1X
Un estándar IEEE para el control de acceso a la red basado en puertos (PNAC) que requiere que los dispositivos se autentiquen a través de EAP (Extensible Authentication Protocol) antes de obtener acceso a la red.
Altamente seguro para entornos empresariales pero inadecuado para despliegues residenciales porque la mayoría de los dispositivos IoT de consumo no incluyen un suplicante 802.1X.
mDNS (Multicast DNS)
Un protocolo de red de configuración cero que permite a los dispositivos descubrir servicios en una red local sin un servidor DNS central. Utilizado por Apple AirPlay, Google Cast y muchos dispositivos IoT.
mDNS opera dentro de un único dominio de difusión. En despliegues de iPSK, se requiere un proxy o pasarela mDNS para permitir el descubrimiento de servicios dentro de la VLAN de un residente mientras se bloquea el descubrimiento entre diferentes VLAN.
CGNAT (Carrier-Grade NAT)
Una implementación de traducción de direcciones de red a gran escala que permite que múltiples direcciones IP privadas compartan una única dirección IPv4 pública, utilizada para abordar el agotamiento de IPv4 en grandes despliegues.
Comúnmente requerido en despliegues de MDU con cientos de unidades. Debe configurarse para admitir UPnP o PCP para evitar alterar los tipos de NAT de las videoconsolas.
SCIM (System for Cross-domain Identity Management)
Un protocolo estándar abierto (RFC 7642-7644) para automatizar el intercambio de información de identidad de usuario entre proveedores de identidad y proveedores de servicios.
Utilizado para sincronizar perfiles de residentes entre Microsoft Entra ID u Okta y la plataforma de Purple, lo que permite el aprovisionamiento y la revocación automáticos de iPSK vinculados al ciclo de vida del inquilino.
Ejemplos prácticos
¿Un desarrollo BTR de 250 unidades tiene actualmente routers domésticos individuales en cada apartamento. Los residentes reportan velocidades lentas, desconexiones frecuentes y la imposibilidad de emparejar dispositivos domésticos inteligentes. El gestor de la propiedad recibe entre 30 y 40 llamadas de soporte de WiFi a la semana. ¿Cómo debería el equipo de TI rediseñar esta red?
Retirar los 250 routers domésticos para eliminar la interferencia de radiofrecuencia de canales compartidos. Desplegar AP empresariales (Cisco Meraki MR46 o HPE Aruba AP-635) en pasillos o en el interior de las unidades, buscando una cobertura de -65 dBm en el punto más lejano de cada unidad. Configurar un único SSID con iPSK habilitado, apuntando al RADIUS en la nube de Purple para la autenticación. Integrar Purple con el PMS existente a través de API para que las iPSK únicas se generen y se envíen por correo electrónico a los residentes de forma automática al firmar el contrato de alquiler. Configurar subredes /20 para las VLAN de los clientes con el fin de soportar la densidad de dispositivos prevista de 15 a 25 dispositivos por unidad. Habilitar la conversión de Multicast a Unicast y desplegar un proxy mDNS para resolver los problemas de emparejamiento de dispositivos inteligentes. Desplegar el portal de autoservicio de Purple para que los residentes puedan gestionar sus propios dispositivos sin tener que contactar con el servicio de soporte.
Un proveedor de alojamiento para estudiantes necesita incorporar a 800 estudiantes durante un único fin de semana de mudanza. Los estudiantes traerán portátiles, teléfonos, consolas de videojuegos y televisores inteligentes. El equipo de TI dispone de cuatro personas para el fin de semana. ¿Cómo deben preparar la red y el proceso de incorporación?
Dos semanas antes de la mudanza, enviar a cada estudiante su iPSK única junto con su información de bienvenida. Proporcionar una guía breve que explique cómo conectar sus dispositivos principales (teléfono, portátil) y cómo registrar dispositivos sin pantalla (consolas, televisores inteligentes) a través del portal de autoservicio de Purple. Abrir el portal de autoservicio para el prerregistro de dispositivos una semana antes de la mudanza, de modo que los estudiantes puedan registrar las direcciones MAC antes de llegar. Durante el fin de semana de mudanza, el equipo de TI supervisará el panel de Purple para detectar fallos de autenticación y alertas de agotamiento de DHCP en lugar de atender problemas de conexión individuales. Configurar subredes /21 por planta o bloque para garantizar una capacidad suficiente de direcciones IP. Habilitar UPnP en la puerta de enlace para las VLAN de los residentes con el fin de soportar los requisitos de NAT para videojuegos.
Preguntas de práctica
Q1. Un operador de BTR de 400 unidades desea ofrecer una suscripción premium "Gamer Tier" por un cargo adicional de 15 £ al mes, que proporcione un mayor ancho de banda y un tipo de NAT abierta para videoconsolas. ¿Cómo debería la arquitectura de red admitir este servicio por niveles?
Sugerencia: RADIUS puede devolver más que solo un ID de VLAN. Considere qué otros atributos de política se pueden aplicar por residente y qué configuración de pasarela se requiere para el NAT de videojuegos.
Ver respuesta modelo
Configure el servidor RADIUS para devolver un atributo de política de ancho de banda QoS (por ejemplo, un perfil de limitación de velocidad) junto con el ID de VLAN para los residentes estándar. Para los suscriptores de "Gamer Tier", el servidor RADIUS devuelve un perfil QoS diferente con límites de ancho de banda más altos y una etiqueta que indica a la pasarela que aplique reglas de CGNAT menos restrictivas para esa VLAN. Habilite UPnP o PCP en la pasarela específicamente para las VLAN de Gamer Tier para permitir que las consolas negocien asignaciones de puertos abiertos. La integración con el PMS debe actualizar el perfil RADIUS del residente cuando se suscriba o se dé de baja del nivel, activando un cambio de política inmediato sin requerir volver a autenticarse.
Q2. Un residente informa que su Chromecast aparece como "fuera de línea" en su teléfono, a pesar de que ambos dispositivos están conectados al WiFi del edificio. El equipo de TI confirma que ambos dispositivos están autenticados y tienen direcciones IP. ¿Cuál es la causa más probable y cuál es la solución?
Sugerencia: El descubrimiento de Chromecast se basa en mDNS. Piense en cómo se comporta el tráfico mDNS a través de los límites de las VLAN.
Ver respuesta modelo
La causa más probable es que el teléfono y el Chromecast se encuentren en diferentes VLAN, lo que impide que el tráfico de descubrimiento mDNS llegue a ambos dispositivos. Esto puede ocurrir si los dispositivos se conectaron en momentos diferentes y se les asignaron diferentes alcances de DHCP, o si el residente tiene múltiples claves iPSK. Verifique que ambos dispositivos utilicen la misma iPSK y estén en la misma VLAN. Si el edificio utiliza una única VLAN compartida para todos los residentes (no recomendado), habilite un proxy mDNS para gestionar el descubrimiento de servicios entre VLAN. La solución correcta a largo plazo es garantizar que todos los dispositivos de un residente utilicen la misma iPSK, colocándolos a todos en la misma VLAN aislada donde mDNS funciona de forma nativa.
Q3. Durante un periodo de máxima afluencia por la tarde, el equipo de TI recibe alertas de que el DHCP está fallando para las conexiones de nuevos dispositivos en un edificio de 300 unidades. La investigación muestra que el grupo de DHCP está agotado. ¿Qué falló en el diseño de la red y cómo debería corregirse?
Sugerencia: Piense en la relación entre el número de unidades, los dispositivos por unidad y el tamaño de la subred. ¿Cuál es el número máximo de direcciones IP que proporciona una subred /24?
Ver respuesta modelo
La red se diseñó con subredes /24 para las VLAN de los clientes, lo que proporciona solo 254 direcciones IP utilizables por VLAN. Con 300 unidades de entre 15 y 25 dispositivos cada una, el número potencial de dispositivos es de 4.500 a 7.500. Las subredes /24 están fundamentalmente sobredimensionadas a la baja. La solución inmediata es ampliar el grupo de DHCP migrando a subredes /20 o /21 (que proporcionan 4.094 o 2.046 direcciones respectivamente). Esto requiere actualizar la configuración de VLAN en el switch principal y el alcance del servidor DHCP. La solución a largo plazo es planificar el tamaño de las subredes en función de la densidad de dispositivos (15 a 25 por unidad) en lugar del número de unidades, e implementar alertas de supervisión de DHCP que se activen al 80 % de la utilización del grupo en lugar de al agotarse por completo.
Continúe leyendo esta serie
PPSK WPA3: comparación de características y modelos de implementación
Esta guía de referencia técnica compara PPSK y WPA3-SAE, explicando sus diferencias arquitectónicas y modelos de implementación para entornos multi-inquilino. Ofrece orientación práctica para directores de TI y promotores inmobiliarios sobre cómo lograr redes WiFi seguras y aisladas utilizando las soluciones basadas en identidad de Purple.
PPSK en la práctica: comparación de funciones y modelos de implementación
Esta guía compara PPSK (Private Pre-Shared Key) con PSK estándar y 802.1X, detallando los modelos de implementación para entornos multi-inquilino. Equipa a los directores de IT y operadores de propiedades para implementar un WiFi seguro y aislado para los residentes, que admita dispositivos domésticos inteligentes y genere un valor comercial medible.
PPSK: comparación de características y modelos de implementación
Esta guía técnica detalla la implementación de arquitecturas de Clave Precompartida Privada (PPSK) y Clave Precompartida de Identidad (iPSK) en entornos de alta densidad multiinquilino. Proporciona estrategias de implementación prácticas para promotores inmobiliarios y directores de TI para proteger las redes de los residentes, admitir dispositivos IoT y generar un ROI positivo a través de WiFi gestionado.