Squid centos 6.3 tcp_miss/000

stefaniobrunhara
(usa CentOS)

Enviado em 15/06/2013 - 19:51h

Meu servidor centos 6.3 não esta abrindo alguns sites, terra.com.br, www.google.com.br, etc...
Pesquisei na internet achei vários links, dizendo ser dns, cache, hardware, mas nada deu certo.

Ele abre o site do ig, bradesco, e vários outros, porém existe vários outros sites que ele da o erro tcp_miss/000.


Se retiro as estações do proxy, navega sem problema, então o dns, firewall, placa de rede, estão funcionando, apaguei o cache, troquei de computador, troquei a mídia do centos 6.3, para o centos live cd, instalei o rpm do squid do centos 6.2

Cheguei a fazer um firewall liberando a rede toda para tirar quaisquer outras duvidas, troquei dns e nada, sempre veja esta mensagem no log do squid


Log do erro


1371231954.993 2499 192.168.0.58 TCP_MISS/000 0 GET http://www.uol.com.br/ - DIRECT/www.uol.com.br -
1371231957.493 2500 192.168.0.58 TCP_MISS/000 0 GET http://www.uol.com.br/ - DIRECT/www.uol.com.br -
1371231959.993 2498 192.168.0.58 TCP_MISS/000 0 GET http://www.uol.com.br/ - DIRECT/www.uol.com.br -


Fiz um squid.conf bem simples e um firewall mesmo assim não achei o problema


firewall simples para testes

#!/bin/bash

iptables -F
iptables -X
iptables -t nat -F
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

echo 0 > /proc/sys/net/ipv4/conf/all/log_martians
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 1 > /proc/sys/net/ipv4/ip_dynaddr

modprobe iptable_nat
modprobe ip_conntrack
modprobe ip_conntrack_ftp
modprobe ip_tables

iptables -t nat -A PREROUTING -p tcp -d 2x.xx.1x0.1x0 --dport 80 -j REDIRECT --to-ports 3128

iptables -A FORWARD -t filter -j ACCEPT
iptables -A FORWARD -t filter -j ACCEPT -m state --state ESTABLISHED,RELATED
iptables -A FORWARD -s 0/0 -d 0/0 -j ACCEPT

iptables -t nat -A POSTROUTING -s 0/0 -d 0/0 -o eth+ -j MASQUERADE


## Squid.conf simples para testes

http_port 192.168.0.254:3128 transparent
#dns_nameservers 8.8.8.8
cache_mgr suporte@xxxxxxx.com.br
visible_hostname 192.168.0.254
cache_mem 32 MB
cache_swap_low 90
cache_swap_high 95
maximum_object_size 4096 KB
ipcache_size 4096
cache_dir ufs /var/spool/squid 50 16 50
cache_access_log /var/log/squid/access.log
cache_log /var/log/squid/cache.log
cache_store_log /var/log/squid/store.log
coredump_dir /var/spool/squid
shutdown_lifetime 5 seconds
cache_effective_user squid
cache_effective_group squid
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320


acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7 # RFC 4193 local private network range
acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines

acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1

acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
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 CONNECT method CONNECT

acl pal-nao url_regex -i "/etc/squid/pal-nao"

http_access deny pal-nao
http_access deny !Safe_ports

http_access deny pal-nao
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

http_access allow localnet
http_access allow localhost

http_access allow all

#http_access deny all

Buckminster
(usa Debian)

Enviado em 15/06/2013 - 21:45h

No Squid:

cache_mem 256 MB << esta linha deixe assim


cache_dir ufs /var/spool/squid 2048 16 256 << esta linha deixe assim


Nas linhas abaixo só deve ficar descomentada a linha da tua rede interna:

#acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
#acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/24 # RFC1918 possible internal network
#acl localnet src fc00::/7 # RFC 4193 local private network range
#acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines


http_access deny !Safe_ports << esta linha está repetida, delete a segunda.


No final coloque essas três linhas:
http_access allow localnet << esta libera a rede interna (acl localnet).
http_access allow localhost << esta libera o localhost.
http_access deny all << esta nega tudo que não foi liberado acima dela.

No Iptables:

Esta linha:
iptables -t nat -A PREROUTING -p tcp -d 2x.xx.1x0.1x0 --dport 80 -j REDIRECT --to-ports 3128

deixe assim:
iptables -t nat -A PREROUTING -i ethx -p tcp --dport 80 -j REDIRECT --to-port 3128 << aqui coloque a placa da tua rede interna.


Esta linha:
iptables -t nat -A POSTROUTING -s 0/0 -d 0/0 -o eth+ -j MASQUERADE

deixe assim:
iptables -t nat -A POSTROUTING -o ethx -j MASQUERADE << aqui coloque a placa de rede de entrada da internet.

Faça as alterações. Salve e saia dos arquivos.

Pare o Squid e execute:

# rm -rf /var/spool/squid/*

# squid -z

Reinicie o Iptables, reinicie o Squid e teste.

Faça esses testes, apesar de que o erro: 000 Resposta não recebida (você pode estar com um problema no link de internet).

As placas de rede do servidor (tanto a de entrada da internet como a da rede interna) estão com IP automático ou fixo?

stefaniobrunhara
(usa CentOS)

Enviado em 15/06/2013 - 22:37h

O problema continua, agora detalhe que não cometei, neste lugar tenho duas internet, uma gvt e outra plenatarium, todas as duas dão o mesmo problema, este mesmo script básico, funciona em um servidor debiam 6.0

Buckminster
(usa Debian)

Enviado em 15/06/2013 - 22:43h

Você fez as alterações que sugeri?

Quando você fala em duas internets você está querendo dizer dois links entrando no mesmo servidor?

No servidor Debian 6.0 tem dois links também?

stefaniobrunhara
(usa CentOS)

Enviado em 15/06/2013 - 23:14h

sim, fiz as alterações

Os Ips do servidor são fixos.

Não tem dois links entrando no mesmo servidor, apenas fiz teste com outro link.

É como falei acima, se tiro as estações do proxy elas navegam normal, então isto descarta o problema de link e dns, e hardware.

Este script que postei, são apenas para teste, esta maquina estava funcionando normal, de uma hora para outra, começou este problema. O firewall e o squid.conf deste servidor e bem grande, fiz um básico para testes. A configuração "256" errada foi uma das tentativas de achar o problema.

Buckminster
(usa Debian)

Enviado em 15/06/2013 - 23:34h

Desinstala, reinicia e instala o Squid de novo.
Mas desinstala ele completamente.

stefaniobrunhara
(usa CentOS)

Enviado em 17/06/2013 - 09:20h

Na mesma maquina, eu tentei com 2 cds diferente do centos, também instalei em outra maquina, o chato é que vou ter que deixar o debiam no lugar do centos, e não vou ter tempo para achar o problema.

Buckminster
(usa Debian)

Enviado em 17/06/2013 - 13:22h

Bom, estive analisando mais a fundo o squid.conf.

Esta linha abaixo, tente colocar um nome e não um IP.
visible_hostname 192.168.0.254


Estas duas linhas abaixo, você definiu o usuário squid e o grupo squid. No squid.conf original diz isso:

This option is not recommended by the Squid Team.
Esta opção não é recomendada pelo time do Squid.

E veja também a tradução das opções:

cache_effective_user
"Se você iniciar o Squid como root, ele vai mudar a efetiva/real UID/GID para o usuário especificado na regra. O padrão é mudar a UID do proxy."


cache_effective_group
"O Squid define o GID para o efetivo ID do grupo padrão do usuário (retirado do arquivo de senhas) e uma lista de grupos suplementares dos membros do grupo.
Se você quiser que o Squid funcione com um GID específico, independentemente das associações de grupo do usuário, defina-o para o grupo (ou GID) que você deseja onde o Squid atue. Ao definir isso, todos os outros privilégios de grupo do usuário efetivo são ignorados e só este GID será eficaz. Se o Squid não for iniciado como root, o usuário DEVE ser membro do grupo especificado."

Talvez seja isso. Teste aí comentando essas duas linhas. Você criou o grupo squid e/ou deu as devidas permissões para ele?

Eu, particularmente, nunca uso essas duas linhas devido a elas serem um tanto trabalhosas de implementar e devido ao próprio time do Squid desaconselhar o seu uso.
É claro que o uso correto delas fornece maior segurança, mas ao mesmo tempo setam o Squid para funcionar somente com um usuário e um grupo específico.

stefaniobrunhara
(usa CentOS)

Enviado em 17/06/2013 - 22:15h

Esta opção visible_hostname eu tentei com e sem ela, a opção do usuario eu não tentei.

Hoje tive que terminar o serviço com o debiam, então não terei mais o ambiente para encontrar a causa exata do problema.

O mais estranho é que este servidor funcionou 3 meses com os mesmo scripts, que hoje não estão funcionando mais, e este mesmo escripts funciona no debiam.

Vou deixar o tópico aberto, talves apareça alguém que tenha vivido o mesmo problema e conheça a solução exata.

Obrigado, Buckminster!

Buckminster
(usa Debian)

Enviado em 18/06/2013 - 01:44h

Bom, o que eu posso dizer é que tem dado muitos problemas de Squid deixando de funcionar de uma hora para outra e, de repente, voltam a funcionar, também de uma hora para outra.

A minha opinião é que tem alguma coisa a ver com essa troca de IPv4 para IPv6. Os cabeçalhos são diferentes e as requisições mudam um pouco de forma. Tem muitos DNSs que estão sendo atualizados para resolver nomes das duas maneiras e acredito que dá alguma incompatibilidade com o Squid.
Mas posso estar enganado.

Deixo aqui um link para uma tabela com os códigos de status do Squid:
http://www2.savant.com.br/index.php/artigos/tutoriais/34

stefaniobrunhara
(usa CentOS)

Enviado em 18/06/2013 - 11:47h

Buckminster, ontem finalizei a instalação do debiam no lugar do centos, mas estou vendo com o gerente do CPD, que implantei o proxy, se tem como ele deixar um segundo servidor, para que eu possa continuar a busco do problema. O lance todo é que deixei a indústria uma semanas com este problema, e o pessoal estava fazendo a festa, são mais de 200 usuários não tinha como protelar mais. Como o gerente do cpd, gosta de debiam, lancei mão dele mesmo, mas a vontade de achar o problema é grande!

Tenho vários servidores de proxy instalado, e nunca tive um problema deste, todos são instalado por script, então é um padrão, e por causa deste padrão, a gente acaba ficando cego, porque você tem a mesma coisa rodando certinho em vários lugares, ai aparece um zebra desta você fica doido kkk.

mas obrigado mais uma vez!

Buckminster
(usa Debian)

Enviado em 18/06/2013 - 12:55h

Eu nunca fiz instalação nenhuma por script. O sistema muda de distribuição para distribuição.
Script eu uso apenas para executar determinadas tarefas que não envolvam nada muito importante.
Eu sou da opinião que em servidores quanto menos automatizado melhor.
Uma vez instalado e configurado o servidor, ele não requer muitos cuidados.
Nem as atualizações eu automatizo, prefiro fazer manualmente, assim dá para saber na hora se a atualização causou um problema.