Por que o WiFi de convidados de estilo hoteleiro falha em edifícios residenciais

O WiFi para convidados do tipo hotelaria falha em edifícios residenciais porque assume uma estadia curta, um telemóvel e um browser. Um apartamento mobilado pode ter 10 ou mais dispositivos ligados, muitos sem browser para completar um Captive Portal, e os residentes esperam que a transmissão de conteúdo e os equipamentos de domótica funcionem. Em vez disso, atribua a cada habitação a sua própria chave iPSK e segmento de rede privado.

Como se caracteriza a falha do WiFi para convidados num edifício residencial?

A falha raramente se manifesta como uma rede sem sinal. Manifesta-se como uma sucessão de pequenas reclamações de residentes que pagam renda e não estão apenas de passagem.

Sintomas típicos num bloco destinado a arrendamento (BTR), residência de estudantes ou unidade de habitação multifamiliar (MDU):

• A smart TV, a coluna de som ou o termostato não se ligam. Estes dispositivos não têm browser, pelo que não conseguem completar um Captive Portal, a página de início de sessão web que uma rede de convidados apresenta antes de conceder acesso.
• A transmissão de conteúdo falha. O telemóvel de um residente não consegue encontrar o seu próprio Chromecast ou recetor AirPlay, ou encontra o do vizinho.
• Todos voltam a iniciar sessão todos os dias. A sessão do portal expira num temporizador de 24 horas, o que se adequa a um hóspede de hotel, mas irrita quem ali reside.
• Os dispositivos perdem a ligação após uma atualização de software. Os telemóveis que alternam o seu endereço de hardware parecem novos dispositivos, pelo que a rede se esquece deles.
• As saídas definitivas deixam acessos ativos. O portátil de um antigo residente ainda se liga semanas após o fim do contrato de arrendamento.

Se gere Hotels e está a expandir para apartamentos com serviços incluídos ou de estadia prolongada, irá deparar-se com estes sintomas primeiro nos pisos de estadia prolongada.

Porque é que o WiFi para convidados do tipo hotelaria não funciona para os residentes?

Quatro pressupostos de design subjacentes ao WiFi para convidados de hotéis deixam de ser válidos quando alguém se muda para o local.

O número de dispositivos é diferente

Uma rede de convidados de hotel é concebida para um telemóvel e um portátil durante uma ou duas noites. Pense, em contrapartida, nos dispositivos de um apartamento de um quarto: dois telemóveis, dois portáteis, uma smart TV, uma pen de streaming, uma coluna de som, uma campainha com vídeo, um termostato e uma impressora. Isto soma 10 antes de receber qualquer visita. Todos eles precisam de se ligar, e a maioria não tem um ecrã para introduzir dados.

Os dispositivos sem ecrã não conseguem utilizar um Captive Portal

Um Captive Portal funciona intercetando um pedido do browser e apresentando uma página de início de sessão. Uma coluna inteligente nunca abre um browser, pelo que nunca vê a página e nunca se autentica. A solução temporária habitual é o registo do endereço MAC, em que o residente introduz o endereço de hardware de cada dispositivo num formulário. Isso também falha.

A aleatorização de endereços MAC prejudica a memorização dos dispositivos

A Apple introduziu endereços privados por rede no iOS 14, e o Android 10 aleatoriza o endereço de hardware por predefinição. Um portal que memoriza os dispositivos pelo endereço MAC perde-os sempre que o endereço se altera. Os residentes voltam a autenticar-se e a sua linha de suporte técnico recebe a chamada.

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

As redes de convidados normalmente isolam os clientes para que estranhos não consigam aceder aos dispositivos uns dos outros. Isso está correto no lobby de um hotel. Mas o Chromecast e o AirPlay encontram recetores usando DNS multicast (mDNS, definido no RFC 6762), um protocolo de deteção que apenas funciona entre dispositivos no mesmo segmento de rede. Com o isolamento ativado, a transmissão falha. Se desativar o isolamento numa rede partilhada, todos os residentes poderão ver os dispositivos de todos os outros residentes.

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

O WiFi de hotel confia num dispositivo durante uma estadia e depois esquece-o. O WiFi para residentes tem de confiar nos dispositivos de um agregado familiar durante a vigência de um contrato de arrendamento, por vezes anos. Também tem de revogar essa confiança numa data específica. Um temporizador de sessão de portal não consegue expressar nenhuma destas regras.

Como identificar a causa do seu problema?

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

Sintoma relatado pelos residentes	Causa mais provável	Como confirmar
A Smart TV ou coluna inteligente não liga	Captive Portal num dispositivo sem ecrã (headless)	Verifique nos registos do seu controlador se o dispositivo chega a aceder à página do portal
O telemóvel não encontra o próprio Chromecast	Isolamento de clientes a bloquear o mDNS	Teste a transmissão com o isolamento desativado num único SSID de teste
O residente vê os dispositivos dos vizinhos ao transmitir	Rede partilhada plana com isolamento desativado	Procure anúncios mDNS a partir de um dispositivo de um residente
Inícios de sessão diários em todos os dispositivos	Limite de tempo de sessão do portal concebido para estadias curtas	Verifique o tempo limite de sessão no SSID de convidados
Dispositivos "esquecidos" após uma atualização do telemóvel	Randomização de MAC contra a memória baseada em MAC	Compare os endereços de hardware do dispositivo antes e depois da atualização
Antigos residentes continuam a ligar-se	Sem ligação entre o fim do arrendamento e o acesso à rede	Audite as credenciais ativas em relação aos registos de arrendamento atuais

Se as duas primeiras linhas descrevem o seu edifício, corrigir o tempo limite da sessão não irá ajudar. Precisa de um modelo de autenticação diferente, e não de um portal otimizado.

Qual o modelo de autenticação mais adequado para residentes?

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

Abordagem	Integração (Onboarding)	Dispositivos sem ecrã (headless)	Transmissão e casa inteligente	Revogar um único agregado familiar	Mais adequado para
Captive Portal (padrão de hotel)	Início de sessão no browser em cada dispositivo, repetido após o tempo limite	Falha sem registo manual de MAC	Bloqueado pelo isolamento de clientes	Aguardar que as sessões expirem	Convidados de hotéis, clientes, fãs, passageiros
Uma palavra-passe partilhada por edifício	Uma palavra-passe para todos	Ligação direta	Funciona, mas todos os residentes veem todos os dispositivos	Alterar a palavra-passe para todo o edifício	Nenhum edifício multi-inquilino
iPSK por agregado familiar	Uma palavra-passe única por apartamento	Ligação direta	Funciona apenas dentro do segmento do agregado familiar	Eliminar uma chave	BTR, residências de estudantes, MDU, estadias de longa duração

O iPSK (identity pre-shared key) executa uma única rede WPA2-Personal onde cada habitação tem a sua própria palavra-passe. Quando um dispositivo se liga, um servidor RADIUS, o serviço de autenticação que valida as credenciais, identifica qual foi a chave utilizada. A rede coloca-o então na VLAN dessa habitação, um segmento de rede virtual. Todos os dispositivos que um residente possui, com ou sem ecrã, ligam-se uma vez com uma palavra-passe que já compreendem.

O resultado é uma bolha de rede privada por apartamento. O telemóvel de um residente encontra o seu próprio Chromecast porque ambos estão no mesmo segmento. Não consegue ver o apartamento ao lado porque essa habitação possui uma chave diferente e está num segmento diferente.

O IEEE 802.1X é mais forte por pessoa, mas a maioria das smart TVs, colunas e termostatos não o conseguem utilizar. Guarde-o para as redes de funcionários.

Como resolver isto em hardware Cisco Meraki, HPE Aruba, Ruckus e outros?

Não precisa de novos pontos de acesso. Cada grande fabricante suporta a autenticação por chave sob o 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, uma vez que muitas implementações ainda funcionam em WPA2-Personal.

O Multi-Tenant WiFi da Purple funciona como uma sobreposição de nuvem no topo desse hardware, pelo que não há necessidade de substituir equipamentos. A Purple fornece o serviço RADIUS na nuvem que mapeia cada chave para a respetiva habitação. Gere as chaves de cada edifício a partir de um único painel centralizado. A Purple possui a certificação ISO 27001 e está em conformidade com o GDPR, e a plataforma funciona em mais de 80.000 locais ativos (dados da própria Purple).

Mantenha a sua rede de convidados para os visitantes. O Guest WiFi da Purple cria um registo de WiFi Visitors para cada visitante que se liga. Esse registo contém os locais visitados, a contagem de visitas e o método de ligação, de acordo com o artigo de suporte de WiFi Visitors da Purple. Isso é adequado para um átrio ou um café no rés-do-chão, não para a ligação residencial de um habitante.

Cenário prático: um hotel adiciona um piso para estadias prolongadas

Situação. Um hotel urbano de 180 quartos converteu um piso em 40 apartamentos de luxo para estadias de um a seis meses. Os hóspedes de estadias prolongadas utilizavam o SSID de convidados existente, com um Captive Portal, isolamento de clientes e um limite de tempo de sessão de 24 horas.

O que foi feito. O hotel manteve o SSID com portal para os quartos de estadia curta e para o lobby. Adicionou um SSID iPSK para o piso de estadia longa, com 40 chaves, cada uma mapeada para a sua própria VLAN. As chaves eram emitidas no check-in e eliminadas no check-out.

Resultado. Os logins por hóspede de estadia longa caíram de sete por semana para um à chegada. As Smart TVs e os dispositivos de transmissão ligaram-se à primeira tentativa porque já não encontravam um portal. No check-out, a eliminação de uma chave removia todos os dispositivos que aquele apartamento tinha ligado.

Cenário real: residências universitárias substituem o registo de MAC

Situação. Uma universidade pública geria uma residência de 600 camas com um captive portal. Os estudantes registavam consolas de jogos e colunas inteligentes introduzindo cada endereço MAC num formulário web. Os endereços aleatórios nos telemóveis implicavam novos registos todos os períodos letivos.

O que foi feito. O departamento de TI emitiu uma chave iPSK por quarto de estudo nos pontos de acesso existentes. Cada estudante recebeu a sua chave juntamente com a atribuição do quarto. As chaves foram associadas à data de término do contrato de alojamento.

Resultado. Os registos manuais de MAC caíram para zero, porque as consolas e as colunas agora ligam-se com uma palavra-passe. No final do ano académico, o departamento de TI revogou as 600 chaves de uma só vez, em vez de andar a gerir registos de dispositivos individuais.

Como evitar que volte a acontecer?

Desenhe a rede residencial em função do contrato de arrendamento, não da visita.

1. Separe as redes por público. Tenha um SSID de convidados 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 sinalização (beacon) e consome tempo de transmissão.
2. Associe chaves a entradas, mudanças e saídas. Emita uma chave na entrada, reatribua-a quando um residente mudar de fração e revogue-a na data de término do contrato de arrendamento. O Multi-Tenant WiFi da Purple gere este ciclo de vida de forma centralizada.
3. Planeie a capacidade por apartamento, não por pessoa. Dimensione cada fração para o número total de dispositivos, incluindo streaming nas horas de ponta da noite.
4. Mantenha os modelos de dados separados. O WiFi de convidados existe em parte para recolher dados primários com consentimento explícito. O WiFi de residentes é um serviço que presta ao abrigo do contrato de arrendamento, por isso não faça recolha de marketing no mesmo. Se quiser compreender como os espaços partilhados são utilizados, leia Presence analytics vs engagement analytics. Se 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 Retail no rés-do-chão, ou alojamento para funcionários num campus de Healthcare, necessita de um portal para o público e de iPSK para as pessoas que lá vivem.

Perguntas frequentes

Posso utilizar 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 as smart TVs, colunas e termóstatos não possuem um. Os portais também expiram sessões e esquecem dispositivos cujos endereços de hardware rodam. Mantenha um portal para visitantes e hóspedes de curta duração. Atribua aos residentes uma chave iPSK por agregado familiar, para que todos os dispositivos se liguem uma única vez e permaneçam ligados durante toda a duração do contrato de arrendamento.

O iPSK funcionará nos pontos de acesso que já possuo?

Sim, se utilizar um controlador atual de um grande fabricante. A Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet suportam autenticação por chave sob os seus próprios nomes de funcionalidades. Verifique a documentação do seu fabricante para saber o número máximo de chaves por SSID na versão do seu controlador. O Purple funciona como uma sobreposição em nuvem nesse hardware, pelo que não necessita de substituir pontos de acesso para migrar os residentes para o iPSK.

O WiFi de convidados e o WiFi de residentes podem funcionar nos mesmos pontos de acesso?

Sim. Execute-os como SSIDs separados nos mesmos pontos de acesso, cada um mapeado para as suas próprias VLANs. Os visitantes veem a rede de convidados com o respetivo captive portal, e os residentes ligam-se à rede iPSK com a chave do seu agregado familiar. Mantenha o número total de SSIDs baixo, pois cada SSID adicional adiciona tráfego de sinalização (beacon) que consome tempo de transmissão em todos os pontos de acesso que o transmitem.

O que acontece aos dispositivos de um residente quando este se muda?

Revoga a sua chave e todos os dispositivos que a utilizavam perdem o acesso. Como cada agregado familiar possui a sua própria frase de acesso, uma única eliminação remove o telemóvel, computador portátil, TV e colunas em simultâneo, sem afetar qualquer outro residente. Associe a revogação da chave à data de término do contrato de arrendamento para que o acesso termine no dia em que o contrato expira, em vez de quando alguém se lembrar de alterar uma palavra-passe.

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

Não, mas é o controlo adequado para dispositivos residenciais. O IEEE 802.1X atribui a cada pessoa uma credencial individual, o que é adequado para computadores portáteis de funcionários. A maioria das smart TVs e colunas não o conseguem utilizar, pelo que falha em apartamentos. O iPSK atribui a cada agregado familiar uma chave única e isola-o na sua própria VLAN, pelo que uma fuga de chave expõe apenas um apartamento e não o edifício inteiro. Utilize o 802.1X para funcionários e o iPSK para residentes.

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

Ao abrigo do UK GDPR, a ligação de um residente é um serviço que presta ao abrigo do contrato de arrendamento, pelo que a base legal será provavelmente a execução de um contrato nos termos do Artigo 6.º, n.º 1, alínea b), e não o consentimento de marketing. O WiFi de convidados recolhe normalmente dados de marketing com consentimentos explícitos. Mantenha os dois separados: não execute captura de marketing na rede de residentes. O Purple possui certificação ISO 27001 e conformidade com o GDPR, processando os dados da rede de residentes com base nesse princípio.

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

Trata-se de uma alteração de configuração, não de um projeto de hardware. Cria um SSID iPSK no seu controlador existente, liga-o a um serviço RADIUS como o cloud RADIUS da Purple e mapeia as chaves para as VLANs residenciais. A tarefa maior é operacional: emitir chaves no momento da mudança e associar a revogação às datas de fim do contrato de arrendamento. Execute o portal e as redes iPSK em paralelo durante a transição para que nenhum residente perca o acesso.