Por qué el WiFi para huéspedes de estilo hotelero 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 apartamento amueblado puede albergar 10 o más dispositivos conectados, muchos de ellos sin navegador para completar un Captive Portal, y los residentes esperan que el envío de contenido (casting) y los equipos de hogar inteligente funcionen. En su lugar, asigne a cada hogar su propia clave iPSK y un segmento de red privado.

¿Cómo se manifiesta el fallo del WiFi para huéspedes en un edificio residencial?

El problema rara vez se presenta como una red caída. Se manifiesta como un flujo constante de pequeñas quejas de residentes que pagan un alquiler, no de personas de paso.

Síntomas típicos en un bloque de viviendas de alquiler (BTR), residencia de estudiantes o unidad multifamiliar (MDU):

• La televisión inteligente, el altavoz 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 invitados antes de conceder el acceso.
• El envío de contenido (casting) falla. El teléfono de un residente no puede encontrar su propio receptor Chromecast o AirPlay, o encuentra el del vecino.
• Todos tienen que volver a iniciar sesión cada día. La sesión del portal caduca con un temporizador de 24 horas, lo cual es adecuado para el huésped de un hotel pero molesta a alguien que vive allí.
• 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.
• Las mudanzas dejan accesos activos. El ordenador portátil de un antiguo residente se sigue conectando semanas después de que termine el contrato de alquiler.

Si gestiona Hotels y se está expandiendo a apartamentos con servicios incluidos o de larga estancia, detectará estos síntomas primero en las plantas de larga estancia.

¿Por qué el WiFi para huéspedes de estilo hotelero no funciona para los residentes?

Cuatro supuestos de diseño del WiFi para huéspedes de hoteles dejan de cumplirse una vez que alguien se muda.

El número de dispositivos es diferente

Una red WiFi para huéspedes de hotel se diseña pensando en un teléfono y un ordenador portátil para una o dos noches. En su lugar, cuente los dispositivos de un apartamento de un dormitorio: dos teléfonos, dos ordenadores portátiles, una televisión inteligente, un dispositivo de streaming, un altavoz, un videoportero, un termostato y una impresora. Ya son 10 antes de que venga de visita cualquier persona. Todos y cada uno de ellos necesitan conectarse, y la mayoría no tienen pantalla para escribir.

Los dispositivos sin pantalla (headless) no pueden usar un Captive Portal

Un Captive Portal funciona interceptando una solicitud del navegador y mostrando una página de inicio de sesión. Un altavoz 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.

La aleatorización de direcciones MAC invalida la memoria del dispositivo

Apple introdujo direcciones privadas por red en iOS 14, y Android 10 aleatoriza la dirección de hardware por defecto. Un portal que recuerda los dispositivos por su dirección MAC los pierde cada vez que la dirección cambia. Los residentes tienen que volver a autenticarse y su servicio de asistencia recibe la llamada.

El aislamiento de clientes (client isolation) bloquea la experiencia de red doméstica

Las 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 vestíbulo de un hotel. Pero Chromecast y AirPlay encuentran receptores utilizando DNS multidifusión (mDNS, definido en RFC 6762), un protocolo de descubrimiento que solo funciona entre dispositivos del mismo segmento de red. Con el aislamiento activado, la transmisión de contenido falla. Si desactiva el aislamiento en una red compartida, cada residente podrá ver los dispositivos de todos los demás residentes.

La confianza para estancias cortas es el modelo de confianza equivocado

El WiFi de los hoteles 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 alquiler, 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 puede saber qué causa tiene?

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

Síntoma que notifican los residentes	Causa más probable	Cómo confirmarlo
La Smart TV o el altavoz no se conectan	Captive Portal en un dispositivo sin pantalla	Compruebe 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 con el aislamiento desactivado en un único SSID de prueba
El residente ve los dispositivos de los vecinos al transmitir	Red plana compartida con aislamiento desactivado	Busque anuncios de mDNS desde un dispositivo de 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	Lea el tiempo de espera de la sesión en el SSID de invitados
Dispositivos "olvidados" tras una actualización del teléfono	Aleatorización de MAC frente a la memoria basada en MAC	Compare las direcciones de hardware de los dispositivos antes y después de la actualización
Los antiguos residentes se siguen conectando	No hay vínculo entre el fin del contrato de alquiler y el acceso a la red	Audite las credenciales activas frente a los registros de alquiler actuales

Si las dos primeras filas describen su edificio, solucionar el tiempo de espera de la sesión no servirá de nada. Necesita un modelo de autenticación diferente, no un portal optimizado.

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

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

Enfoque	Incorporación	Dispositivos sin pantalla	Transmisión y hogar inteligente	Revocar un solo hogar	Más adecuado para
Captive Portal (patrón de hotel)	Inicio de sesión en el navegador en cada dispositivo, repetido al expirar el tiempo de espera	Fallan sin el registro manual de MAC	Bloqueado por el aislamiento de clientes	Esperar a que caduquen 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 multi-inquilino
iPSK por hogar	Una contraseña única por apartamento	Se conectan	Funcionan solo dentro del segmento del hogar	Eliminar una clave	BTR, residencias de estudiantes, MDU, estancias de larga duración

iPSK (identidad de clave previamente compartida) ejecuta una única red WPA2-Personal donde cada hogar obtiene 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 ha utilizado. A continuación, la red lo ubica en la VLAN de ese hogar, un segmento de red virtual. Todos los dispositivos que posee un residente, tengan o no pantalla, se conectan una sola vez con una frase de contraseña que ya entienden.

El resultado es una burbuja de red privada por apartamento. El teléfono de un residente encuentra su propio Chromecast porque ambos se encuentran en el mismo segmento. No puede ver el piso 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 smart TV, altavoces y termostatos no pueden utilizarlo. Consérvelo para las redes del personal.

¿Cómo se soluciona en Cisco Meraki, HPE Aruba, Ruckus y otros equipos?

No necesita nuevos puntos de acceso. Cada uno de los principales proveedores admite la autenticación por clave con 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: PPSK (Private Pre-Shared Key)
• Fortinet: MPSK

Compruebe dos cosas en la documentación de su proveedor antes de realizar el cambio. En primer lugar, confirme el número máximo de claves por SSID en la versión de su controlador. En segundo lugar, confirme si WPA3-Personal es compatible con la autenticación por clave, ya que muchas implementaciones todavía funcionan con WPA2-Personal.

El WiFi para Multi-Tenant de Purple funciona como una capa en la nube sobre ese hardware, por lo que no es necesario sustituir equipos. Purple proporciona el servicio RADIUS en la nube que asocia cada clave a su hogar. Usted gestiona 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 funciona en más de 80.000 espacios activos (datos propios de Purple).

Mantenga su red de invitados para las visitas. El WiFi para invitados de Purple crea un registro de visitantes de WiFi para cada visitante que se conecta. Ese registro contiene los espacios visitados, el número de visitas y el método de conexión, de acuerdo con el artículo de soporte de visitantes de WiFi de Purple. Eso es adecuado para un vestíbulo o una cafetería en la planta baja, no para la conexión doméstica de un residente.

Escenario práctico: un hotel añade una planta para estancias de larga duración

Situación. Un hotel urbano de 180 habitaciones convirtió una planta en 40 apartamentos con servicios incluidos para estancias de uno a seis meses. Los huéspedes de larga duración utilizaban el SSID de invitados existente, con un Captive Portal, aislamiento de clientes y un tiempo de espera de sesión de 24 horas.

Qué se hizo. El hotel mantuvo el SSID del portal para las habitaciones de estancia corta y el vestíbulo. Añadió un SSID iPSK para la planta de estancia larga, con 40 claves, cada una de ellas asignada a su propia VLAN. Las claves se entregaban en el momento del registro de entrada y se eliminaban en el del registro de salida.

Resultado. Los inicios de sesión por huésped de estancia larga pasaron de siete a la semana a uno a la llegada. Las Smart TV y los dispositivos de transmisión se conectaron al primer intento porque ya no se encontraban con un portal. Al registrar la salida, la eliminación de una sola clave eliminaba todos los dispositivos que ese apartamento había conectado.

Caso práctico: las residencias universitarias sustituyen el registro de direcciones MAC

Situación. Una universidad pública gestionaba una residencia de 600 camas con un portal cautivo. Los estudiantes registraban las videoconsolas y los altavoces inteligentes introduciendo cada dirección MAC en un formulario web. Las direcciones aleatorias en los teléfonos obligaban a volver a registrarse cada trimestre.

Qué se hizo. El departamento de TI emitió una clave iPSK por cada habitación de estudio en los puntos de acceso existentes. Cada estudiante recibió su clave 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 se redujeron a cero, ya que las consolas y los altavoces se conectan ahora con una contraseña. Al final del curso académico, el departamento de TI revocó las 600 claves en un solo lote en lugar de tener que rastrear los registros de cada dispositivo de forma individual.

¿Cómo evitar que vuelva a ocurrir?

Diseñe la red de residentes en función del arrendamiento, no de la visita.

1. Separe las redes por público. Ejecute un SSID de invitados con un portal para los visitantes y un SSID iPSK para los residentes. Mantenga un número bajo de SSID, ya que cada SSID adicional añade tráfico de balizas y consume tiempo de transmisión de aire.
2. Asocie las claves a las altas, traslados y bajas. Entregue una clave al mudarse, asígnela de nuevo cuando un residente se mude de unidad y revóquela en la fecha de finalización del contrato. Multi-Tenant WiFi de Purple gestiona este ciclo de vida de forma centralizada.
3. Planifique la capacidad por apartamento, no por persona. Dimensione cada unidad para el número total de sus dispositivos, incluida la transmisión en directo en las horas punta de la tarde.
4. Mantenga los modelos de datos separados. El WiFi de invitados existe en parte para crear datos de origen con opciones de consentimiento explícito e informado. El WiFi para residentes es un servicio que usted ofrece en virtud del contrato de alquiler, por lo que no debe realizar capturas 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 centros de uso mixto. Un edificio con locales de Retail en la planta baja, o alojamiento para el personal en un campus de Healthcare, necesita un portal para el público e iPSK para las personas que viven allí.

Preguntas frecuentes

¿Puedo utilizar un portal cautivo para los residentes?

No, no como la red principal para residentes. Un Captive Portal necesita un navegador en cada dispositivo, y las televisiones inteligentes, altavoces y termostatos no disponen de uno. Los portales también caducan las sesiones y olvidan los dispositivos cuyas direcciones de hardware rotan. Mantenga un portal para los visitantes y huéspedes de estancia corta. Proporcione a los residentes una clave iPSK por hogar para que cada dispositivo se conecte una sola vez y permanezca conectado durante toda la duración del alquiler.

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

Sí, si utiliza un controlador actual de un fabricante principal. 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 fabricante 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 tendrá que sustituir los puntos de acceso para trasladar a los residentes a iPSK.

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

Sí. Ejecútelas como SSIDs independientes en los mismos puntos de acceso, cada una mapeada 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 su clave de hogar. Mantenga bajo el recuento total de SSIDs, ya que cada SSID adicional añade tráfico de baliza que consume tiempo de transmisión en cada punto de acceso que la emita.

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

Usted revoca su clave y todos los dispositivos que la utilizaban pierden el acceso. Dado que cada hogar tiene su propia contraseña, una sola eliminación desconecta el teléfono, el portátil, la televisión y el altavoz a la vez, sin afectar a ningún otro residente. Vincule la revocación de la clave a la fecha de finalización del contrato de alquiler para que el acceso termine el mismo día en que finaliza el contrato, en lugar de cuando alguien se acuerde de cambiar una contraseña.

¿Es iPSK tan seguro como 802.1X?

No, pero es el control adecuado para los dispositivos residenciales. IEEE 802.1X proporciona a cada persona una credencial individual, lo que resulta idóneo para los portátiles del personal. La mayoría de las televisiones inteligentes y altavoces no pueden utilizarlo, por lo que no resulta viable en los apartamentos. iPSK proporciona a cada hogar una clave única y lo aísla en su propia VLAN, de modo que la filtración de una clave expone a un solo apartamento, no a todo el edificio. Utilice 802.1X para el personal e iPSK para los residentes.

¿Cómo se aplica el GDPR de forma diferente a la red WiFi de residentes?

Bajo el UK GDPR, la conexión de un residente es un servicio que usted proporciona en virtud del contrato de alquiler, por lo que la base legal probablemente sea el contrato según el Artículo 6(1)(b), no el consentimiento de marketing. La red WiFi de invitados suele recopilar datos de marketing mediante consentimiento expreso. Mantenga ambas redes separadas: no ejecute la captura de datos 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 sobre esa base.

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

Se trata de un cambio de configuración, no de un proyecto de hardware. Cree un SSID iPSK en su controlador existente, conéctelo a un servicio RADIUS como el RADIUS en la nube de Purple y asocie las claves a las VLAN de cada vivienda. La tarea más compleja es de carácter operativo: emitir las claves en el momento de la mudanza y vincular la revocación a las fechas de finalización del contrato de alquiler. Ejecute el portal y las redes iPSK en paralelo durante la transición para que ningún residente pierda el acceso.