Como Corrigir Redirecionamento de Captive Portal no Apache e Linux

Configurar um captive portal exige precisão na camada de rede e no servidor web. Quando um usuário se conecta a uma rede Wi-Fi pública ou corporativa, espera-se que qualquer tentativa de navegação HTTP seja interceptada e redirecionada para a página de autenticação correta. No entanto, inconsistências entre domínios (como redirecionamentos errôneos de um TLD .com para .net), regras de DNS imprecisas ou falhas no Apache podem quebrar completamente o fluxo de login, gerando loops de requisição e erros de SSL.

O que causa falhas de redirecionamento em Captive Portals?

O funcionamento de um portal de autenticação envolve a interceptação do tráfego através de tabelas do firewall (como iptables ou nftables) e a resolução controlada de DNS (walled garden). Os problemas mais comuns surgem em três pontos críticos:

1. VirtualHosts e ServerName no Apache: Se o servidor Apache estiver configurado para responder por portal.exemplo.com mas os scripts PHP ou o DNS local apontarem para portal.exemplo.net, o servidor pode rejeitar a requisição ou disparar cabeçalhos de redirecionamento incorretos (301 Moved Permanently ou 302 Found).
2. Regras de mod_rewrite: Diretivas de reescrita mal estruturadas no .htaccess ou no arquivo de configuração do site podem forçar a troca de protocolo ou domínio de forma inadequada.
3. Interceptação de DNS (DNS Hijacking): Se o daemon de DNS (como dnsmasq ou BIND) não responder com o IP correto do portal para todas as consultas de domínios externos não autorizados, o cliente tentará carregar páginas externas que falharão no handshake.

Boas práticas de configuração no Linux e Apache

Para garantir que o fluxo de autenticação funcione de maneira transparente:

• Padronização de URLs no VirtualHost: Defina explicitamente o ServerName e ServerAlias correspondentes ao domínio de autenticação ativo. Evite misturar domínios de desenvolvimento (.local, .net) com domínios finais de produção sem sincronizar os arquivos de configuração.
• Reescrita condicional e segura: Ao capturar requisições no Apache, use regras limpas para preservar a URL de destino original (geralmente enviada como parâmetro de retorno para o PHP):

apache
RewriteEngine On
RewriteCond %{HTTPHOST} !^portal.exemplo.net$ [NC] RewriteRule ^(.*)$ http://portal.exemplo.net/login.php?origem=%{HTTPHOST}%{REQUEST_URI} [L,R=302]

• Validação no backend PHP: Em sistemas que desenvolvo, estruturo a aplicação para validar a origem da requisição e emitir cabeçalhos estritos de controle de cache (Cache-Control: no-store, no-cache), evitando que dispositivos móveis memorizem rotas de redirecionamento desatualizadas.

Passo a passo para diagnosticar e corrigir o problema

1. Verificação de DNS e Walled Garden: Teste a resolução de nomes no ambiente cliente para garantir que todas as requisições não autenticadas apontem para o IP local do servidor.
2. Inspeção de Headers HTTP: Execute curl -I http://dominio-teste.com a partir de um cliente conectado para verificar o código de status retornado e o cabeçalho Location enviado pelo Apache.
3. Auditoria de configurações do Apache: Localize diretivas Redirect, RewriteRule e ServerName em /etc/apache2/sites-enabled/ que contenham referências ao domínio antigo (.com) e atualize-as para o domínio correto (.net).
4. Limpeza e teste de sessão PHP: Garanta que variáveis globais ou arquivos de configuração do PHP não possuam URLs estáticas antigas gravadas para redirecionamento pós-autenticação.

Se a sua infraestrutura de rede ou captive portal está enfrentando problemas de redirecionamento, timeouts ou instabilidade em servidores Linux e Apache, entre em contato para uma consultoria técnica especializada e restabeleça o funcionamento correto da sua rede.