Computadores com Win7 param de navegar do nada [RESOLVIDO]

bacurinho
(usa Debian)

Enviado em 22/04/2015 - 18:54h

Administro um domínio com vários computadores. Alguns deles utilizam winxp, outros win7 (32 e 64)...
O controlador de domínio é um Server 2008.
No proxy/filtro de conteúdo utilizamos o Debian com iptables + squid...
Os computadores tem o ip setado.
O problema que ocorre é que, algumas estações com win7 param de navegar. Se reiniciar os computadores, ou mexer em qualquer configuração da placa de rede a máquina volta a navegar.
Se ficar forçando a navegação, não vai. Se tentar pingar "pra fora", no endereço... Ele volta a funcionar.
Se liberar o acesso no iptables para o determinado ip, ele volta a funcionar também, por exemplo: iptables -I FORWARD -p tcp -s 10.0.0.30 -j ACCEPT...

Vi alguns tópicos com gente passando por problemas parecidos, mas sem resolução:

http://www.vivaolinux.com.br/topico/Squid-Iptables/Iptables-Windows-7-servidor-de-dns-nao-responde
http://www.vivaolinux.com.br/topico/Servidores-Linux-para-iniciantes/win7-nao-navega
http://www.vivaolinux.com.br/topico/Squid-Iptables/FirewallSquid-problema-de-comunicacao-com-Windows...

O iptables tá dropando tudo, e liberando só o necessário.
Os XPs tão uma maravilha. Quando tinha alguns notebooks com winvista acontecia também.
O problema é do vista pra "cima".

A solução temporária que a gente achou foi deixar um .bat nas estações...
ping ipdoproxy
ping 8.8.8.8
ping www.google.com.br

Após rodar o bat, a maquina volta a navegar.

Andei lendo alguma coisa com relação ao NCSI (monitor de conexão) do Windows 7, mas acho que não é o caminho.
Acredito que não seja configuração, e sim alguma peculiaridade do win7.

Alguém tem alguma pista do que pode estar acontecendo?

bmarquesm
(usa Fedora)

Enviado em 03/05/2015 - 17:46h

No momento em que ocorrer o problema com alguma máquina, tente monitorar pelos logs ou por um sniffer como o tcpdump no seu firewall/proxy.

Se a estação em que ocorrer o problema tiver NAT (for totalmente liberada via firewall) faça o seguinte no seu firewall Debian como root:

tcpdump -Snni any host IP_DA_ESTACAO

No momento que der enter nesse comando no Debian, tenta abrir o navegador da estação e navegar. Com isso, irão aparecer as conexões na console. Você posta aqui que vai dar para ver melhor o que está ocorrendo.

Caso a máquina acesse a internet via proxy, posta aqui os logs do /var/log/squid/access.log no momento do acesso (comando como root: tail -f /var/log/squid/access.log | grep IP_DA_ESTACAO). Novamente você pode postar aqui para identificar o que seu proxy retorna no momento do acesso.

Caso não se sinta a vontade de colocar os logs aqui, pode alterar os IPs reais por outros, bastando indicar quem é o IP do proxy/firewall e qual o da estação.

bacurinho
(usa Debian)

Enviado em 05/05/2015 - 11:25h

Acho que descobri o problema...

Nosso proxy/firewall tem duas interfaces, uma pra rede local e uma conectada ao modem... (o modem não está conectado ao servidor diretamente, e sim a um switch... Acho que é aí que está nosso problema...)

Ontem quando queria monitorar o problema com o tcpdump, ao invés do iptraf como já vinha fazendo o problema parou de ocorrer...
Quando um usuário relatou ter acontecido novamente, corri para a estação dele pra fazer os testes e deixar monitorando no servidor, mas o burro aqui esqueceu de deixar jogando a saída do tcpdump para um arquivo, e quando fui tentar olhar o que tinha na tela, não consegui ver o começo para poder analisar... Mas consegui "pescar" alguma coisa de requisições ARP...

Tinha conversado com um usuário (pedroalexr) aqui do fórum que tinha relatado um problema semelhante ao que eu estou passando... (http://www.vivaolinux.com.br/topico/Squid-Iptables/Computadores-perdendo-acesso-a-rede)

Ele também me disse pra usar o tcpdump para monitorar o tráfego, pois, pelo que ele me falou, e pelo que entendi, o proxy dele tinha dois links e as requisições de saída estavam sendo feitas no link errado... (se entendi corretamente)

Voltando e resumindo... Pelo que notei, o servidor está respondendo as requisições ARP para o IP da rede local com a MAC da placa de rede que está com a rede do modem...
Eu estava usando o iptraf para monitorar, mas monitorava apenas a interface da rede local...
Hoje ao configurar uma estação aqui para navegar pelo servidor, o problema aconteceu e eu pude constatar que na tabela arp da estação, a MAC relacionada ao IP do servidor era a MAC da interface conectada ao modem... Forçar a navegação não funciona, ele não atualiza... Após pingar até o servidor, a tabela arp atualiza e a MAC fica certa...


Aqui vai um pedaço do log do tcpdump

MAC Servidor - Rede local - xx:xx:xx:xx:xx:xx
MAC Servidor - Internet - yy:yy:yy:yy:yy:yy
MAC Estação - zz:zz:zz:zz:zz:zz

IP Servidor - Rede local - 192.168.254.254
IP Estação - 192.168.254.7


Com o problema....
09:46:25.848832 ARP, Request who-has 192.168.254.254 (yy:yy:yy:yy:yy:yy) tell 192.168.254.7, length 46
09:46:25.848850 ARP, Reply 192.168.254.254 is-at yy:yy:yy:yy:yy:yy, length 28

Pingando....
09:48:56.083806 IP 192.168.254.7 > 192.168.254.254: ICMP echo request, id 1, seq 3200, length 40
09:48:56.087307 ARP, Request who-has 192.168.254.7 tell 192.168.254.254, length 28
09:48:56.087345 ARP, Request who-has 192.168.254.7 tell 192.168.254.254, length 46
09:48:56.087398 ARP, Reply 192.168.254.7 is-at zz:zz:zz:zz:zz:zz, length 46
09:48:56.087401 IP 192.168.254.254 > 192.168.254.7: ICMP echo reply, id 1, seq 3200, length 40

Depois do ping...
09:49:04.855204 ARP, Request who-has 192.168.254.254 (xx:xx:xx:xx:xx:xx) tell 10.0.0.7, length 46
09:49:04.855215 ARP, Reply 192.168.254.254 is-at xx:xx:xx:xx:xx:xx, length 28


To lendo alguma coisa sobre o arp_ignore... Pelo que eu li, acho que deve resolver meu problema...
Se alguém tiver outra solução, será bem-vinda...

Obrigado bmarquesm.

bmarquesm
(usa Fedora)

Enviado em 10/05/2015 - 20:13h

Bom pelo que entendi, seu cenário não é o mais adequado de se ter, pois temos tudo (modem, estações, servidor,etc) ligados à um switch. Além de uma falha de segurança, isso pode se tornar um gargalo futuramente (se já não estiver sendo) devido ao alto índice de broadcast que está sendo gerado em cima deste switch que você possui. Críticas a parte (quero que entende-a como construtiva, claro), você pode tentar na minha visão duas coisas:


1 - Alterar o cenário:

--> Modem ligado diretamnte à uma interface de rede do servidor;
--> Servidor com apenas uma placa de rede ligada ao switch da rede local e a outra somente no modem;

OU

2 - Utilizar os recursos de ARP_IGNORE e ARP_ANNOUNCE;

Inserir no /etc/sysctl.conf:

net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.eth0.arp_announce = 2

Colocar em memória:

echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce

Sugiro de longe a primeira alternativa, porém se for uma empresa muito grande e houver muita complicação em fazer esta alteração e reconfigurar o servidor de acordo com o novo cenário, você tenta a segunda. Coloquei os valores arp_ignore e arp_announce com os que achei conveniente com base no que foi repassado, porém você deve ler bem e ter atenção ao mudar estes parâmetros do sistema operacional, por isso traduzi algumas definições mais importantes de http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/arp_ignore_to_disable_ARP e coloquei para que você decidir melhor.


arp announce - Configura diferentes modos de informar o endereço IP de origem vindos de pacotes IP em requisições ARP enviadas à interface; (ARP Requests enviados por esta interface)

0 (default)- Usa qualquer endereço local configurado em qualquer interface;
1 - Tenta evitar endereços locais que não fazem parte da mesma rede solicitada para esta interface;
2 - Sempre usa o melhor endereço de rede para o destino. Neste modo, ele ignora o campo origem presente no pacote IP e tenta escolher um endereço local melhor para conversar com o host remoto.

arp ignore - Configura diferentes modos de envio de respostas à requisições ARP que resolvem endereços IPs em locais (físicos); (ARP Replys enviados por esta interface)

0 (default) - Usa qualquer endereço local configurado em qualquer interface;
1 - Responde somente se o endereço IP de destino for um endereço local configurado na interface que entrou a requisição;
2 - Responde somente se o endereço IP de destino for um endereço local configurado na interface que entrou a requisição e se ambas as partes (origem e destino) fizerem parte da mesma subrede;
3 - Não responde para endereços locais, somente para endereços públicos e outras especificações globais;
8 - Não responde para todos os endereços locais;

bacurinho
(usa Debian)

Enviado em 10/05/2015 - 21:17h

Tudo bem bmarquesm... Eu entendo...
Gostaria muito que fosse desse jeito, mas quem já trabalhou em algum órgão público sabe que as coisas não funcionam do jeito que a gente gostaria... =/
Vários pcs, vários prédios ligados através de redes sem fio, várias redes se expandindo sem nenhum tipo de planejamento, vários troca-troca de pcs de lugar, zoneando a rede toda... Passando um cabo de rede de qualquer jeito dizendo que é provisório e se torna permanente... Apenas uma operadora com ADSL na cidade... O único jeito de fazer um balanceamento com failover foi usar a internet de mais de um local (diferentes prédios)...
Cara, pra fazer bonito, do jeito que teria que ser, só fazendo quase tudo de novo, e, pra isso, nunca tem grana...
É triste cara... Mas deu de mimimi...

Voltando ao problema (o que motivou a abertura do tópico)...
Resolvi usando...
echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter

Cheguei a ler sobre o arp_ignore e arp_announce, mas até então não precisei ir neles... Só o arp_filter já resolveu...
Mais uma vez, muito obrigado bmarquesm.

bmarquesm
(usa Fedora)

Enviado em 12/05/2015 - 13:31h

Beleza bacurinho. Já trabalhei em órgão público sim e sei como funciona, e infelizmente quase sempre é assim mesmo. Que bom que já houve solução para o tópico, só lembra de marcar lá como resolvido. Valeu!