Por que o WiFi de hóspedes estilo hotel falha em edifícios residenciais

O WiFi para visitantes no estilo de hotel falha em edifícios residenciais porque pressupõe uma estadia curta, um telefone e um navegador. Um apartamento mobiliado pode ter 10 ou mais dispositivos conectados, muitos sem navegador para completar um Captive Portal, e os moradores esperam que a transmissão de tela e os kits de casa inteligente funcionem. Em vez disso, forneça a cada residência sua própria chave iPSK e segmento de rede privada.

Como é a falha do WiFi de visitantes em um edifício residencial?

O problema raramente aparece como uma rede inativa. Ele se manifesta como um fluxo de pequenas reclamações de moradores que estão pagando aluguel, e não apenas de passagem.

Sintomas típicos em um bloco build to rent (BTR), residência estudantil ou unidade multifamiliar (MDU):

• A smart TV, o alto-falante ou o termostato não se conectam. Esses dispositivos não têm navegador, portanto não conseguem preencher um Captive Portal, a página de login da web que uma rede de visitantes exibe antes de conceder o acesso.
• A transmissão de tela falha. O telefone de um morador não consegue encontrar seu próprio Chromecast ou receptor AirPlay, ou encontra o do vizinho.
• Todos precisam fazer login novamente todos os dias. A sessão do portal expira em um timer de 24 horas, o que serve para um hóspede de hotel, mas irrita quem mora lá.
• Os dispositivos desconectam após uma atualização de software. Celulares que alteram seu endereço de hardware parecem novos dispositivos, então a rede os esquece.
• As mudanças de moradores deixam acessos ativos. O notebook de um ex-morador ainda se conecta semanas após o término do contrato de locação.

Se você administra Hotéis e está se expandindo para apartamentos de estadia prolongada ou com serviços inclusos, você encontrará esses sintomas primeiro nos andares de estadia prolongada.

Por que o WiFi de visitantes no estilo de hotel não funciona para moradores?

Quatro premissas de design por trás do WiFi de visitantes de hotéis deixam de ser válidas assim que alguém se muda.

O número de dispositivos é diferente

Uma rede de visitantes de hotel é projetada para um telefone e um notebook por uma ou duas noites. Em vez disso, conte os dispositivos em um apartamento de um quarto: dois telefones, dois notebooks, uma smart TV, um dispositivo de streaming, um alto-falante inteligente, uma campainha de vídeo, um termostato e uma impressora. São 10 dispositivos antes mesmo de receber visitas. Cada um deles precisa se conectar, e a maioria não tem tela para digitar.

Dispositivos sem tela não podem usar um Captive Portal

Um Captive Portal funciona interceptando uma solicitação de navegador e mostrando uma página de login. Um alto-falante inteligente nunca abre um navegador, então nunca vê a página e nunca se autentica. A solução alternativa usual é o registro de endereço MAC, no qual o morador digita o endereço de hardware de cada dispositivo em um formulário. Isso também falha.

A randomização de MAC prejudica a memória do dispositivo

A Apple introduziu endereços privados por rede no iOS 14, e o Android 10 randomiza o endereço de hardware por padrão. Um portal que lembra dos dispositivos pelo endereço MAC os perde sempre que o endereço muda. Os moradores precisam se autenticar novamente, e sua equipe de suporte recebe a ligação.

O isolamento de clientes bloqueia a experiência de rede doméstica

As redes de convidados normalmente isolam os clientes para que estranhos não consigam acessar os dispositivos uns dos outros. Isso está correto para o saguão de um hotel. Mas o Chromecast e o AirPlay encontram receptores usando DNS multicast (mDNS, definido na RFC 6762), um protocolo de descoberta que só funciona entre dispositivos no mesmo segmento de rede. Com o isolamento ativado, a transmissão falha. Se desativar o isolamento em uma rede compartilhada, todos os moradores poderão ver os dispositivos de todos os outros moradores.

A confiança de curta duração é o modelo de confiança errado

O WiFi de hotéis confia em um dispositivo durante uma estadia e depois o esquece. O WiFi para moradores precisa confiar nos dispositivos de uma residência durante o período do contrato de locação, às vezes por anos. Ele também precisa revogar essa confiança em uma data específica. Um temporizador de sessão de portal não consegue expressar nenhuma dessas regras.

Como identificar qual é a causa do seu problema?

Associe a reclamação à causa antes de alterar qualquer coisa. A maioria dos edifícios apresenta mais de uma.

Sintoma relatado pelos moradores	Causa mais provável	Como confirmar
Smart TV ou alto-falante não conecta	Captive Portal em um dispositivo sem tela	Verifique nos logs do seu controlador se o dispositivo chega a acessar a página do portal
O celular não encontra o próprio Chromecast	Isolamento de cliente bloqueando mDNS	Teste a transmissão com o isolamento desativado em um único SSID de teste
O morador vê os dispositivos dos vizinhos ao transmitir	Rede compartilhada plana com isolamento desativado	Monitore anúncios de mDNS a partir do dispositivo de um morador
Logins diários em todos os dispositivos	Expiração de sessão do portal projetada para estadias curtas	Verifique o tempo limite de sessão no SSID de convidados
Dispositivos "esquecidos" após atualização do celular	Randomização de MAC contra memória baseada em MAC	Compare os endereços de hardware do dispositivo antes e depois da atualização
Antigos moradores ainda se conectam	Falta de vínculo entre o fim do contrato e o acesso à rede	Audite as credenciais ativas em relação aos registros atuais de locação

Se as duas primeiras linhas descrevem o seu edifício, ajustar o tempo limite de sessão não ajudará. Você precisa de um modelo de autenticação diferente, e não de um portal otimizado.

Qual modelo de autenticação se adapta melhor aos moradores?

A tabela abaixo compara as quatro opções que os edifícios realmente utilizam.

Abordagem	Integração	Dispositivos sem tela	Transmissão e casa inteligente	Revogação de uma única residência	Mais indicado para
Captive Portal (padrão de hotel)	Login pelo navegador em cada dispositivo, repetido no tempo limite	Falha sem o registro manual do MAC	Bloqueado pelo isolamento de cliente	Aguardar a expiração das sessões	Convidados de hotéis, compradores, fãs, passageiros
Uma senha compartilhada por edifício	Uma senha para todos	Conectam	Funcionam, mas cada morador vê todos os dispositivos	Alterar a senha de todo o edifício	Nenhum edifício multi-inquilino
iPSK por residência	Uma senha exclusiva por apartamento	Conectam	Funcionam apenas dentro do segmento da residência	Excluir uma chave	BTR, residências estudantis, MDU, longa estadia

O iPSK (identity pre-shared key) executa uma única rede WPA2-Personal onde cada residência recebe sua própria senha. Quando um dispositivo se conecta, um servidor RADIUS, o serviço de autenticação que verifica as credenciais, identifica qual chave foi utilizada. A rede então o coloca na VLAN daquela residência, um segmento de rede virtual. Cada dispositivo que um residente possui, com ou sem interface visual, conecta-se uma vez com uma senha que ele já entende.

O resultado é uma bolha de rede privada por apartamento. O telefone de um residente encontra seu próprio Chromecast porque ambos estão no mesmo segmento. Ele não consegue ver o apartamento ao lado porque aquela residência possui uma chave diferente e está em um segmento diferente.

O IEEE 802.1X é mais forte por pessoa, mas a maioria das smart TVs, alto-falantes e termostatos não podem usá-lo. Mantenha-o para redes de funcionários.

Como resolver isso no Cisco Meraki, HPE Aruba, Ruckus e outros hardwares?

Você não precisa de novos pontos de acesso. Cada grande fabricante suporta a autenticação por chave sob seu próprio nome:

• 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

Verifique duas coisas na documentação do seu fabricante antes de mudar. Primeiro, confirme o número máximo de chaves por SSID na versão do seu controlador. Segundo, confirme se o WPA3-Personal é suportado com autenticação por chave, já que muitas implementações ainda rodam em WPA2-Personal.

O Multi-Tenant WiFi da Purple funciona como uma sobreposição em nuvem sobre esse hardware, de modo que não há necessidade de substituição total de equipamentos. A Purple fornece o serviço RADIUS em nuvem que mapeia cada chave para sua respectiva residência. Você gerencia as chaves de cada edifício a partir de uma única interface de gerenciamento. A Purple possui certificação ISO 27001 e está em conformidade com o GDPR, e a plataforma roda em mais de 80.000 locais ativos (dados da própria Purple).

Mantenha sua rede de convidados para visitantes. O Guest WiFi da Purple cria um registro de WiFi Visitors para cada visitante que se conecta. Esse registro contém os locais visitados, a contagem de visitas e o método de conexão, de acordo com o artigo de suporte de WiFi Visitors da Purple. Isso é adequado para um lobby ou um café no andar térreo, não para a conexão doméstica de um residente.

Cenário prático: um hotel adiciona um andar para estadias de longa duração

Situação. Um hotel urbano de 180 quartos converteu um andar em 40 apartamentos com serviços para estadias de um a seis meses. Os hóspedes de longa duração usavam o SSID de convidados existente, com um Captive Portal, isolamento de cliente e um limite de tempo de sessão de 24 horas.

O que foi feito. O hotel manteve o SSID do portal para quartos de curta permanência e o lobby. Adicionou um SSID iPSK para o andar de longa permanência, com 40 chaves, cada uma mapeada para sua própria VLAN. As chaves eram emitidas no check-in e excluídas no check-out.

Resultado. Os logins por hóspede de longa permanência caíram de sete por semana para apenas um na chegada. Smart TVs e dispositivos de transmissão conectavam-se na primeira tentativa porque não encontravam mais um portal. No check-out, a exclusão de uma única chave removia todos os dispositivos que aquele apartamento havia conectado.

Caso prático: residências universitárias substituem o registro de MAC

Situação. Uma universidade pública administrava uma residência estudantil de 600 leitos com um Captive Portal. Os estudantes registravam consoles de videogame e alto-falantes inteligentes digitando cada endereço MAC em um formulário web. Os endereços aleatórios nos telefones resultavam em novos registros a cada período letivo.

O que foi feito. O departamento de TI emitiu uma chave iPSK por quarto de estudante nos access points existentes. Cada estudante recebeu sua chave junto com a atribuição do quarto. As chaves foram vinculadas à data de término do contrato de acomodação.

Resultado. Os registros manuais de MAC caíram para zero, pois os consoles e alto-falantes agora se conectam por meio de uma senha. Ao final do ano acadêmico, a TI revogou todas as 600 chaves em um único lote, em vez de buscar registros de dispositivos individuais.

Como evitar que isso aconteça novamente?

Projete a rede de residentes em torno do contrato de locação, não da visita.

1. Separe as redes por público. Execute um SSID de visitante com um portal para visitantes e um SSID iPSK para residentes. Mantenha o número de SSIDs baixo, pois cada SSID extra adiciona tráfego de beacon e consome tempo de transmissão.
2. Vincule as chaves a quem chega, se muda ou sai. Emita uma chave na mudança de entrada, reatribua-a quando um residente mudar de unidade e revogue-a na data de término do contrato. O Multi-Tenant WiFi da Purple gerencia esse ciclo de vida de forma centralizada.
3. Planeje a capacidade por apartamento, não por pessoa. Dimensione cada unidade para o número total de dispositivos, incluindo streaming nos horários de pico da noite.
4. Mantenha os modelos de dados separados. O WiFi de convidados existe em parte para criar dados primários com opt-ins de escolha consciente. O WiFi de residentes é um serviço que você fornece sob o contrato de locação, portanto, não realize captura de marketing nele. Se você quiser entender como os espaços compartilhados são usados, leia Presence analytics vs engagement analytics. Se você utiliza HPE Aruba, leia HPE Aruba Central presence analytics: setup, exports and limits.
5. Aplique o mesmo padrão em locais de uso misto. Um edifício com unidades de Varejo no térreo, ou acomodações para funcionários em um campus de Saúde, precisa de um portal para o público e de iPSK para as pessoas que moram lá.

Perguntas frequentes

Posso usar um Captive Portal para residentes?

Não, não como a rede principal de residentes. Um captive portal necessita de um navegador em cada dispositivo, e smart TVs, alto-falantes e termostatos não possuem um. Os portais também expiram sessões e esquecem dispositivos cujos endereços de hardware rotacionam. Mantenha um portal para visitantes e hóspedes de curta permanência. Forneça aos residentes uma chave iPSK por residência para que todos os dispositivos se conectem uma única vez e permaneçam conectados durante todo o período do contrato.

O iPSK funcionará nos access points que eu já possuo?

Sim, se você utiliza um controlador atual de um grande fabricante. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet oferecem suporte para autenticação por chave sob seus próprios nomes de recursos. Verifique a documentação do seu fornecedor para saber o número máximo de chaves por SSID na versão do seu controlador. O Purple funciona como uma sobreposição de nuvem nesse hardware, portanto você não precisa substituir os access points para migrar os residentes para o iPSK.

O WiFi de convidados e o WiFi de residentes podem funcionar nos mesmos access points?

Sim. Execute-os como SSIDs separados nos mesmos access points, cada um mapeado para suas próprias VLANs. Os visitantes visualizam a rede de convidados com seu captive portal, e os residentes se conectam à rede iPSK com a chave da sua residência. Mantenha o número total de SSIDs baixo, pois cada SSID adicional gera tráfego de beacon que consome tempo de transmissão em cada access point que o transmite.

O que acontece com os dispositivos de um residente quando ele se muda?

Você revoga a chave dele e todos os dispositivos que a utilizavam perdem o acesso. Como cada residência possui sua própria frase secreta, uma única exclusão remove o telefone, laptop, TV e alto-falante simultaneamente, sem afetar nenhum outro residente. Vincule a revogação da chave à data de término do contrato de locação para que o acesso termine no mesmo dia em que o contrato expira, em vez de quando alguém se lembrar de alterar uma senha.

O iPSK é tão seguro quanto o 802.1X?

Não, mas é o controle adequado para dispositivos residenciais. O IEEE 802.1X fornece a cada pessoa uma credencial individual, o que é ideal para laptops corporativos de funcionários. A maioria das smart TVs e alto-falantes não consegue utilizá-lo, portanto ele falha em apartamentos. O iPSK fornece a cada residência uma chave exclusiva e a isola em sua própria VLAN, de modo que o vazamento de uma chave expõe apenas um apartamento, não o prédio inteiro. Use 802.1X para funcionários e iPSK para residentes.

Como o GDPR se aplica de forma diferente ao WiFi de residentes?

De acordo com o UK GDPR, a conexão de um residente é um serviço fornecido sob o contrato de locação, portanto a base legal provavelmente será a execução de contrato sob o Artigo 6(1)(b), e não o consentimento para fins de marketing. O WiFi de convidados normalmente coleta dados de marketing com opt-ins. Mantenha os dois separados: não execute captura de marketing na rede de residentes. O Purple é certificado ISO 27001 e em conformidade com o GDPR, processando os dados da rede de residentes com base nisso.

Quanto esforço exige uma migração de portal para iPSK?

Trata-se de uma alteração de configuração, não de um projeto de hardware. Você cria um SSID de iPSK no seu controlador existente, conecta-o a um serviço RADIUS como o cloud RADIUS da Purple e mapeia as chaves para as VLANs residenciais. A tarefa mais complexa é operacional: emitir chaves no momento da mudança e vincular a revogação às datas de término do contrato. Execute o portal e as redes iPSK lado a lado durante a transição para que nenhum residente perca o acesso.