Como as conexões de rede do portal cativo funcionam?

O acesso à Internet em hotéis, cafés de aeroportos geralmente é bloqueado por um portal cativo que o força a acessar uma página da Web específica pela primeira vez, por exemplo, uma página de pagamento ou alguma página para aceitar termos de serviço ou uma página de autenticação / autorização. Você vê isso nas conexões sem fio e com fio.

Como é que isso funciona?

Certamente varia de acordo com o fornecedor do produto sem fio, mas na minha experiência, geralmente funciona algo como isto:

1. O laptop faz uma conexão sem fio a um ponto de acesso inteligente, que pode ser conectado a uma estação de gerenciamento centralizada.
2. Sua primeira solicitação da Web é interceptada e respondida com um Location:cabeçalho que o redireciona para uma página de login / política (por exemplo, http://hotelwireless.net/login ). Isso pode estar diretamente no ponto de acesso inteligente ou em uma estação de gerenciamento central.
3. Depois de concluir a autenticação, seu endereço MAC é adicionado a uma lista de clientes permitidos, fazendo com que futuras solicitações sejam roteadas corretamente para a Internet ou para recursos acessíveis da Intranet.

Com relação ao que chamá-lo, ouvi-o ser chamado de "portal cativo" ou "portal de acesso sem fio" com mais frequência.

Primeiro para obter o redirecionamento, você precisa de um autenticador em linha (controlador de acesso). No contexto do seu tópico, você precisará de um controlador LAN sem fio se optar pelo gerenciamento central do ponto de acesso. OU você também pode colocar um tipo de portal cativo de controlador de acesso à rede com os recursos do Wall Garden.

O NAS monitora o tráfego que entra no downlink (lado do cliente) através do soquete bruto do modo promíscuo e quando o tráfego iniciado pelo navegador para um cliente não autenticado é detectado, um redirecionamento HTTP é fornecido como resposta. Portanto, o navegador ao receber é redirecionado para a página inicial do portal CAPTIVE, que pode ser hospedada on-line no autenticador ou pronta para usar em algum servidor externo.

O único trabalho desta página é fornecer ao usuário uma interface do usuário para inserir credenciais. as credenciais inseridas são encaminhadas de volta para o autenticador Daemon, como chilli, no caso de coova chilli. Além disso, essas credenciais são passadas como solicitação de raio para o servidor RADIUS ou podem ser verificadas localmente. Após a autenticação bem-sucedida, o estado do cliente no autenticador é marcado como autorizado e o cliente recebe acesso.

Como o redirecionamento é alcançado

A abordagem mais usada é interceptar a solicitação HTTP iniciada pelo usuário e o código 302 como resposta ao cliente. Nos pimentões, isso é feito através da função abaixo

http_redirect2() {

cat < <  EOF
HTTP/1.1 302 Redirect 

Location: $1

Set-Cookie: PORTAL_SESSIONID=$PORTAL_SESSIONID

Set-Cookie: COOVA_USERURL=$COOVA_USERURL

Connection: close

EOF
    exit

}

Esse redirecionamento pode ser facilmente alcançado através da interface tun tap controlada de forma pragmática para a interface do lado do cliente, que intercepta o tráfego do cliente. Também é possível obter um redirecionamento adicional via envenenamento de DNS, mas às vezes pode causar problemas se as respostas forem armazenadas em cache no navegador do cliente. Outras coisas podem ser feitas mais especificamente, de acordo com o domínio do problema. Eu posso ajudá-lo com isso, se você quiser.

Há uma excelente descrição disso em https://www.arubanetworks.com/vrd/GuestAccessAppNote/wwhelp/wwhimpl/js/html/wwhelp.htm .

Aqui está parte disso:

Processo de autenticação do portal cativo

O portal cativo é uma autenticação da camada 3, que exige que os dispositivos se conectem à rede e obtenham um endereço IP e informações DNS relacionadas antes de autenticar através do portal cativo. As etapas a seguir explicam todo o processo do portal cativo quando o ArubaOS nativo é usado para autenticação do portal cativo:

1. O dispositivo associado ao SSID convidado recebe uma função inicial (função de logon do convidado na configuração de exemplo). Essa função inicial permite DHCP, para que o usuário obtenha um endereço IP.

2. O usuário abre um navegador e faz uma solicitação HTTP (ou HTTPS) para algum destino (por exemplo, www.bbc.com).

3. O resolvedor no dispositivo envia uma solicitação de DNS para resolver o www.bbc.com. A função inicial (função de logon de convidado) permite serviços DNS, para que o resolvedor possa se comunicar com o servidor DNS.

4. O servidor DNS responde com o endereço correto para www.bbc.com.

5. O resolvedor informa ao navegador qual endereço IP usar com base na resposta do DNS.

6. O navegador inicia uma conexão TCP com a porta 80 do endereço www.bbc.com.

7. O controlador intercepta a conexão e falsifica os handshakes TCP iniciais do processo HTTP. Neste momento, o navegador do cliente pensa que está se comunicando com o servidor bbc.com.

8. Quando o navegador envia a solicitação HTTP GET para a página da web, o controlador responde dizendo que o bbc.com foi “temporariamente movido” para.

9. O navegador fecha a conexão.

10. O navegador tenta se conectar, mas primeiro precisa enviar uma solicitação de DNS para o endereço.

11. O servidor DNS real responde que não pode resolver https://securelogin.arubanetworks.com , mas o controlador intercepta essa resposta e altera o pacote para dizer que securelogin.arubanetworks.com está no endereço IP do próprio controlador. Lembre-se de que é essencial que o servidor DNS retorne uma resposta à consulta. É só então que o controlador pode falsificar a resposta de volta do servidor DNS. Enviar uma solicitação DNS sem receber uma resposta não é suficiente, pois, sem uma resposta, o controlador nunca ajudará o cliente a resolver o securelogin.arubanetworks.com.

12. O navegador inicia uma conexão HTTPS com o endereço do controlador, que responde com a página de login do portal cativo, onde o convidado se autentica.

13. Após a autenticação bem-sucedida, o usuário recebe a função de pós-autenticação (função de convidado-autenticação na configuração de exemplo). Essa é a função padrão no perfil do portal cativo.

14. Após a autenticação, o navegador é redirecionado para bbc.com no endereço originalmente resolvido pelo DNS. Como alternativa, se uma página de boas-vindas estiver configurada, o navegador será redirecionado para a página de boas-vindas.

15. Para redirecionar com êxito para a página da Web original, o controlador falsifica uma resposta do bbc.com para informar ao cliente que o bbc.com "mudou permanentemente" para o bbc.com. Esta etapa corrige a "realocação temporária" que ocorreu como parte do logon do portal cativo.

16. Isso faz com que o cliente solicite novamente ao DNS o endereço de www.bbc.com.

17. O navegador começa a se comunicar com o servidor bbc.com real.