Resolução do erro de ligação sem Internet no WiFi para visitantes

O erro de ligado sem internet no WiFi de convidados ocorre quando as verificações de conectividade falham antes de o Captive Portal carregar. Em locais com muito tráfego, as consultas DNS na porta UDP 53 (RFC 1035) esgotam o tempo limite durante a congestão. A resolução exige apontar os âmbitos DHCP de convidados para um filtro DNS com cache, concluir os domínios de walled garden nos controladores como o Cisco Meraki e rever as regras de moldagem de tráfego.

Qual é o aspeto de "ligado, sem internet" no WiFi de convidados?

O convidado vê as barras de sinal no máximo e uma rede à qual se associou, mas nada carrega. A página de início de sessão nunca aparece, pelo que não consegue aceitar os termos nem iniciar sessão. Em seguida, dirige-se à receção, ao ponto de ajuda ou ao balcão de atendimento.

Cada sistema operativo formula o aviso de forma diferente. A sua equipa de suporte do local deve reconhecer todos eles:

• O Windows mostra "Sem internet" por baixo do nome da rede.
• O Android mostra "Ligado sem internet" ou "A internet pode não estar disponível".
• O iPhone e iPad mostram "Sem Ligação à Internet" por baixo do nome da rede.

Os três resultam do mesmo mecanismo. Após a associação, o dispositivo solicita um endereço web conhecido para testar a ligação. Se esse teste retornar a página esperada, o dispositivo considera que a ligação está a funcionar. Se retornar uma página de início de sessão, o dispositivo abre o Captive Portal. Se não obtiver qualquer resposta, o dispositivo comunica "sem internet".

Antes de o dispositivo poder solicitar qualquer uma destas páginas, tem de consultar o hostname através de DNS. É nessa consulta que começa a maioria das falhas em ambientes de alta densidade.

O que causa habitualmente erros de ligado sem internet no WiFi de convidados?

Timeouts de DNS numa rede congestionada

O DNS (Domain Name System) converte um hostname num endereço IP. A maioria das consultas DNS viaja pela porta UDP 53, conforme definido na RFC 1035. O UDP não tem retransmissão incorporada, pelo que uma consulta perdida limita-se a aguardar pelo temporizador de nova tentativa do próprio dispositivo.

A congestão surge em picos. Pense no intervalo de um jogo num estádio, no check-out do pequeno-almoço num hotel ou num comboio a chegar à estação. Centenas de dispositivos associam-se em poucos segundos e cada um envia uma consulta ao mesmo tempo. Se o resolver estiver a vários saltos de distância através de uma ligação WAN ocupada, as consultas sofrem atrasos ou são descartadas. O dispositivo desiste, o portal nunca abre e o convidado vê "sem internet".

Os outros suspeitos habituais

O DNS é a causa mais comum em locais movimentados, mas não é a única. Exclua também estas hipóteses:

• Entradas em falta no walled garden. O walled garden é a lista de domínios que um dispositivo pode alcançar antes do início de sessão. Se o seu portal ou os seus recursos estiverem em falta, a página não consegue carregar.
• Esgotamento do conjunto de endereços DHCP. Se o conjunto de endereços se esgotar, os dispositivos atribuem a si próprios um endereço 169.254.x.x e não conseguem alcançar nada.
• Limites de taxa ou limitação de QoS na porta UDP 53. Um limite por cliente ou por SSID definido de forma muito restrita pode esgotar o DNS durante um pico de tráfego.
• DNS encriptado. O DNS sobre HTTPS (DoH, RFC 8484) e o DNS sobre TLS (DoT, RFC 7858) enviam consultas para resolvedores externos. Um walled garden que bloqueie esses resolvedores interrompe a consulta antes do início de sessão.
• Uma falha na ligação de montante (upstream). Se a própria ligação WAN estiver em baixo, todos os dispositivos falham e todas as portas com fios também falham.

Como identificar a causa do problema?

Comece pelo padrão e não pelo hardware. Utilize esta matriz para afunilar a causa antes de alterar qualquer configuração.

Três verificações que a sua equipa de suporte pode executar

1. Verificar o endereço IP do dispositivo. Um endereço 169.254.x.x indica um problema de DHCP, não de DNS. Um endereço normal no intervalo de convidados significa que o dispositivo se associou corretamente.
2. Cronometrar uma consulta a partir de um dispositivo de teste. Execute nslookup captive.apple.com num portátil ligado à rede de convidados. Uma resposta lenta ou uma falha durante um período de pico confirma um estrangulamento no DNS.
3. Capturar pacotes na VLAN de convidados. Uma VLAN (LAN virtual) separa o tráfego de convidados das suas outras redes. Filtre a captura por udp port 53 e procure consultas sem a respetiva resposta.

Depois, verifique quando ocorrem os erros. Em WiFi Analytics, compare os volumes de ligação e início de sessão com os horários em que os convidados reportam problemas. As falhas que acompanham as suas horas de maior movimento apontam claramente para congestionamento.

Como é que um filtro DNS empresarial resolve o estrangulamento?

Um filtro DNS empresarial é um resolvedor sob o seu controlo, posicionado perto da rede de convidados. Substitui o resolvedor público ou do ISP distante que o DHCP atribui atualmente. Desempenha três tarefas que eliminam o tempo limite de resposta.

Responde a partir da cache. Os nomes de anfitrião de verificação de conetividade são solicitados milhares de vezes por hora num local com muito movimento. Um filtro próximo responde a consultas repetidas a partir da sua cache, pelo que estas nunca chegam a atravessar a ligação WAN congestionada.

Elimina tráfego indesejado antecipadamente. As consultas para categorias maliciosas ou bloqueadas são recusadas logo no filtro. Isso liberta capacidade na WAN para as consultas que realmente importam.

Regista todas as consultas. Obtém um registo de quais domínios falharam, quando e com que frequência. Isto transforma suposições em provas da próxima vez que um responsável reportar um problema.

Onde o colocar

Para uma propriedade distribuída, como uma cadeia de comércio a retalho com centenas de instalações de pequena dimensão, um filtro fornecido na nuvem com localizações de limite próximas é geralmente a escolha mais prática. Para uma única instalação de grande dimensão, como um estádio ou um centro de conferências, um resolvedor alojado no local mantém as pesquisas completamente fora da WAN. Em ambos os casos, atribua dois endereços de resolvedor no DHCP para que uma única falha não inative a rede.

Duas definições que determinam o sucesso

Primeiro, permita os domínios do seu portal cativo no filtro. Um filtro que bloqueie ou atrase o portal recria exatamente o erro que se propôs resolver. Segundo, mantenha o DNS de convidados separado do DNS corporativo. O PCI DSS trata a segmentação de rede como a forma de manter uma rede de convidados fora do âmbito do seu ambiente de dados de titulares de cartões.

Como resolver o problema em cada fornecedor e sistema operativo?

Nos seus pontos de acesso e controlador

O Purple é agnóstico em relação ao hardware e executa-se como uma sobreposição na nuvem em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. A resolução segue os mesmos três passos em cada um deles:

1. Atualize os servidores DNS no âmbito DHCP de convidados para o seu filtro DNS empresarial.
2. Conclua o jardim murado. A Cisco Meraki, a HPE Aruba e a Ruckus utilizam todas o termo "walled garden" (jardim murado). Siga o artigo de configuração do Purple para o seu fornecedor, que lista os domínios exatos a permitir.
3. Verifique o controlo de tráfego de convidados para que os limites por cliente não estrangulem a porta UDP 53 durante um pico.

Não copie definições entre fornecedores. Os nomes dos menus e as predefinições diferem, pelo que deve utilizar a documentação do próprio fornecedor em conjunto com o artigo de configuração do Purple.

No dispositivo do convidado

Quando apenas um convidado é afetado e todos os outros estão a navegar sem problemas, a sua equipa de suporte pode tentar os seguintes passos:

• Esquecer a rede e voltar a ligar-se para acionar uma nova verificação de conetividade.
• Abrir um endereço http:// simples no navegador para forçar o aparecimento do portal.
• No Android, definir o DNS Privado para Automático. Um fornecedor de DNS Privado fixo pode bloquear a pesquisa antes do início de sessão.
• Pausar qualquer aplicação VPN até que o convidado tenha iniciado sessão.

Cenários práticos

Os valores abaixo são ilustrativos, não tendo sido retirados de uma implementação específica. Utilize-os como modelo para o que deve medir no seu próprio local.

Um hotel de 200 quartos à hora do pequeno-almoço

Situação. As reclamações na receção sobre "sem internet" concentram-se entre as 7h e as 9h, quando os hóspedes consultam o e-mail antes do check-out. Os pontos de acesso mostram um sinal saudável e tempo de transmissão livre. O DHCP de convidados atribui o resolvedor do ISP, com vários saltos através de uma linha congestionada.

O que foi feito. O gestor de TI executou o nslookup durante o pico de utilização e observou falhas diretas nas pesquisas. A equipa direcionou o DHCP de convidados para um filtro DNS na nuvem, adicionou os domínios do portal ao jardim murado e manteve o DNS de convidados separado da rede de gestão da propriedade.

Resultado. Medido no WiFi Analytics e no registo da receção, a conclusão do portal em picos subiu de 81% para 97%. As reclamações de WiFi na receção caíram de cerca de 15 por manhã para duas. Para saber mais sobre redes para hóspedes em hotéis, consulte as nossas páginas sobre hotelaria.

Um estádio com capacidade para 30.000 pessoas ao intervalo

Situação. Os adeptos reportavam "ligado sem internet" em todos os intervalos, enquanto os primeiros dez minutos de cada parte decorriam sem problemas. As capturas de pacotes na VLAN de convidados mostraram consultas de DNS sem resposta durante o pico de tráfego.

O que foi feito. O arquiteto de rede implementou um resolver local com suporte alternativo na nuvem. A equipa removeu um limite de débito por cliente que estrangulava a porta UDP 53 e moveu o escopo DHCP para o novo resolver.

Resultado. As consultas de DNS sem resposta ao intervalo caíram de 12% para menos de 1% nas capturas subsequentes. Os inícios de sessão dos adeptos durante o intervalo subiram 40% em relação ao jogo anterior.

Como evitar que os erros de ligado sem internet voltem a acontecer?

• Nunca confie apenas num resolver público distante. O DNS público tem geralmente um bom desempenho, mas um resolver a vários saltos de distância adiciona um atraso incontrolável durante um pico de tráfego.
• Crie alertas para consultas de DNS sem resposta. Configure o seu firewall ou switch principal para assinalar o aumento de perdas na porta UDP 53 na rede de convidados, o que sinaliza tempos limite esgotados antes que os convidados se apercebam.
• Reveja as listas de bloqueio do filtro de DNS todos os meses. Categorias demasiado agressivas afetam aplicações legítimas e geram novos pedidos de suporte.
• Defina um período de retenção de registos. Os registos de DNS associam endereços IP aos domínios visitados, pelo que deve tratá-los como dados pessoais ao abrigo do GDPR.
• Adote o RFC 8910 se o seu hardware o suportar. Este RFC permite que o DHCP informe o dispositivo sobre a localização do Captive Portal, fazendo com que o dispositivo dependa menos de uma verificação de conetividade.
• Considere o Passpoint para visitantes habituais. O Passpoint (também chamado Hotspot 2.0) e o OpenRoaming permitem que os dispositivos se liguem com segurança sem um Captive Portal, eliminando por completo esta falha.

A Purple opera Guest WiFi em mais de 80.000 espaços ativos em mais de 90 países, com 500 milhões de utilizadores e inícios de sessão por ano. Desde salas de espera na área da saúde a comboios, o padrão mantém-se: corrija o DNS antes de comprar mais largura de banda.

Perguntas frequentes

Precisamos de novos pontos de acesso para corrigir erros de ligado sem internet?

Não, na maioria dos casos não precisa. Quando o erro ocorre em horas de ponta, a causa é normalmente a resolução de DNS e não o hardware dos pontos de acesso. A solução é uma alteração de configuração: aponte o DHCP de convidados para um filtro de DNS empresarial próximo, complete o walled garden e reveja as regras de modelação de tráfego. Substitua o hardware apenas depois de as capturas de pacotes mostrarem que os próprios pontos de acesso estão a descartar tráfego em cargas normais e após ter descartado problemas de DHCP e DNS.

A Purple funciona com o hardware que já possuímos?

Sim, o Purple funciona nos pontos de acesso que já possui. O Purple é independente de hardware e é implementado como uma sobreposição na nuvem no Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Não há necessidade de substituir equipamentos. O Purple publica um artigo de configuração para cada fornecedor, listando os domínios de jardim murado de que o seu controlador precisa para que o portal cativo seja carregado antes de os visitantes iniciarem sessão.

Um filtro DNS empresarial tornará o nosso WiFi para visitantes mais lento?

Não, um filtro DNS bem posicionado torna geralmente as pesquisas mais rápidas. Este situa-se mais próximo da rede de visitantes do que um fornecedor de serviços de Internet (ISP) ou um resolvedor público e responde a pesquisas repetidas a partir da sua memória cache. O risco reside no posicionamento e na configuração, não na filtragem em si. Forneça dois endereços de resolvedor para redundância e autorize os domínios do seu portal cativo para que o filtro nunca atrase a página de início de sessão.

Por que não atribuir simplesmente aos visitantes um resolvedor público como o 8.8.8.8?

Pode fazê-lo, mas isso não resolve os tempos limite de congestão. Um resolvedor público continua a situar-se do outro lado da sua ligação WAN, pelo que cada pesquisa compete com o aumento de tráfego que causa a falha. Além disso, não oferece qualquer filtragem nem registos de consultas para resolução de problemas. Um filtro empresarial próximo responde a partir da memória cache, recusa categorias indesejadas e regista todas as pesquisas com falhas, algo que o DNS público não pode fazer por si.

Como gerimos os registos de consultas DNS ao abrigo do GDPR?

Trate os registos DNS como dados pessoais, pois estes associam endereços IP aos domínios que um dispositivo visitou. Defina um período de retenção especificado, limite o acesso à sua equipa de rede e segurança e registe a finalidade no seu aviso de privacidade. O Purple tem certificação ISO 27001 e cumpre o GDPR, devendo o seu fornecedor de filtro DNS demonstrar uma certificação equivalente antes de encaminhar o tráfego de visitantes através do mesmo.

Quanto esforço exige a implementação?

A alteração em si é reduzida; o teste consome a maior parte do esforço. Atualize os servidores DNS no escopo DHCP de visitantes, adicione os domínios do portal à lista de permissões do filtro e verifique o jardim murado. Planeie testar durante um pico real, como a hora de ponta do pequeno-almoço ou o intervalo de um jogo, pois uma tarde calma não reproduzirá a congestão que causou o erro.

O Passpoint ou o OpenRoaming eliminarão o erro?

Sim, para os dispositivos que os utilizam. O Passpoint e o OpenRoaming permitem que os dispositivos se liguem com segurança sem um portal cativo, pelo que não há portal suscetível de falhar. Os visitantes que acedem pela primeira vez e os dispositivos sem um perfil Passpoint continuam a utilizar o portal cativo, pelo que continuará a precisar de um DNS rápido e de um jardim murado completo. Execute ambos em conjunto: Passpoint para visitantes recorrentes, um portal otimizado para todos os outros.