SLES11 inacessibilidade aleatória de uma única máquina

Question

Estou passando por um problema muito estranho e estou perdida agora. Eu configurei várias máquinas SUSE SLES 11 SP2, já que minha empresa tenta migrar para o SUSE. E cada máquina com o SLES 11 tem esse problema específico:

Uma vez instalado, tudo funciona bem. No entanto, se alguém se conecta a partir de uma máquina Debian (Squeeze and Wheezy) ou Putty (versão mais recente) via SSH, a conexão cai ocasionalmente e a máquina permanece inacessível apenas daquela máquina. Se eu, então, me conecto a ele por meio de algum servidor aleatório, ele funciona, enquanto eu não consigo nem fazer o ping dessa máquina da minha máquina.

Mais detalhes:

• O tcpdump na máquina vê minhas próprias tentativas de ping, mas nenhuma resposta está sendo enviada
• O SSH simplesmente expira quando isso acontece
• reiniciar a interface de rede ou reinicializar resolve o problema temporariamente
• ocorre aleatoriamente entre 1 minuto e várias horas
• todas as máquinas estão na mesma sub-rede
• todas as máquinas estão conectadas a um switch Cisco, nenhuma VLAN configurada nessa sub-rede
• verificado por roubo de IP (talvez um laptop dormindo e acordando aleatoriamente para fazer coisas), sem sucesso
• para completar a bagunça, as conexões de uma máquina RedHat6 (exatamente o mesmo hardware) nunca tiveram esse problema
• o módulo e1000e está sendo usado em todas essas máquinas (exceto para janelas com massa, é claro), atualizar para o firmware mais recente em um ou ambos os lados não ajudou
• Os cabos de rede também foram trocados - sem sucesso
• o eeprom_fix_82574_or_82583 não corrigiu esse problema, mesmo que o problema estivesse presente em algumas dessas máquinas
• instalar um Debian nessas máquinas problemáticas resolve o problema, mas não é desejado por razões de empresa ...

Então, aqui estou eu, completamente sem noção ... Alguém tem a menor idéia do que está errado aqui?

    

Answer 1

Graças ao abade, encontrei uma solução para esse problema:

Simplesmente. Desativar Iptables.

Completamente, isto é, desativando o carregamento dos módulos do kernel no momento da inicialização, bem como desativando o firewall de antemão no Yast.

Crie este arquivo e reinicie, então verifique com lsmod se o iptables ainda está carregado:

nano /etc/modprobe.d/netfilter.conf

alias ip_tables off
alias iptable off
alias iptable_nat off
alias iptable_filter off
alias x_tables off
alias nf_nat off
alias nf_conntrack_ipv4 off
alias nf_conntrack off

Depois, o problema de roteamento resolveu-se com o ponto de roteamento desnecessário no meio já removido, então agora é apenas um único salto em vez de dois desde o início.

Fonte: link

    

Answer 2

tcpdump on the machine sees my own ping attempts but no reply is being sent

No GNU / Linux, tcpdump pode ver os pacotes bloqueados pelo local iptables firewall, por isso, se você não receber nenhuma resposta, isso se deve à entrada ICMP bloqueado ou à falta de ARP entrada de fonte.

Para diagnosticar esses problemas, a -e switch de tcpdump é útil, pois imprime endereços de camada de link e, ao analisar o tráfego, também captura ARP de tráfego.

Para descartar a probabilidade de ARP (fácil), você pode adicionar entradas estáticas / permanentes ARP para ver se o problema desaparece. Se depois de adicionar entradas ARP estáticas, então provavelmente alguém está roubando ARPs ou alguma filtragem ARP está acontecendo.