Página 1 de 2 12 ÚltimoÚltimo
+ Responder ao Tópico



  1. #1

    Question Squid com problema, caindo direto

    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!

  2. #2

    Padrão

    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.



  3. #3

    Padrão

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

  4. #4

    Padrão

    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!!!



  5. #5

    Padrão

    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...

  6. #6

    Padrão

    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.



  7. #7

    Padrão

    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!

  8. #8

    Padrão

    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!



  9. #9

    Padrão

    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)

  10. #10

    Padrão

    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



  11. #11

    Padrão

    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

  12. #12

    Padrão

    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!



  13. #13

    Padrão

    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.

  14. #14

    Padrão

    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 ??
    Última edição por irado; 13-02-2009 às 11:59.



  15. #15

    Padrão

    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??

  16. #16

    Padrão

    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".



  17. #17

    Padrão

    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?

  18. #18

    Padrão

    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.



  19. #19

    Padrão

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

  20. #20

    Padrão

    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!!!