Soluções possíveis e eficazes com transparência para o usuário:
- SSL_BUMP: vai possibilitar filtrar o trafego https mesmo com o squid transparente. provavelmente vai te render uma dor de cabeça com erro de certificados em alguns sites
- WPAD: vai automatizar a configuração do proxy no cliente, fazendo com que o tráfego HTTPS seja direcionado para o proxy desde o cliente, sem necessidade de redirect no firewall
- GP: não manjo mto, mas acho que nesta situação tem função análoga a do WPAD, só que a configuração automática vai ser por regras de group policy vindas do AD. Somente para ambientes windows.
Usando squid e tendo transparência (transparente do ponto de vista do usuário, não da rede), acho que essas são as soluções que são eficazes. Em todas essas, o trafego vai passar pelo squid que vai realizar o bloqueio por url. Desconheço outra maneira de fazer esse bloqueio usando squid de maneira transparente para o usuário.2013/1/3 P. J. <pjotamail@gmail.com>Oi,
Concordo com o pessoal que é contrário a bloquear por ip, a range dele
muda muito...
Em 3 de janeiro de 2013 15:37, Leonardo Carneiro
<chesterman86@gmail.com> escreveu:
--> Mesmo com essa lista, te garanto que em pouco tempo teus usuários vão
> conseguir acessar de novo. Os IPs do fb (assim como de outros grandes
> portais) não é estática. Invariavelmente os FB começa a responder por outros
> IPs (isso não é publicamente divulgado) e lá vai vc correr atras de forum,
> mailing lists e coisas assim pra descobrir qual é o IP novo do FB.
| .''`. A fé não dá respostas. Só impede perguntas.
| : :' :
| `. `'`
| `- Je vois tout
Archive: http://lists.debian.org/CACnf0phTEpdrcXuVB3mM_fRm0FSOvÌ5TPUjRDBQK0XKLRw@mail.gmail.com
--
To UNSUBSCRIBE, email to debian-user-portuguese-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org