Por qué el WiFi para huéspedes estilo hotel falla en los edificios residenciales

El WiFi para huéspedes de estilo hotelero falla en los edificios residenciales porque asume una estancia corta, un teléfono y un navegador. Un departamento amueblado puede albergar 10 o más dispositivos conectados, muchos de ellos sin un navegador para completar un Captive Portal, y los residentes esperan que la transmisión de contenido y los equipos de hogar inteligente funcionen. En su lugar, brinde a cada hogar su propia clave iPSK y un segmento de red privada.\n\n## ¿Cómo se ve el fracaso del WiFi para huéspedes en un edificio residencial?\n\nLa falla rara vez se presenta como una red inactiva. Se manifiesta como un flujo constante de pequeñas quejas por parte de residentes que pagan renta, no que van de paso.\n\nSíntomas típicos en un bloque de viviendas para renta (BTR), residencias estudiantiles o unidades multifamiliares (MDU):\n\n- La televisión inteligente, la bocina o el termostato no se conectan. Estos dispositivos no tienen navegador, por lo que no pueden completar un Captive Portal, la página de inicio de sesión web que muestra una red de huéspedes antes de otorgar acceso.\n- La transmisión de contenido (casting) falla. El teléfono de un residente no puede encontrar su propio Chromecast o receptor AirPlay, o bien encuentra el del vecino.\n- Todos vuelven a iniciar sesión todos los días. La sesión del portal expira con un temporizador de 24 horas, lo cual es adecuado para el huésped de un hotel pero molesta a alguien que vive ahí.\n- Los dispositivos se desconectan después de una actualización de software. Los teléfonos que rotan su dirección de hardware parecen dispositivos nuevos, por lo que la red los olvida.\n- Las mudanzas dejan el acceso activo. La laptop de un exresidente se sigue conectando semanas después de que terminó el contrato de arrendamiento.\n\nSi administra Hotels y se está expandiendo a departamentos con servicios incluidos o de estancia prolongada, se encontrará con estos síntomas primero en los pisos de estancia prolongada.\n\n## ¿Por qué el WiFi para huéspedes de estilo hotelero no funciona para los residentes?\n\nCuatro supuestos de diseño detrás del WiFi para huéspedes de hoteles dejan de cumplirse una vez que alguien se muda.\n\n### La cantidad de dispositivos es diferente\n\nUna red de huéspedes de hotel se diseña pensando en un teléfono y una laptop para una o dos noches. En cambio, cuente los dispositivos en un departamento de una habitación: dos teléfonos, dos laptops, una televisión inteligente, un dispositivo de streaming, una bocina, un videoportero, un termostato y una impresora. Eso suma 10 antes de recibir visitas. Cada uno de ellos necesita conectarse y la mayoría no tiene pantalla para escribir.\n\n### Los dispositivos sin pantalla no pueden usar un Captive Portal\n\nUn Captive Portal funciona interceptando una solicitud del navegador y mostrando una página de inicio de sesión. Una bocina inteligente nunca abre un navegador, por lo que nunca ve la página y nunca se autentica. La solución habitual es el registro de direcciones MAC, donde el residente escribe la dirección de hardware de cada dispositivo en un formulario. Eso también falla.\n\n### La aleatorización de direcciones MAC debilita la memoria del dispositivo\n\nApple introdujo direcciones privadas por red en iOS 14, y Android 10 aleatoriza la dirección de hardware de forma predeterminada. Un portal que recuerda los dispositivos por dirección MAC los pierde cada vez que la dirección cambia. Los residentes se vuelven a autenticar y su centro de soporte recibe la llamada.\n\n### El aislamiento de clientes bloquea la experiencia de red en el hogar\n\nLas redes de invitados normalmente aíslan a los clientes para que los extraños no puedan acceder a los dispositivos de los demás. Eso es correcto en el lobby de un hotel. Pero Chromecast y AirPlay encuentran receptores mediante DNS multicast (mDNS, definido en el RFC 6762), un protocolo de detección que solo funciona entre dispositivos en el mismo segmento de red. Con el aislamiento activado, la transmisión de contenido falla. Si se desactiva el aislamiento en una red compartida, cada residente podrá ver los dispositivos de todos los demás.

La confianza para estancias cortas es el modelo de confianza equivocado

El WiFi de un hotel confía en un dispositivo durante una estancia y luego lo olvida. El WiFi para residentes tiene que confiar en los dispositivos de un hogar durante la duración de un contrato de arrendamiento, a veces años. También tiene que revocar esa confianza en una fecha específica. Un temporizador de sesión de portal no puede expresar ninguna de las dos reglas.

¿Cómo determinar cuál es la causa que tiene?

Asocie la queja con la causa antes de cambiar cualquier cosa. La mayoría de los edificios tienen más de una.

Síntoma que reportan los residentes	Causa más probable	Cómo confirmarlo
La Smart TV o bocina inteligente no se conecta	Captive Portal en un dispositivo sin pantalla	Verifique si el dispositivo llega a la página del portal en los registros de su controlador
El teléfono no encuentra su propio Chromecast	El aislamiento de clientes bloquea mDNS	Pruebe la transmisión de contenido con el aislamiento desactivado en un solo SSID de prueba
El residente ve los dispositivos de los vecinos al transmitir	Red plana compartida con aislamiento desactivado	Busque anuncios de mDNS desde el dispositivo de un residente
Inicios de sesión diarios en cada dispositivo	El tiempo de espera de la sesión del portal está diseñado para estancias cortas	Revise el tiempo de espera de la sesión en el SSID de invitados
Dispositivos "olvidados" después de una actualización de teléfono	Aleatorización de MAC frente a la memoria basada en MAC	Compare las direcciones de hardware del dispositivo antes y después de la actualización
Los antiguos residentes se siguen conectando	No hay vínculo entre el fin del arrendamiento y el acceso a la red	Audite las credenciales activas frente a los registros de arrendamiento actuales

Si las dos primeras filas describen su edificio, corregir el tiempo de espera de la sesión no ayudará. Necesita un modelo de autenticación diferente, no un portal ajustado.

¿Qué modelo de autenticación se adapta a los residentes?

La siguiente tabla compara las cuatro opciones que realmente operan los edificios.

Enfoque	Incorporación	Dispositivos sin pantalla	Transmisión y hogar inteligente	Revocación de un hogar	Ideal para
Captive Portal (modelo de hotel)	Inicio de sesión en el navegador de cada dispositivo, repetido al expirar el tiempo de espera	Fallan sin el registro manual de MAC	Bloqueados por el aislamiento de clientes	Esperar a que expiren las sesiones	Huéspedes de hotel, compradores, aficionados, pasajeros
Una contraseña compartida por edificio	Una contraseña para todos	Se conectan	Funcionan, pero cada residente ve todos los dispositivos	Cambiar la contraseña para todo el edificio	Ningún edificio multifamiliar
iPSK por hogar	Una contraseña única por departamento	Se conectan	Funcionan solo dentro del segmento del hogar	Eliminar una sola clave	BTR, residencias estudiantiles, MDU, estancias largas

iPSK (identity pre-shared key) ejecuta una sola red WPA2-Personal donde cada hogar recibe su propia frase de contraseña. Cuando un dispositivo se conecta, un servidor RADIUS, el servicio de autenticación que verifica las credenciales, identifica qué clave se utilizó. Luego, la red lo coloca en la VLAN de ese hogar, un segmento de red virtual. Cada dispositivo que posee un residente, tenga pantalla o no, se conecta una sola vez con una frase de contraseña que ya comprende.

El resultado es una burbuja de red privada por departamento. El teléfono de un residente encuentra su propio Chromecast porque ambos se encuentran en el mismo segmento. No puede ver el departamento de al lado porque ese hogar tiene una clave diferente y se encuentra en un segmento distinto.

IEEE 802.1X es más sólido por persona, pero la mayoría de las televisiones inteligentes, bocinas y termostatos no pueden usarlo. Consérvelo para las redes del personal.

¿Cómo se soluciona esto en Cisco Meraki, HPE Aruba, Ruckus y otro hardware?

No necesita nuevos puntos de acceso. Cada uno de los principales proveedores soporta la autenticación por clave bajo su propio nombre:

• Cisco Meraki: Identity PSK (iPSK)
• HPE Aruba: MPSK (Multiple Pre-Shared Key)
• Ruckus: DPSK (Dynamic Pre-Shared Key)
• Juniper Mist: Multi PSK
• Ubiquiti UniFi: Private Pre-Shared Keys
• Cambium: ePSK
• Extreme Networks: PPSK (Private Pre-Shared Key)
• Fortinet: MPSK

Verifique dos cosas en la documentación de su proveedor antes de realizar el cambio. Primero, confirme el número máximo de claves por SSID en la versión de su controlador. Segundo, confirme si se soporta WPA3-Personal con autenticación por clave, ya que muchas implementaciones aún se ejecutan en WPA2-Personal.

El WiFi Multi-Tenant de Purple funciona como una superposición en la nube sobre ese hardware, por lo que no es necesario desinstalar ni reemplazar nada. Purple proporciona el servicio RADIUS en la nube que mapea cada clave a su respectivo hogar. Usted administra las claves de cada edificio desde un único panel de control. Purple cuenta con la certificación ISO 27001 y cumple con el GDPR, y la plataforma se ejecuta en más de 80,000 ubicaciones activas (datos propios de Purple).

Conserve su red de invitados para los visitantes. El Guest WiFi de Purple crea un registro de WiFi Visitors para cada visitante que se conecta. Ese registro contiene los lugares visitados, el número de visitas y el método de conexión, de acuerdo con el artículo de soporte de WiFi Visitors de Purple. Esto es adecuado para un lobby o una cafetería en la planta baja, no para la conexión residencial de un habitante.

Escenario de ejemplo: un hotel añade un piso para estancias prolongadas

Situación. Un hotel urbano de 180 habitaciones convirtió un piso en 40 departamentos amueblados con servicios incluidos para estancias de uno a seis meses. Los huéspedes de estancia prolongada utilizaban el SSID de invitados existente, con un captive portal, aislamiento de clientes y un límite de tiempo de sesión de 24 horas.

Qué se hizo. El hotel mantuvo el SSID del portal para las habitaciones de estancia corta y el lobby. Agregó un SSID de iPSK para el piso de estancia prolongada, con 40 claves, cada una asignada a su propia VLAN. Las claves se entregaban al hacer el check-in y se eliminaban al hacer el check-out.

Resultado. Los inicios de sesión por huésped de estancia prolongada disminuyeron de siete a la semana a uno a su llegada. Las Smart TV y los dispositivos de transmisión se conectaron al primer intento porque ya no se topaban con un portal. Al hacer el check-out, la eliminación de una sola clave desconectaba todos los dispositivos que ese departamento había enlazado.

Escenario práctico: residencias universitarias reemplazan el registro de MAC

Situación. Una universidad pública operaba una residencia de 600 camas mediante un captive portal. Los estudiantes registraban consolas de videojuegos y bocinas inteligentes escribiendo cada dirección MAC en un formulario web. Las direcciones aleatorias en los teléfonos inteligentes implicaban volver a realizar el registro cada periodo escolar.

Qué se hizo. El departamento de TI emitió una clave iPSK por dormitorio de estudio en los puntos de acceso existentes. Cada estudiante recibió su clave junto con la asignación de su habitación. Las claves se vincularon a la fecha de finalización del contrato de alojamiento.

Resultado. Los registros manuales de direcciones MAC disminuyeron a cero, ya que las consolas y bocinas ahora se conectan mediante una contraseña. Al final del año académico, TI revocó las 600 claves en un solo lote en lugar de tener que buscar registros de dispositivos individuales.

¿Cómo evitar que vuelva a suceder?

Diseñe la red residencial en torno al periodo de arrendamiento, no a la visita.

1. Separe las redes por público. Utilice un SSID de invitados con un portal para los visitantes y un SSID de iPSK para los residentes. Mantenga bajo el número de SSID, ya que cada SSID adicional genera tráfico de balizamiento y consume tiempo de aire.
2. Vincule las claves a las altas, cambios y bajas de usuarios. Emita una clave al momento de la mudanza, reasígnala si el residente cambia de unidad y revóquela en la fecha de finalización del contrato. El WiFi multiinquilino de Purple gestiona este ciclo de vida de forma centralizada.
3. Planifique la capacidad por departamento, no por persona. Dimensione cada unidad para el número total de sus dispositivos, incluyendo la transmisión de video en las horas pico de la noche.
4. Mantenga los modelos de datos separados. El WiFi de invitados existe en parte para recopilar datos de primera mano con opciones de participación por elección consciente. El WiFi para residentes es un servicio que se ofrece bajo el contrato de arrendamiento, por lo que no debe aplicar la captación de marketing en él. Si desea comprender cómo se utilizan los espacios compartidos, lea Análisis de presencia frente a análisis de interacción. Si utiliza HPE Aruba, lea Análisis de presencia de HPE Aruba Central: configuración, exportaciones y límites.
5. Aplique el mismo patrón en sitios de uso mixto. Un edificio con unidades de Retail en la planta baja, o alojamiento para el personal en un campus de Healthcare, requiere un portal para el público en general e iPSK para las personas que viven allí.

Preguntas frecuentes

¿Puedo usar un captive portal para residentes?

No, no como la red principal para residentes. Un captive portal requiere un navegador en cada dispositivo, y las smart TVs, bocinas y termostatos no lo tienen. Los portales también vencen las sesiones y olvidan los dispositivos cuyas direcciones de hardware rotan. Mantenga un portal para visitantes y huéspedes de estadías cortas. Proporcione a los residentes una clave iPSK por hogar para que cada dispositivo se conecte una sola vez y permanezca conectado durante la vigencia del contrato de arrendamiento.

¿Funcionará iPSK en los puntos de acceso que ya tengo?

Sí, si utiliza un controlador actual de un proveedor importante. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet admiten la autenticación por clave bajo sus propios nombres de función. Consulte la documentación de su proveedor para conocer el número máximo de claves por SSID en la versión de su controlador. Purple se ejecuta como una superposición en la nube en ese hardware, por lo que no es necesario reemplazar los puntos de acceso para migrar a los residentes a iPSK.

¿Pueden coexistir la red WiFi para invitados y la de residentes en los mismos puntos de acceso?

Sí. Utilícelas como SSIDs independientes en los mismos puntos de acceso, cada una asignada a sus propias VLANs. Los visitantes verán la red de invitados con su captive portal, y los residentes se unirán a la red iPSK con la clave de su hogar. Mantenga bajo el recuento total de SSIDs, ya que cada SSID adicional agrega tráfico de baliza (beacon) que consume tiempo de transmisión en cada punto de acceso que lo transmite.

¿Qué sucede con los dispositivos de un residente cuando se muda?

Usted revoca su clave y todos los dispositivos que la usaban perderán el acceso. Como cada hogar tiene su propia frase de contraseña, una sola eliminación desconecta el teléfono, la laptop, la TV y la bocina al mismo tiempo, sin afectar a ningún otro residente. Vincule la revocación de la clave a la fecha de finalización del contrato de arrendamiento para que el acceso termine el mismo día en que vence el contrato, en lugar de depender de que alguien se acuerde de cambiar una contraseña.

¿Es iPSK tan seguro como 802.1X?

No, pero es el control adecuado para dispositivos residenciales. El estándar 802.1X proporciona a cada persona una credencial individual, lo cual es ideal para las laptops del personal. La mayoría de las smart TVs y bocinas no pueden utilizarlo, por lo que no funciona en departamentos. iPSK otorga a cada hogar una clave única y lo aísla en su propia VLAN, de modo que una clave filtrada expone a un solo departamento, no a todo el edificio. Utilice 802.1X para el personal e iPSK para los residentes.

¿Cómo se aplica el GDPR de manera diferente al WiFi para residentes?

Bajo el UK GDPR, la conexión de un residente es un servicio que usted proporciona en virtud del contrato de arrendamiento, por lo que la base legal probablemente sea contractual según el Artículo 6(1)(b), no el consentimiento de marketing. El WiFi para invitados generalmente recopila datos de marketing con opciones de suscripción (opt-in). Mantenga ambos separados: no realice capturas de marketing en la red de residentes. Purple cuenta con la certificación ISO 27001 y cumple con el GDPR, y procesa los datos de la red de residentes bajo esa base.

¿Cuánto esfuerzo requiere migrar de un portal a iPSK?

Se trata de un cambio de configuración, no de un proyecto de hardware. Usted crea un SSID iPSK en su controlador existente, lo conecta a un servicio RADIUS como el RADIUS en la nube de Purple y asocia las claves a las VLAN de cada vivienda. La tarea más compleja es operativa: emitir claves al momento de la mudanza y vincular la revocación de accesos a las fechas de finalización del contrato de arrendamiento. Ejecute el portal y las redes iPSK de forma simultánea durante la transición para que ningún residente pierda el acceso.