Squid não fica transparente

doidopombal
(usa Outra)

Enviado em 12/04/2012 - 05:12h

Bem vamos lá... hoje de madruga (12-04-2011 01:00) mexendo no servidor ele parou dinovo... ele roda no xenserver e consegui acesso a ele de uma outra rede, portanto fiz acesso direto nele para analisar o problema em si.

Ele estava com a mensagem "echo 0 /proc/system/kernel/hung task timeout secs blocked for more than 120" seconds e travou geral. tive que reiniciar.

Estou um pouco cru em linux, mas creio que o arquivo de log a ser analisado para se descobrir um problema no sistema é o /var/log/messages.

Portanto analisei ele ao longo do dia (11-04-2011)... e o dia inteiro até o último travamento (dos 3 que mencionei hoje) ele ficou dando a seguinte mensagem:

nf_conntrack: table full, dropping packet.

Após o terceiro travamento não deu mais, mas eu também esqueci ligado um log do iptables que rastreava o ACESSO SSH o dia todo, não sei se isso impediu a exibição da mensagem. Portanto não vi nenhuma mensagem diferente do SSH depois do último travamento do dia 11 até o travamento dessa madrugada do 12, simplesmente travou e mostrou isso que falei para vocês "echo 0 /proc/system/kernel/hung task timeout secs blocked for more than 120". Estou analisando o arquivo de log certo nesses casos ou existe outro???

O que é esse "nf_conntrack: table full, dropping packet."??? Será o causador dos meus problemas??? Segui essa dica http://br.groups.yahoo.com/group/squid-br/message/27541 e deixei o tail -f no /var/log/messages para vê se ela volta a aparecer.

Abraços

andrecanhadas
(usa Debian)

Enviado em 12/04/2012 - 12:08h

Memoria:
http://sixsideweb.blogspot.com.br/2010/04/otimizando-seu-squid-squid-tunning.html
MASQUERADE:
Como a rede do roteador esta fora da sua rede o Masquerade vai liberar o acesso das maquinas client ao roteador Admin web)em conjunto com o FORWARD para a rede do roteador (na sua acho que esta no 192.254.0.0 se não me engano)

doidopb
(usa Outra)

Enviado em 12/04/2012 - 20:52h

É meu amigo, não deu jeito mesmo... pediram para o antigo adm resolver o problema dos travamentos que realmente estavam constante, e o mesmo levou apenas alguns minutos para tal.

1) Uma alteração que vi foi no firewall onde ele colocou a política padrão do INPUT da filter como DROP (antes se observar estava ACCEPT)

2) Outra alteração que vi foi a criação do arquivo cbq-0003.in com o seguinte conteúdo:

DEVICE=eth0,10Mbit,1Mbit
RATE=128Kbit
WEIGHT=10Kbit
PRIO=5
RULE=:443,192.168.0.0/16

Mas creio que não influenciou em nada.

Como posso fazer para tentar descobrir o que ele fez??? Já chequei log, tabelas do IPTABLES, squid.conf, rotas... tudo igual antes!!!!

PS: Outra pergunta ... esse server é ligado a um modem roteado da velox... ele trocou a porta padrão do SSH para eu não acessar mais pela antiga, eu vi a nova e fiz o acesso. Mas ele não redirecionou a nova porta no modem para o meu server... ainda está a antiga sendo redirecionada. Como eu estou conseguindo acesso no server com essa porta nova??? A mesma não está sendo redirecionada para o server pelo modem. Como isso é possível!

andrecanhadas
(usa Debian)

Enviado em 12/04/2012 - 21:07h

Provavelmente o modem esta como DMZ para a maquina do server.

andrecanhadas
(usa Debian)

Enviado em 12/04/2012 - 21:12h

Para ver o que foi feito pelo menos na linha de comando pode digitar "history" vai mostrar uma lista dos ultimos comando digitados.

O INPUT estava como Aberto pode ter sido um ataquem ao server o outro arquivo é apenas um controle de banda onde ele limitou a banda porta 443 para a rede 192.168.0.0/24

doidopb
(usa Outra)

Enviado em 12/04/2012 - 21:16h

O history não tem nada, com certeza foi apagado.

O lance é como capturar dados de que rolou esse ataque na INPUT??? É possível??? Não observei nenhuma comunicação em excesso no iptraf durante esse problema

doidopb
(usa Outra)

Enviado em 12/04/2012 - 21:21h

Isso mesmo... Não estava achando a opção do DMZ, mas acabei de localizar. Ele ativou o DMZ

andrecanhadas
(usa Debian)

Enviado em 12/04/2012 - 21:35h

O comando last mostra as ultimas conexões tb pode ser que tenha algo em:
/var/log/messages
/var/log/auth.log
/var/log/faillog
/var/log/user.log

doidopb
(usa Outra)

Enviado em 12/04/2012 - 21:48h

É Andre... muito grato pela ajuda, mas nada! :-(

doidopb
(usa Outra)

Enviado em 12/04/2012 - 21:51h

Desculpa te perturbar com isso dinovo Andre... mas nao entendi bem sua resposta. Poderia ilustrar???

O esquema que tá lá é REDE INTERNET (192.168.1.0/24) <-> (192.167.1.3/24) eth0 FIREWALL COM MASQUERADE eth1 (192.168.254.2/24) <-> modem velox roteado (192.168.254.254/24)

andrecanhadas
(usa Debian)

Enviado em 12/04/2012 - 22:27h

Lembra quando falou que não pingava o roteador?

Então sem o MASQUERADE na placa onde esta o roteador e liberar o FORWARD este IP do roteador não seria acessivel pela rede (client) no IP local apenas pela maquina do firewall.
Ativando o masquerade e Forward eu posso setar o IP no memso range do roteador e sair usando o roteador como gateway em qualquer maquina client.

doidopb
(usa Outra)

Enviado em 13/04/2012 - 09:34h

Tranquilo. Mas para o ping e a net funcionar não bastaria só mascarar a eth1 onde o modem está ligado??? Se sim, qual o objetivo de mascarar a eth0 onde a rede local está ligada???