Detecção do portal cativo, implementação popup?

4

Com base no hostapd, estou construindo um portal cativo.

  • Minha máquina Linux fornece acesso Wi-Fi.
  • Os clientes e tablets do iPad e do Android se conectam a esse Wi-Fi.

Geralmente, qualquer sistema operacional cliente verifica se uma URL está acessível; se não: o sistema operacional do cliente informa que é cativo e exibe uma janela do navegador pop-up. O pop-up é usado para login, apresentação ou outro.

Gostaria de exibir esse pop-up para apresentar o serviço da minha máquina, mas não entendi. Eu evitei a net forward embora. Todas as conexões são redirecionadas no site localhost da máquina.

Por que eu não recebo esse pop-up? Como conseguir isso? Como / onde devo implementá-lo no meu host local?

Idéias semelhantes:

Quando o popup acontece, como o seu conteúdo é definido? Por exemplo, um portal cativo de restaurante pede seu número secreto em sua anotação; onde esta página é armazenada? Como o sistema operacional sabe o URL a ser exibido no pop-up?

    
por ArchiT3K 29.06.2015 / 16:22

2 respostas

2

Para fazer um portal cativo aparecer, você precisa parar todo o tráfego da Internet e fornecer um 302 redirect ao navegador do cliente. Para fazer isso, você precisa ter um firewall (como iptables ) redirecionar todo o tráfego para um servidor da Web (como nginx , apache , etc) onde o servidor responde com 302 redirect à URL da sua página de login .

Escrevi um artigo longo no meu blog sobre como fazer isso com um Raspberry Pi. Basicamente se resume ao bloco / redirecionamento do iptables para o servidor web :

iptables -t nat -A wlan0_Unknown -p tcp --dport 80 -j DNAT --to-destination 192.168.24.1

e, em seguida, o servidor da web ( nginx ) redirecionando para a página de login:

# For iOS
if ($http_user_agent ~* (CaptiveNetworkSupport) ) {
    return 302 http://hotspot.localnet/hotspot.html;
}

# For others
location / {
    return 302 http://hotspot.localnet/;
}

O iOS tem que ser difícil, pois precisa das configurações do WISP. Os conteúdos hotspot.html são os seguintes:

<!--
<?xml version="1.0" encoding="UTF-8"?>
<WISPAccessGatewayParam xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.wballiance.net/wispr_2_0.xsd">
<Redirect>
<MessageType>100</MessageType>
<ResponseCode>0</ResponseCode>
<VersionHigh>2.0</VersionHigh>
<VersionLow>1.0</VersionLow>
<AccessProcedure>1.0</AccessProcedure>
<AccessLocation>Andrew Wippler is awesome</AccessLocation>
<LocationName>MyOpenAP</LocationName>
<LoginURL>http://hotspot.localnet/</LoginURL>
</Redirect>
</WISPAccessGatewayParam>
-->
    
por 16.08.2016 / 21:29
2

Para complementar a mensagem @AWippler. Implementei um portal cativo no FreeBSD e realizei alguns testes com dispositivos Windows, Mac, iOS e Android como clientes.

Esteja ciente de que, de acordo com meus testes, versões mais recentes do Android ao ter o Chrome instalado , faça o (s) teste (s) de detecção do portal cativo usando a porta 443 em vez da porta 80. Se você só intercepta a porta 80 a autenticação, você vai começar a coçar a cabeça pensando por que os clientes Android mais novos não estão funcionando.

(OK, notei que isso foi colidido na primeira página e a resposta é de 2016 ... o Android pode ter começado a fazer isso logo depois)

Além de interceptar a porta 80, você também precisa configurar um host SSL, interceptando a porta 443 e conviver com o erro de certificado SSL. Ou use um domínio DNS real válido na Internet como um todo com um certificado válido.

Para os visitantes que também tentam entender como implementar a Autenticação em Cativeiro, consulte também meu Q & A Portal cativo usando o Apache e as questões relacionadas Obtendo tags WISPr de um portal de autenticação FON ; também é útil para testar Desativando o CNA no MacOS

    
por 02.02.2018 / 11:28