Squid com problema, caindo direto

[SebaCueto]

Boa tarde pessoal!
Meu problema é o seguinte aqui na empresa: A Internet cai direto, todo santo dia. O estranho é que cai so para algumas pessoas, por um tempo indeterminado, segundos, às vezes meia hora. Parece como que tem um limite de usuarios que podem estar conectados ao mesmo tempo, sei lá.
Às vezes, escolhendo "reparar", lá nos micrinhos do lado do relógio resolve, ou trocando o IP, e quando cai o proxy, cai tb os e-mails (outlook no caso), e não consigo pingar nada tb. Reiniciar o Squid tb nao soluciona, reiniciar o meu micro sim.

Faz perto de um mês que to com esse problema, já mudei o squid.conf um milhão de vezes, e sempre acaba igual, calculo que o problema não é o squid.

Outra coisa, se faço uma conexão direta do meu micro para fora (a gente tem 2 IP´s fixos), navego sem problema.

Tó usando Squid 2.6 STABLE5, num Debian 40r3

Vou postar aí me squid.conf e o cache.log

SQUID.CONF:
http_port 3128
visible_hostname smb
cache_mem 128 MB
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
maximum_object_size_in_memory 64 KB
maximum_object_size 12288 KB
minimum_object_size 0 KB
cache_swap_low 90
cache_swap_high 95
cache_dir ufs /proxy/cache 2048 16 256
cache_access_log /proxy/log/access.log
cache_log /proxy/log/cache.log
cache_store_log /proxy/log/store.log
cache_effective_user proxy
cache_effective_group proxy
refresh_pattern ^ftp: 60 20% 2280
refresh_pattern ^gopher: 60 0% 2280
refresh_pattern . 0 20% 2280
emulate_httpd_log off

#-------------AUTENTICACAO-----------------
auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squid.passwd
auth_param basic children 5
auth_param basic realm Digite seu usuario e senha
auth_param basic casesensitive on

#------------ACL's-------------------------
acl ncsa_users proxy_auth REQUIRED
acl bloqueados url_regex '/samba/administrativo/Servidor/Bloqueados/Bloqueados.txt'
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 SSL_ports port 443 563
acl Safe_ports port 80 #http
acl Safe_ports port 21 #ftp
acl Safe_ports port 443 563 #https, snews
acl Safe_ports port 70 #gopher
acl Safe_ports port 210 #wais
acl Safe_ports port 1025-65535 #unregistered_ports
acl Safe_ports port 280 #http-mgmt
acl Safe_ports port 488 #gss-http
acl Safe_ports port 591 #filemaker
acl Safe_ports port 777 #multiling http
acl redelocal src 192.168.10.0/24
acl CONNECT method CONNECT
acl outros proxy_auth -i "/etc/squid/outros"
acl outrossites dstdomain "/etc/squid/outrossites"

#------------HTTP_ACCESS-------------------
http_access deny bloqueados
http_access deny outros !outrossites
http_access allow ncsa_users
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow redelocal
http_access deny all
icp_access allow redelocal
icp_access deny all


ULTIMAS LINHAS DO CACHE.LOG:
2009/02/11 14:44:14| clientReadRequest: FD 20 (192.168.10.126:1294) Invalid Request
2009/02/11 14:44:14| clientReadRequest: FD 23 (192.168.10.126:1295) Invalid Request
2009/02/11 14:44:14| clientReadRequest: FD 24 (192.168.10.126:1297) Invalid Request
2009/02/11 14:44:14| clientReadRequest: FD 20 (192.168.10.126:1296) Invalid Request
2009/02/11 14:44:14| clientReadRequest: FD 23 (192.168.10.126:1298) Invalid Request
2009/02/11 15:06:40| ctx: enter level 0: 'http://graficos.invertia.com.mx/Megacharts/MChartISAPI.dll?Chart?ACK=30805&UID=DemoDLYemoDLY&PRD=InvMX&SYM=IB030BOVESPA&SPR=1&SFR=5:O:1&SCL=&SLK=WWW&TIU=0&TIO=&TIS=&CSZ=140,100&CST=1,1&CGR=3&IMG=PNG&RGN=BR&XML=InvertiaTiny&TMP=0&symalt=&cache=300'
2009/02/11 15:06:40| WARNING: unparseable HTTP header field {HTTP/1.1 200 OK}
2009/02/11 15:06:40| ctx: exit level 0
2009/02/11 15:06:40| WARNING: unparseable HTTP header field {HTTP/1.1 200 OK}
2009/02/11 15:07:20| clientReadRequest: FD 39 (192.168.10.106:1775) Invalid Request
2009/02/11 15:07:20| clientReadRequest: FD 39 (192.168.10.106:1777) Invalid Request
2009/02/11 15:36:01| clientReadRequest: FD 20 (192.168.10.112:1234) Invalid Request
2009/02/11 15:36:01| clientReadRequest: FD 20 (192.168.10.112:1235) Invalid Request
2009/02/11 15:36:01| clientReadRequest: FD 20 (192.168.10.112:1236) Invalid Request
2009/02/11 15:36:01| clientReadRequest: FD 20 (192.168.10.112:1237) Invalid Request

Esses erros de “clientReadRequest” dá direto.

Desculpa a extensão da pergunta, mas é que tô desesperado, e queria que ficasse bem claro o problema, que para mim está sendo impossível resolver, agradeceria muito a ajuda de vocês, pois o pessoal aqui usa bastante a internet, e sobra para mim sempre.

Muito Obrigado!

[irado]

bão.. a mim tá mais parecendo uma placa de rede abobada ou um switch problematico. Mas vamos tentar definir melhor as coisas, na base do "eu acho" não funciona.

esqueça (por enquanto) o squid. Quando u'a máquina não conseguir se comunicar/navegar, faça:

a) pingue-a a partir de outra máquina ou mesmo do gw
b) no gw, coloque o tcpdump no ar, assim:
tcpdump -nvvi interface_interna host maquina_qualquer (das que costumam cair)
examine esse trafego até que 'desapareça'. Quando (e se) desaparecer, pingue a maquina_qualquer pra ver se responde.

a idéia é ISOLAR o problema, senão a gente endoida

vai colocando aqui os resultados.

[alexandrecorrea]

de acordo com os logs.. nao idica problema no squid nao !!

[SebaCueto]

Opa!, valeu pela atenção ai pessoal!
Seguinte, caiu enquanto eu tava lendo aqui as mensagems (que coincidencia), fiz o tcpdump, ta aí o resultado:


smb:~# tcpdump -nvvi eth0 host informatica
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

(nao tava acontecendo nada e dei um Ctrl + c)
0 packets captured
2115 packets received by filter
1935 packets dropped by kernel


Pinguei o meu micro pelo servidor(enquanto rodava o tcpdump) e ele voltou a vida imediatamente!!, o que será que pode ser??, nunca tinha visto algo assim!.

Obs: quando cai a internet no meu micro não cai a rede, eu continuo acessando os compartilhamentos normalmente.
Outra coisa, os switch faz tempo que tam ligado direto, um 3com(1Gb) e 1 D-link(100Mb) Eu to conectado no D-link, que vai ate o 3com, ate acessar o servidor, mais tem gente que ta direto no 3com e tb da problema.

Obrigadão pela força ae!!!

[SebaCueto]

Caiu de novo, pinguei algums sites a traves do meu pc, e funcionou legal, mas o firefox continuava sem funcionar. Pinguei um micro da rede, mesmo resultado.
Peguei o micro do chefe e pinguei o meu.... voltou a funcionar!, nao entendo...

[irado]

tá ruço..

defina "mas o firefox continuava sem funcionar.", indica o que? mensgem de erro? página?

ping não é propriamente uma boa ferramenta, o traceroute sim; sempre que possivel, faça traceroute PARA FORA, só pra ver onde (ou o que) para.

[SebaCueto]

No Firefox aparece um erro dicendo que a conexão de rede foi reiniciada, ou algo parecido, cuando acontecer de novo eu pego certinho o erro.
Valeu!

[SebaCueto]

Aparece assim no Firefox:


Conexão interrompida
A conexão para o servidor foi reiniciada durante o carregamento da página.
O link de rede foi interrompido durante a negociação da conexão. Por favor, tente de novo.


Dei um traceroute para um site externo e demorou um monte para chegar no servidor, depois foi, e a net voltou.
Não será problema de dns???

Valeu!

[irado]

pela indicação do firefox.. hmm...

será que vc não tá usando placas de rede realtreko? são conhecidas por apresentarem um comportamento errático, ao invés de morrerem de vez. Se estiverem no servidor.. bem, troque por placas de gente, pelo menos os servidores merecem isso. Na santa efigenia vc compra 3com usadas 10/100 por até 5 merréis.. e vale a pena.

não querendo semi-novas, então coloque intel. Jogue as realtreko fora, sem dó nem piedade.

bão.. pra analisar:

será que é o dns? (não parece).

dig uol.com.br all
dig @208.67.222.222 under-linux.org all

compare os resultados (tempo)

[SebaCueto]

Olha só Irado,

dig uol.com.br all
;; Query time: 835 msec

dig @208.67.222.222 under-linux.org all
;; Query time: 1870 msec

Com respeito as placa de rede: o servidor tem 2 Intel, e na rede tem de tudo espalhado por ai, 3com, realtek, via, etc.
Mas cai com todo mundo, inclusive com as workstation da dell, que são porrada e tem link de 1Gb.

Outra coisa, aqui eu instalei o bind9, mas não configurei nada, deixei default.
No squid nao configurei dns, ele pega do resolv.conf, que tá assim:
nameserver 201.10.120.3
nameserver 201.10.1.2
nameserver 200.160.145.2
(todos brasil telecom)

Agradeço novamente

[irado]

a latência aí é elevada, aqui é menor que 10% da sua:
dig @208.67.222.222 under-linux.org all
[..]
;; Query time: 147 msec

bem.. dada essa latência cavalar, é possivel que vc tenha TAMBÉM broadcast wins na rede; vc TEM um servidor wins, pra reduzir isso? (apost no "não" - rss).

vc usa dhcp? pode ser que, dada a latência, no "refresh" as máquinas percam a resposta do servidor; faça assim: SE for dhcp, fixe o ip-addr de uma ou duas máquinas que despencam e avalie se o problema persiste.

use o tcpdump + wireshark pra avaliar o tráfego de rede, principalmente o broadcast. Se vc se der melhor com o trafshow ou iptraf use-os.

e vamos ver como isso fica; a solução existe, apenas não a vimos, ainda.

e o magnum hem? e o scorpion? os dois tão fingindo que não estão nos vendo..
rss

[SebaCueto]

Tem um servidor DHCP no servidor, mas todas as maquinas estão com IP fixo.
o wireshark tô tentando baixar, mas ta dificil, porque internet fica caindo
Cara, nunca usei nenhum dos softwares que tu citou abaixo, tô lendo sobre o wireshark, tem algum recomendado para iniciantes?
Server WINS não tem não.(apostou certo, he he)

Vou tentar então, dar uma investigada na rede, falou!

[SebaCueto]

Dei um tcpdump -nvvi eth0 host 192.168.10.122
agora pegou!, pelo nome não foi, tive que botar o IP.
O negócio ia passando as linhas muito rápido, eu tava com firefox(sem carregar nada) e putty abertos.
Vou postar so a finalera:

11:41:14.145646 IP (tos 0x0, ttl 128, id 48070, offset 0, flags [DF], proto: TCP (6), length: 92) 192.168.10.122.2151 > 192.168.10.1.22: P 1732641:1732693(52) ack 14631516 win 58283
11:41:14.145716 IP (tos 0x10, ttl 35, id 61352, offset 0, flags [DF], proto: TCP (6), length: 156) 192.168.10.1.22 > 192.168.10.122.2151: P 14632584:14632700(116) ack 1732693 win 8576
11:41:14.145770 IP (tos 0x0, ttl 128, id 48071, offset 0, flags [DF], proto: TCP (6), length: 92) 192.168.10.122.2151 > 192.168.10.1.22: P 1732693:1732745(52) ack 14632208 win 57591
11:41:14.145783 IP (tos 0x0, ttl 128, id 48072, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.10.122.2151 > 192.168.10.1.22: ., cksum 0x4b98 (correct), 1732745:1732745(0) ack 14632584 win 57215
11:41:14.145859 IP (tos 0x10, ttl 35, id 61353, offset 0, flags [DF], proto: TCP (6), length: 268) 192.168.10.1.22 > 192.168.10.122.2151: P 14632700:14632928(228) ack 1732745 win 8576
11:41:14.146019 IP (tos 0x0, ttl 128, id 48073, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.10.122.2151 > 192.168.10.1.22: ., cksum 0x4b98 (correct), 1732745:1732745(0) ack 14632928 win 56871
11:41:14.146143 IP (tos 0x0, ttl 128, id 48074, offset 0, flags [DF], proto: TCP (6), length: 92) 192.168.10.122.2151 > 192.168.10.1.22: P 1732745:1732797(52) ack 14632928 win 56871
11:41:14.146150 IP (tos 0x0, ttl 128, id 48075, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.10.122.2151 > 192.168.10.1.22: ., cksum 0x298c (correct), 1732797:1732797(0) ack 14632928 win 65535
11:41:14.146205 IP (tos 0x10, ttl 35, id 61354, offset 0, flags [DF], proto: TCP (6), length: 732) 192.168.10.1.22 > 192.168.10.122.2151: P 14632928:14633620(692) ack 1732797 win 8576
11:41:14.146518 IP (tos 0x0, ttl 128, id 48076, offset 0, flags [DF], proto: TCP (6), length: 92) 192.168.10.122.2151 > 192.168.10.1.22: P 1732797:1732849(52) ack 14632928 win 65535
11:41:14.146573 IP (tos 0x10, ttl 35, id 61355, offset 0, flags [DF], proto: TCP (6), length: 716) 192.168.10.1.22 > 192.168.10.122.2151: P 14633620:14634296(676) ack 1732849 win 8576
11:41:14.146643 IP (tos 0x0, ttl 128, id 48077, offset 0, flags [DF], proto: TCP (6), length: 92) 192.168.10.122.2151 > 192.168.10.1.22: P 1732849:1732901(52) ack 14633620 win 64843
11:41:14.146697 IP (tos 0x10, ttl 35, id 61356, offset 0, flags [DF], proto: TCP (6), length: 588) 192.168.10.1.22 > 192.168.10.122.2151: P 14634296:14634844(548) ack 1732901 win 8576
11:41:14.146892 IP (tos 0x0, ttl 128, id 48078, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.10.122.2151 > 192.168.10.1.22: ., cksum 0x2924 (correct), 1732901:1732901(0) ack 14634844 win 63619
11:41:14.147018 IP (tos 0x0, ttl 128, id 48079, offset 0, flags [DF], proto: TCP (6), length: 92) 192.168.10.122.2151 > 192.168.10.1.22: P 1732901:1732953(52) ack 14634844 win 63619
11:41:14.147074 IP (tos 0x10, ttl 35, id 61357, offset 0, flags [DF], proto: TCP (6), length: 860) 192.168.10.1.22 > 192.168.10.122.2151: P 14634844:14635664(820) ack 1732953 win 8576
11:41:14.147268 IP (tos 0x0, ttl 128, id 48080, offset 0, flags [DF], proto: TCP (6), length: 92) 192.168.10.122.2151 > 192.168.10.1.22: P 1732953:1733005(52) ack 14634844 win 63619
11:41:14.147322 IP (tos 0x10, ttl 35, id 61358, offset 0, flags [DF], proto: TCP (6), length: 652) 192.168.10.1.22 > 192.168.10.122.2151: P 14635664:14636276(612) ack 1733005 win 8576
11:41:14.147518 IP (tos 0x0, ttl 128, id 48081, offset 0, flags [DF], proto: TCP (6), length: 92) 192.168.10.122.2151 > 192.168.10.1.22: P 1733005:1733057(52) ack 14635664 win 62799
11:41:14.147570 IP (tos 0x10, ttl 35, id 61359, offset 0, flags [DF], proto: TCP (6), length: 524) 192.168.10.1.22 > 192.168.10.122.2151: P 14636276:14636760(484) ack 1733057 win 8576
11:41:14.147643 IP (tos 0x0, ttl 128, id 48082, offset 0, flags [DF], proto: TCP (6), length: 92) 192.168.10.122.2151 > 192.168.10.1.22: P 1733057:1733109(52) ack 14636276 win 62187
11:41:14.147651 IP (tos 0x0, ttl 128, id 48083, offset 0, flags [DF], proto: TCP (6), length: 92) 192.168.10.122.2151 > 192.168.10.1.22: P 1733109:1733161(52) ack 14636276 win 62187
11:41:14.147721 IP (tos 0x10, ttl 35, id 61360, offset 0, flags [DF], proto: TCP (6), length: 364) 192.168.10.1.22 > 192.168.10.122.2151: P 0.1.22 > 192.168.10.122.2151: P 14641616:14641684(68) ack 1733629 win 8576

70782 packets captured
77200 packets received by filter
6367 packets dropped by kernel
smb:~# man tcpdump


Só uma observação, não tem nenhum 192.168.1.22 aqui.

[irado]

powww.. se vc não conhece o parzinho tcpdump/wireshark, esqueça

poluido pra kct - o xxx.1.22 é o acesso do putty na porta 22 do servidor, óbvio, ssh.

precisariamos despoluir isso, mas..

não tem algum coleguinha que vc possa chamar a troco de feijoada do sábado pra ajudar vc ??

[SebaCueto]

Pois é, não conhecia esses caras, e que eu to aprendendo linux na marra mesmo, he he.
Já andei lendo algo sobre wireshark no site oficial, vou tentar dar uma estudada no fimde.
Qual seria o software principal deles??, ou tem que fazer uma mistura mesmo??

Tu acha que o problema é isso mesmo?, essa "poluição" que tu falou??
Outra coisa, fis o tcpdump apontando a outros micros, e não ficou táo ruim assim, foi tranquilo, será algum virus??

Valeu!

PS: esse "6367 packets dropped by kernel" é normal ou o kernel não deveria perder nenhum pacote??

[irado]

bem, em minha opinião quem quer fazer "na marra" é porque é um grande preguiçoso ou não sabe ler. Acaba acontecendo o que vinha acontecendo com vc: "chutando" pra todo lado, apontando pra lado completamente errado. Um exemplo é este trédi mesmo: "Squid com problema, caindo direto" - ONDE está o squid no problema? No dia em que acerta, não sabe porque acertou - em síntese: é preguiçoso mas trabalha pra kct, muito mais que o normal, e fazendo errado.

Procure (google):
tcpdump wireshark tutorial:
tcpdump wireshark tutorial - Google Search

e APRENDA, faça, repita, repita MUITAS VEZES, releia tudo de novo e comece outra vez.

procure aprender sobre redes; aqui mesmo existem tutoriais ÓTIMOS, vc vai ganhar muito com isso.

finalmente: vc pode estar com alguma placa "ruidosa" na rede. Pra isolar, vc teria que DIREITO o tcpdump e remover um cabo de rede de cada máquina, UM POR VEZ, até isolar aquela que possivelmente gere esse broadcast tremendo.

comece a fazer as coisas direito. Como eu digo para meus estagiotários: "se vc fizer certo, funciona".

[SebaCueto]

Não, não, na marra eu me referia a que to aprendendo por mim próprio, não tem ninguém para me ajudar e não to fazendo nenhum curso, desculpa, e que o meu português não é muito bom.
Sem ler não como aprender, he he. E é claro, tem muito para aprender ainda.

Tu acha que é esse o problema mesmo, algum micro que não para de mandar pacotes pela rede?

[irado]

sim, eu acho que (possivelmente) seja uma rede tempestuosa. Porém os "culpados" podem ser muitos, uma placa (em um host qualquer), um switch com porta "estranha"; enfim, só poderemos saber quando vc conseguir (madrugada? sabadão? domingo?) uma rede com TODOS os equipamentos desligados sendo ligados um a um e "lidos" pelo parzinho tcpdump+wireshark. No caso, quando me refiro a isso (parzinho) é pra ser gerado um arquivo binário pelo tcpdump (man tcpdump) a ser lido pelo wireshark (man wireshark).

vc pode tentar, também, o iptraf, usando os vários modos de filtragem (man iptraf) mas vc vai ter que ler MUITO o man dêle.

divirta-se.

[SebaCueto]

isso farei então, o antes possível, depois posto os resultados.

[SebaCueto]

Opa, voltei!
O meu amigo irado, ou alguem que possa me ajudar.
Fiz o esquema que tu me falou, o parziho tcpdump+wireshark, e realmente, tinha dois Centros de Usinagem que ficavam mandando broadcast direto, praticamente um por segundo, e um micro com virus tb fazendo broadcast.

Atualmente os dois centros de usinagem estão fora da rede, e o virus já foi, mas continua acontecendo os problemas antes mencionados, ja verifiquei todos os micros aqui com o tcpdump, e uma das coisas que achei estranho é que todos eles, mesmo que ninguem esteja usando ficam mandando direto broadcast do tipo:"who has 192.168.10.x, tell 192.168.10.y".
Isso é problema de dns, certo?
Tô perdendo a paciência com esse negócio, vou acabar quebrando tudo aqui, por favor alguem me ajude!!!