[Resolvido] Captive Portal com FreeRadius Autenticando em Openldap
-
Certo.
Isso já ocorre.
Tenho a seguinte regra no Custom Settings do squid
acl SITES_NO_PROXY url_regex "/var/db/squidGuard/SITES_NO_PROXY/domains";
http_access allow SITES_NO_PROXY;redirect_children 3 redirect_program /usr/local/bin/squidGuard -c /usr/local/etc/squidGuard/squidGuard.conf;
redirect_program /usr/local/bin/squidGuard -c /usr/local/etc/squidGuard/squidGuard.conf;redirector_bypassNeste arquivo domains tenho o IP 192.168.1.32 para não passar pelo proxy.
Ate na lan eu digitar o ip 192.168.1.32/sief no navegador o mesmo não pede autenticação. -
Gilmar,
Mas de qualquer forma você esta enviando a requisição para o squid.
Falo de alterar o wpad ou a gpo para não enviar trafego interno para o proxy.
Entende a diferença?
-
Eu coloquei no firefox sem proxy para sief.agrovale.com.br e 192.168.1.32 e ocorre o mesmo problema.
Penso que seria a mesma coisa que colocar no wpad. -
Se o IP cadastrado esta na mesma faixa de rede da estação de trabalho, o acesso não deveria passar pelo proxy.
Tentou fechar e abrir o browser depois da alteração da configuração? Faça o teste sem o wpad.
-
No caso a rede da estação é 10.9.9.0/24 esta rede acessa a rede 192.168.1.0/24 que é onde esta o servidor 192.168.1.32.
-
Alguma chance do proxy estar com modo transparente habilitado?
-
Bom dia.
Estou com o Proxy Setado no navegador e o mesmo esta autenticando em base openldap. -
Bom dia.
Pelo meus testes o problema ocorre porque o squidGuard não esta conseguindo liberar conexão vinda de uma outra lan no meu caso 10.9.9.0.
Minha lan é 192.168.1.0 e o squidguard aceita perfeitamente.
Já quando o trafego vem da rede 10.9.9.0 que e direcionado para o proxy ai o squidguard não esta conseguindo tratar nas acl e cai no grupo não defenido. -
Aparece algo no log do squid(access e cache.log)?
Conferiu se esta outra faixa está cadastrada no squid como ips autorizados?
-
Pelo que descobri e algo relacionado do captive portal direcionando a URL para o squid que após o dominio o mesmo esta retirando a /.
Fiz um teste liberando o endereço.
http://www.linkteck.com.br/site/produtosAi ele direcionou para uma url como inexistente pois na barra de endereço ficou da seguinte forma.
http://www.linkteck.com.brsite/produtos -
Boa tarde.
Realmente o problema era a falta da barra.
No script index.php do captive portal localizado em /usr/local/captiveportal estava sem a barra entra a variavel orig_host e orig_request.
Estaquei em negrito a alteração do arquivo captive portal.if (isset($config['captiveportal']['httpslogin']))
header("Location: https://{$ourhostname}/index.php?redirurl=" . urlencode("http://{$orig_host}/{$orig_request}"));
else
header("Location: http://{$ourhostname}/index.php?redirurl=" . urlencode("http://{$orig_host}/{$orig_request}")); -
Gilmar,
Esta atualização resolveu somente o erro do display ou resolveu o problema de acesso?
EDIT
Este erro já foi corrigido no código da 2.0.3 pelo ermal no dia 03/01 :)
att,
Marcello Coutinho -
Bom dia.
Eu já tinha resolvido o problema de acesso.
O problema que estava tendo era porque o as url como sief.agrovale.com.br/sief caia no squidGuard como negado.
E lembrando que já tinha regra no squidguard liberando esta url.
Ai notei que isso ocorreia com todas urls que tinha a barra.
Esta versão 2.0.3 que você informou que corrigiu este problema já saiu?
Pois meu pfsense esta na versão 2.0.2 e no status de versão ele informa que estou com a versão mais nova. -
Esta versão 2.0.3 que você informou que corrigiu este problema já saiu?
Ainda não. Está na pre-release. Alguns bugs foram corrigidos mas o core team ainda esta esperando alguns feedbacks sobre o captive portal para finalizar a versão.
-
Ahh tá.
Só encontrei este bug por enquanto relacionado ao captive portal.
Mas muito obrigado pela sua ajuda.
