Ubuntu 10.04 - Dhcp + Iptables + Squid Transpatente (resolvido)

rafaelomago · 05 de Janeiro de 2012, 18:00

Citação de: zekkerj online 05 de Janeiro de 2012, 17:46
Quantas estações são?

40

zekkerj · 05 de Janeiro de 2012, 18:38

Muito poucas pra ser problema com a tabela NAT estourando. $:-\$
Também tem muito tempo que não vejo esse problema, acredito que já foi corrigido. Mas...

Execute os comandos abaixo na hora em que a rede para e cole o resultado aqui.

cat /proc/sys/net/netfilter/nf_conntrack_max
cat /proc/sys/net/netfilter/nf_conntrack_acct
cat /proc/sys/net/netfilter/nf_conntrack_buckets
cat /proc/sys/net/netfilter/nf_conntrack_count

modprobe -rv iptable_nat
modprobe -v iptable_nat

(depois repita os comandos "cat" acima, e teste a conexão nas estações)

rafaelomago · 05 de Janeiro de 2012, 19:27

também acho dificil, mas posto o resultado assim que puder.

Voce sabe dizer q sequencia das requisições dos clientes? Tipo: Cliente -> Firewall -> Squid -> Net -> Fiewall -> Squid -> Cliente ? É isso ?

zekkerj · 05 de Janeiro de 2012, 19:37

O firewall do servidor vai verificar todas as comunicações, assim, se vc pensar que o cliente fala com o squid, e o squid fala com a rede, vc vai ter algo mais como

Cliente -> Fwl -> Squid -> Fwl -> Net -> Fwl -> Squid -> Fwl -> Cliente.

rafaelomago · 07 de Janeiro de 2012, 15:30

ANTES
cat /proc/sys/net/netfilter/nf_conntrack_max
65536
cat /proc/sys/net/netfilter/nf_conntrack_acct
1
cat /proc/sys/net/netfilter/nf_conntrack_buckets
16384
cat /proc/sys/net/netfilter/nf_conntrack_count
473

modprobe -rv iptable_nat
FATAL: Module iptable_nat in use.
modprobe -v iptable_nat
-> nao retornou nada do sistema...

DEPOIS
cat /proc/sys/net/netfilter/nf_conntrack_max
65536
cat /proc/sys/net/netfilter/nf_conntrack_acct
1
cat /proc/sys/net/netfilter/nf_conntrack_buckets
16384
cat /proc/sys/net/netfilter/nf_conntrack_count
1368

modprobe -rv iptable_nat
FATAL: Module iptable_nat in use.
modprobe -v iptable_nat
-> nao retornou nada do sistema...

-----------------------------------------

Bom, depois reiniciei o servidor e deixei o PING ativo durante 15min no cliente e ele funcionou certinho.
Durante esse tempo ia no cliente e tentava acessar paginas proibidas: www.youtube.com | www.sexo.com.br
E o squid bloqueando...

Depois de 15min, abri uma nova aba no cliente e digitei www.vivaolinux.com.br... acessou certinho
Atualizei uma vez... carregou sem problemas
Atualizei outra vez ... e perdeu a conectividade...

youtube | sexo , nao bloqueia mais, pois nao acha nada...
e quando tento acessar a porta do squid pelo cliente 192.168.1.254:3128 o navegador retorna: Não é possivel uma conexao com o servidor...

Ou seja, o problema aparentemente está no momento que o squid está gravando o cache... ou na memoria ou no hd...

configuracao atual de meu squid,conf

Código Selecionar


http_port 3128 transparent
visible_hostname linuxs

debug_options ALL,1 33,2

cache_mem 256 MB
maximum_object_size_in_memory 128 KB
maximum_object_size 100 MB
minimum_object_size 2 KB
cache_dir ufs /var/spool/squid 4096 16 32
cache_swap_low 90
cache_swap_high 95
cache_access_log /var/log/squid/access.log
error_directory /usr/share/squid/errors/Portuguese/

refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern . 0 20% 4320

## ACL's ##

acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
#acl BADPORTS port 7 9 11 19 22 23 25 53 110 119 513 514 3128 8080
acl SSL_ports port 443 563 2083 1863
acl Safe_ports port 21 80 443 563 70 210 280 488 591 777 901 1025-65535
acl purge method PURGE
acl CONNECT method CONNECT

acl almoco time MTWTF 12:20-13:45
acl horaextra time MTWTF 18:00-23:45
acl palavrasproibidas url_regex -i "/etc/squid/block_palavras.txt"
acl palavrasproibidasDOM dstdom_regex "/etc/squid/block_palavras.txt"
acl downloads url_regex -i "/etc/squid/block_downloads.txt"

acl redelocal src 192.168.1.0/24
#Bia - Gisele - Gilberto - Ciro - Nara - Maria - Tereza - Francimilton - marcos - joana - rosa - joao - felipe
acl ips_gerencia src "/etc/squid/ip.diretoria"

## Regras ## .

http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
#http_access deny BADPORTS
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

http_access deny palavrasproibidas
http_access deny palavrasproibidasDOM

http_access allow ips_gerencia
http_access allow redelocal almoco
http_access allow redelocal horaextra

http_access deny downloads
#http_reply_access deny all downloads

http_access allow localhost
http_access allow redelocal
http_access deny all

df - h

Sist. Arq. Size Used Avail Use% Montado em
/dev/sda1 455G 3,5G 429G 1% /
tmpfs 997M 0 997M 0% /lib/init/rw
udev 992M 168K 992M 1% /dev
tmpfs 997M 0 997M 0% /dev/shm

free
total used free shared buffers cached
Mem: 2039844 451060 1588784 0 12264 259400
-/+ buffers/cache: 179396 1860448
Swap: 3983352 0 3983352

zekkerj · 07 de Janeiro de 2012, 16:08

Não é o squid, é o firewall. De alguma forma ele está travando depois de algum tempo em execução.

Se fosse o squid, vc o reiniciaria e ele voltaria ao normal.

rafaelomago · 07 de Janeiro de 2012, 20:39

Citação de: zekkerj online 07 de Janeiro de 2012, 16:08
Não é o squid, é o firewall. De alguma forma ele está travando depois de algum tempo em execução.

Se fosse o squid, vc o reiniciaria e ele voltaria ao normal.

E porque so nos clientes? O servidor continua funcionando sem problemas...

Ô mistério...

zekkerj · 07 de Janeiro de 2012, 23:02

O firewall do linux tem duas partes estanques, uma que lida com os pacotes que vão e vem pra própria máquina (cadeias INPUT e OUTPUT), e outra que lida com os pacotes que cruzam a máquina vindos de outras máquinas (cadeia FORWARD). Assim, é plenamente possível que o próprio servidor consiga se comunicar com o mundo, mas não consiga repassar pacotes.

Se bem que, no caso, como estamos usando um servidor proxy, tudo deveria estar passando pelas cadeias INPUT e OUTPUT, já que os clientes vão enviar tudo pro servidor, pra depois o servidor reenviar.

Uma coisa que eu queria confirmar novamente contigo é se vc está usando o proxy configurado nas estações, ou se está usando o proxy transparente. Pq no caso do proxy transparente, as estações precisam fazer suas próprias consultas DNS, e isso pode ser o ponto onde a falha está ocorrendo.

rafaelomago · 07 de Janeiro de 2012, 23:15

Citação de: zekkerj online 07 de Janeiro de 2012, 23:02
Uma coisa que eu queria confirmar novamente contigo é se vc está usando o proxy configurado nas estações, ou se está usando o proxy transparente. Pq no caso do proxy transparente, as estações precisam fazer suas próprias consultas DNS, e isso pode ser o ponto onde a falha está ocorrendo.

transparente.
Nos clientes naotem nada configurado.
E o servidor naoesta com bind.

zekkerj · 08 de Janeiro de 2012, 00:11

Então o próximo teste é configurar o proxy nas estações, se funcionar assim sabemos que o problema está nos mecanismos do proxy transparente.

rafaelomago · 08 de Janeiro de 2012, 10:34

Citação de: zekkerj online 08 de Janeiro de 2012, 00:11
Então o próximo teste é configurar o proxy nas estações, se funcionar assim sabemos que o problema está nos mecanismos do proxy transparente.

1 - Seria so colocar o proxy no navegador ?
2 - E retirar a linha de PREROUTING do iptables ?

abs.

zekkerj · 08 de Janeiro de 2012, 12:27

Basta colocar o proxy no navegador, pq a partir daí ele passa a comunicar diretamente com o proxy, em vez de tentar falar diretamente com os sites na porta 80.

rafaelomago · 08 de Janeiro de 2012, 13:55

Citação de: zekkerj online 08 de Janeiro de 2012, 12:27
Basta colocar o proxy no navegador, pq a partir daí ele passa a comunicar diretamente com o proxy, em vez de tentar falar diretamente com os sites na porta 80.

retirando o "transparent" da conf do squid ?

acho que tentei fazer algo assim no inicio e se nao me engano aconteceu a mesma coisa.
mas vou testar novamente.

zekkerj · 08 de Janeiro de 2012, 14:11

Não, não precisa mudar nenhuma configuração no squid ou no firewall. Apenas configure o proxy no navegador. Não precisa ser em todas as estações, basta uma. Se ela voltar a funcionar, sabemos que o problema está nos mecanismos do proxy transparente.

zekkerj · 08 de Janeiro de 2012, 14:13

Antes que eu esqueça, o proxy no navegador tem que ser configurado com o endereço do servidor proxy, e a porta em que o squid está funcionando. Esta costuma ser a porta 3128/tcp. Na dúvida, é a mesma porta indicada na regra de "PREROUTING" do seu firewall, aquela onde vc faz "-J REDIRECT --to-port xxxx".