Respostas no Fórum
-
Posts
-
Não cheguei a testar isso, pois não deu tempo, devido as reclamações. Se funcionar, será uma boa alternativa para contornar o problema…
Mas amanha vou realizar uns testes fora do horário de expediente. Em seguida eu posto os resultados.
Wireguard_webadmin
Sistema gratuito (Open Source) para gestão de VPN's WireGuard com uma Web interface intuitiva e fácil de usar.
Principais funcionalidades:
- Sistema de Firewall completo e flexível.
- Encaminhamento de portas
- Suporte a multi usuário com níveis diferentes de acesso
- Múltiplas instâncias do Wireguard
- Crypto key routing para configuração de VPN site-to-site
O projeto é Open Source, fácil de instalar e está disponível em wireguard_webadmin
Prezado Neobyte,
Estamos colocando todos os desktops no domínio, mas ainda faltam muitos.
Todas as regras do webfilter foram criadas, com autenticação por grupos. Os usuários já estão cadastrados em seus devidos grupos de acesso.O maior problema é que teremos alguns visitantes, funcionários e gerentes, que utilizam a nossa rede. Mas o uso não é continuo, pois muitas vezes eles vão na empresa apenas para reuniões. Assim fica inviável ficar pegando IP ou MAC de todos que visitarem a empresa, e adicionar a regra de liberados…
Eu testei apenas habilitando o proxy transparente… Quando for proxy não transparente, sei que terei muitos problemas…
Vou verificar em detalhes, a regra que libera os “não autenticados”.
Se mais alguem tiver alguma dica, será bem vinda !
Obrigado!O Endian lê as regras de cima para baixo, ou seja, sequencialmente.
Confira esta dica:
Politica 1 = Bloqueia o sitexx.com.br
Politica 2 = Libera o sitexx.com.brO que prevalecerá é a primeira regra.
Verifique se não á conflito entre suas politicas.Me corrijam se eu estiver equivocado:
Que eu saiba, proxy não transparente funciona perfeitamente quando configuramos o endereço do proxy no browser do cliente…Para que o Endian não bloqueie os endereços internos, quando configurar o proxy nos browsers, clique em “Não usar servidor proxy para endereços locais”. Depois clique em avançado, e digite o IP da sua rede no campo: Não usar servidor proxy para endereços iniciados por:
Prezado Diego,
Em diversos testes que realizei, eu não consegui simular o erro igual ao seu.
Como você diz que refez todas as politicas, você poderia ter experimentando, criar apenas uma politica (diretoria), e fazer um teste de navegação. Se a navegação ficar do jeito que você espera, vá criando as demais categorias, e sempre testando a navegação do grupo diretoria. Assim você consegui ver qual categoria poderá apresentar conflito com a diretoria, impedindo a navegação.Eu sei que as regras de firewall funcionam assim mesmo. As regras são lidas de cima para baixo. O que prevalesse é a primeira regra lida.
Sobre o webfilter eu não posso afirmar se funciona assim. Mas acredito que seja a mesma forma de leitura das regras.Vamos ver se alguém aqui do fórum pode confirmar isso.
Muito estranho,
Eu não consegui simular este erro aqui. Criei outros grupos Access Police e Webfilter, com acesso full, mas todos navegam conforme eu configuro.
Realizei o teste no meu ambiente de produção, e tambem em uma VM.Vc ja fez o teste abaixo:
No AD, coloque o seu usuário no grupo da diretoria, remova os demais grupos. Defina o grupo diretoria como grupo primário.
Aguarde alguns minutos e faça um teste na navegação.Algo me chamou a atenção na tela que vc me enviou.
No AD, existe um grupo chamado diretoria ?Pois em “Grupos permitidos” não aparece o grupo diretoria.
Em “Filtro de perfil”, deveria estar selecionado o perfil: chequenobre-diretoria
Pois este perfil tem acesso liberado no webfilter.vamos fazer o primeiro teste.
em Access Police, utilizando as setas, posicione a regra da diretoria, para a primeira posição.
faça um teste de navegação.Diego,
É possível enviar 2 printscreen para analisarmos ?1 – Menu Proxy, Access Police, e tire um printscreen.
2 – Dentro de Access Police, clique em editar a police, e tire um printscreen.
