No Cisco 5508 v7.2.103.0, tenho duas WLANs configuradas. Chame-os de ABC e XYZ para o bem desta pergunta. O ABC usa 802.1X e obtém um URL de redirecionamento de página inicial pressionado. O XYZ usa PSK e usa a configuração externa do WebAuth para enviar por push um URL de redirecionamento da página de login. As páginas de abertura e de login são veiculadas na mesma URL base (servidor da Web externo), como http://webauth.example.com/splash.html e /login.html.
WLAN ABC - Splash-Page-Web-Redirect[WPA + WPA2][Auth(802.1X + CCKM)]
WLAN XYZ - Web-Passthrough[WPA2][Auth(PSK)]
Vejo o que parece ser um comportamento inconsistente quando os URLs de redirecionamento são exibidos nos dispositivos, o estado webauth / NAC RUN e a capacidade de realmente obter acesso à Internet (ou não quando necessário).
Entendo que a página de login exige aceitação (não é necessário nome de usuário) antes de permitir a passagem do tráfego e o WLC apenas pensa que a página inicial foi vista pelo dispositivo (aceitação não necessária) para que o tráfego flua aqui.
Eu já vi praticamente todas as condições possíveis , mas os casos em que os fluxos de tráfego nem sempre fazem sentido.
- O redirecionamento de página inicial ou de splash ocorre ao navegar para um URL de texto simples não seguro; webauth mostra Autenticado com estado NAC RUN, fluxos de tráfego. É o que se espera que aconteça, mas não acontece com frequência.
- O redirecionamento de página inicial ou de splash não ocorre ao navegar para um URL de texto sem formatação não seguro; O webauth mostra autenticado com o estado NAC RUN, fluxos de tráfego (mas não deve após a remoção do cliente do WLC para forçar o redirecionamento do webauth que não foi exibido).
- O redirecionamento de página inicial ou de respingo não ocorre ao navegar para um URL de texto simples não seguro; webauth não autenticado com o estado WEBAUTH do NAC, fluxos de tráfego (mas não deveria).
- O redirecionamento de página inicial ou de splash ocorre ao navegar para um URL de texto simples não seguro; webauth mostra Não autenticado com o estado WEBAUTH do NAC, o tráfego não flui (mas deveria se WEBAUTH foi mostrado como aprovado).
- O redirecionamento de página inicial ou de respingo não ocorre ao navegar para um URL de texto simples não seguro; webauth não autenticado com o estado WEBAUTH do NAC, o tráfego não flui (conforme o esperado).
Em todos os casos, os detalhes do cliente mostram que o URL de redirecionamento foi definido.
Nos dois casos em que tudo funcionou como esperado com o redirecionamento, estado de webauth / run e fluxo de tráfego (sendo permitido ou negado), não acho que as ACLs sejam o problema. Nada mais está sendo enviado do ACS para além do URL de redirecionamento. As duas WLANs são codificadas para diferentes VLANs.
Poderia ser um comportamento aleatório ou meus olhos estão apenas brincando comigo? Vi comportamentos ligeiramente diferentes com dispositivos diferentes - alguns mais aleatórios, outros menos.
Qual é a melhor abordagem para diminuir esse problema?
Atualização : o DNS não é o problema. A acessibilidade geral do IP funciona aleatoriamente no navegador. Independentemente do estado do webauth (RUN x WEBAUTH-REQD), algumas vezes o navegador é acessado e outras não. (As solicitações iniciais são sempre HTTP em texto sem formatação.) Vi até mesmo o tráfego regular passar por aplicativos que não são da Web, como SMTP, então estou realmente pensando que o Webauth está mexendo com isso, mas não vejo nada obviamente errado . Eu tenho uma ACL pré - legal que é bastante liberal e uma ACL para convidados . Eu até adicionei permissão any / any para ambas as ACLs que não fizeram a diferença.
Respostas:
Já vi problemas semelhantes duas vezes no passado.
A primeira vez, teve a ver com resolução de DNS. Eu realizei uma pesquisa de DNS em um cliente que estava com problemas e percebi que o cliente não era capaz de resolver o URL que eu estava passando para a página de login. Isso ocorreu porque eu estava passando um servidor DNS externo. Verifique isso primeiro. Eu resolvi isso passando o IP na URL, embora você pudesse criar um cname que resolva para 1.1.1.1.
Na segunda vez, foi um problema de certificado. Alguns navegadores padrão não mostrarão a tela inicial se o usuário precisar aceitar um certificado autoassinado. Eu testaria isso navegando manualmente na tela inicial ou na página de login de um cliente que não a mostra automaticamente.
Espero que um desses ajude você. Eu sei que estava pronto para arrancar meus cabelos quando vi isso pela primeira vez.
fonte