Acho que decifrei, em parte, a charada.
Está documentado sim, mas de forma sutil, e sem maiores explicações
,na documentação oficial.
http://www.squidguard.org/config/#example05
src grownups {
ip 10.0.0.0/24 # range 10.0.0.0 - 10.0.0.255
}
src kids {
ip 10.0.0.0/22 # range 10.0.0.0 - 10.0.3.255
}
....
perceba que o range aumenta de cima pra baixo na ordem das acls.
Parece até o seu caso.
no src grownups temos um range que vai de 10.0.0.0 ate 10.0.0.255 e
na src abaixo, o range engloba todo o range da src de cima e mais um
pouco, de 10.0.0.0 até 10.0.3.255.
Isso realmente não está explicado explicitamente na documentação,
mas no fórum deles tem bastante coisa correlata. E imaginando o
mesmo esquema do squid, em que a primeira acl que for casada
automaticamente faz com que o squid ignore as próximas acls, o
squidguard deve seguir o mesmo modelo em relação as origens: a
primeira que casar automaticamente ignora as próximas. No squid isso
não é feito com as acls, mas sim com os http_access e similares, e
este é um cuidado que temos que ter ao definir a ordem de
quem-ou-o-que está liberado no squid.
você nunca veria este exemplo abaixo em nenhum site, referente a uma
configuração incorreta do squid:
acl subrede1 src 10.20.169.0/24
acl redetoda src 10.0.0.0/8
http_access allow redetoda
http_access deny subrede1
Justamente porque está errada no seu propósito, pois do modo como
está, irá liberar toda a sua rede, não importando a linha com
o "http_access deny subrede1", isso porque se o cliente estiver
usando o micro 10.20.169.12 ele estará na redetoda, e casará
primeiro uma regra que está liberando tudo.
Usando a mesma analogia, pelo visto o squidguard trata a ordem das
src's e não das acls, como é feito no squid.
Realmente nunca tinha parado para pensar neste aspecto do
squidguard, especialmente pq não uso varias redes ou várias
definições para diferentes redes, e somente uso a acl default com N
dsts.
Como esse tema me interessa também, fucei mais um pouco com olhos
mais criticos e descobri estas linhas abaixo, do faq-plus, de 2004,
e que falam sobre o squid não fornecer todos os bits de
endereçamento e ser preciso adicionar um parametro no squid.conf
para que ele o faça.
http://www.maynidea.com/squidguard/faq-plus.html#nosrcip
achei meio estranho, tanto por conter 'nunca trabalharemos com a
Berkeley 4.0' quanto por já terem se passado várias versões de
squid.
Com relação a colocar todas as maquinas em um grande txt, o site
desaconselha por questões de performance. Assim como ele tbm
desaconselha usar regex complexas. Agora, vai lá saber o que eles
entendem como complexas... rs
e só pra confirmar, lendo os sources do squidguard(estou fazendo
isso agora) é isso mesmo! ele faz tudo a partir do src:
Current changes in the upcomming release 1.2.0:
2001-06-01 The source block takes a new argument: continue.
With this command an ipaddress or user can be configured in serval
sourceblocks. If a client is found but not blocked, squidGuard
will continue to search in the next source block, if the continue
command is defined. Thanks to Valentin Chopov for the patch
testei e não deu erro, pelo menos. Lendo mais um pouco, achei algo
que outro dia alguém comentou comigo, de quotas de horario. Uma pena
que não funcionou aqui, o patch que a debian aplica automaticamente
retira essa característica, ou ela não funciona mesmo ou os patches
são incompativeis com isso... seria mto interessante pra mta gente,
ter N tempo de navegação por usuário ou por máquina ou por rede a
cada X horas/dias/semanas. Um único porém que eu li no forum é que
isso influenciava na performance do servidor. Mas tbm eles estavam
falando de 10.000 alunos... hehehe
até tentei compilar aplicando um mega-patche distribuido pela
http://linuxbox.com/tiki/tiki-index.php?page=squidGuard , mas cai no
mesmo dilema de quem compilou mas não fez bloqueio algum, deve ser a
tal do db4... ou o ldap. Ou ambos, ou eu mesmo.
Talvez se eu compilasse sem nenhum patch, usando a db3.x e me
sujeitando a alguns overflows e em um ambiente pequeno a médio (uma
lan house, ou um lab de 30 maquinas, por ex) eu conseguiria rodar
esse treco de quotauser tranquilamente.
[ ],s
Henry
--- Em [email protected], "Welington R. Braga"
<[EMAIL PROTECTED]> escreveu
>
> Fazendo mais alguns teste aqui, percebi uma coisa que não está
documentado
> (pelo menos não achei). A ordem dos "src" importa no casamento das
regras.
> Ex.:
> src administrador {
> ip 10.20.168.56
> }
> src minharede {
> ip 10.0.0.0/8
> }
>
> Se tiver uma acl para tratar cada caso desse e houver uma
requisição de
> 10.20.168.56 a ACL para "administrador" será acionada na boa. Mas
se a ordem
> dos "src" acima for invertida assim.
> Ex.:
> src minharede {
> ip 10.0.0.0/8
> }
> src administrador {
> ip 10.20.168.56
> }
>
> A ACL para "minharede" SEMPRE será acionada e nunca chegará a ACL
para
> adminsitrador. Independente da ordem das ACLs ao que parece o
importante é a
> ordem dos SRC.
>
> Alguém pode confirmar isso ?
Enviar mensagem: [email protected]
Assinar: [EMAIL PROTECTED]
Cancelar assinatura: [EMAIL PROTECTED]
Proprietário da lista: [EMAIL PROTECTED]
| Yahoo! Grupos, um serviço oferecido por: | |
|
Links do Yahoo! Grupos
- Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/squid-br/
- Para sair deste grupo, envie um e-mail para:
[EMAIL PROTECTED]
- O uso que você faz do Yahoo! Grupos está sujeito aos Termos do Serviço do Yahoo!.
