Por que só consigo me conectar ao meu servidor ao gerar tráfego dele?

Question

UPDATE - Devido às alterações de infraestrutura da aquisição, houve um conflito de endereços IP. Depois que isso foi identificado, o comportamento foi interrompido, pois o tráfego poderia ser roteado de maneira consistente para o local correto. Obrigado a todos pela vossa ajuda.

Eu tenho um servidor final Virtualizado Centos 6.2. A intenção da máquina é executar o Jenkins no Tomcat para compilações automatizadas. Como minha empresa foi adquirida, a infraestrutura de rede mudou e algumas configurações também foram alteradas. Eu posso entrar na história mais se necessário, mas por enquanto, vou me concentrar nos meus sintomas reais.

1. A máquina, se tentada interagir com a rede por ssh ou http, não responde normalmente.
2. A máquina, se conectada diretamente, irá interagir com as máquinas. No entanto, parece demorar um pouco para finalmente começar a conversar. Ou seja, quando executo um traceroute da vm para minha máquina local, são necessárias algumas iterações. O mesmo acontece com o ping - pode levar até 6 iterações antes que os pacotes comecem a passar.
3. Quando a máquina estiver conversando com outras máquinas, o contato externo é alcançável. Eu posso ssh para ele, e o aplicativo Jenkins responderá por http.
4. A comunicação acabará, entretanto, e retornará ao primeiro estado inicial, onde o contato externo não é possível, até que eu interaja diretamente com a máquina para fazer com que ela se comunique com o mundo externo (2).

Eu tenho um pouco de perda para entender o que procurar a partir de uma perspectiva de diagnóstico. Como eu disse anteriormente, havia alguma história aqui. A máquina originalmente tinha um adaptador de rede com um endereço IP atribuído via DHCP. Em seguida, um adaptador de rede adicional foi adicionado e o endereço IP foi atribuído estaticamente. Agora há apenas um adaptador de rede com o endereço IP atribuído estaticamente.

Eu procurei outros tópicos na Internet que falam sobre vários comandos que podem ajudar a diagnosticar, mas não sei como lê-los.

Eu imagino que isso não é informação suficiente para fazer um diagnóstico (mas ficaria grato se fosse!), então eu apreciarei mais materiais de leitura, passos a serem dados, ou esclarecendo questões.

Muito obrigado pelo seu tempo.

    

Answer 1

Uma possibilidade além do simples preenchimento de tabela MAC é uma colisão ARP gratuita.

O caso em que estou pensando exige duas coisas:

1. Uma má máscara de rede, provavelmente na caixa do Jenkins.
2. Um de:
   1. Mais de um dispositivo configurado para ARP gratuito na sub-rede da caixa Jenkins, um dos quais é stateful (talvez um firewall ou um balanceador de carga).
   2. O dispositivo configurado para G-ARP não é o dispositivo que você espera que seja o gateway padrão.

Como o ARP supostamente deve funcionar

No estado inicial quando a caixa Jenkins não foi interagida e todas as várias tabelas router / switch / arp estão vazias, se a sua caixa Jenkins configurada incorretamente tentar acessar um host, ela considera local devido à má máscara de rede. mas na verdade é remoto, o dispositivo configurado para o Gratuitous ARP vai mentir para ele e diz que é o endereço IP em questão e o encaminha silenciosamente para onde ele precisa ir.

Caso de vários dispositivos G-ARP

Neste caso, existem dois dispositivos enviando pacotes G-ARP. O modo de falha aqui é:

1. O Jenkins envia uma solicitação ARP para um endereço fora da sub-rede.
2. O primeiro dispositivo G-ARP responde que tem esse endereço.
3. Jenkins envia o pacote SYN para o dispositivo remoto.
4. O dispositivo remoto confirma a conexão e é recebido por Jenkins.
5. Antes da emissão do SYN-ACK, o 2º dispositivo G-ARP também envia uma resposta ARP indicando que possui esse endereço. Jenkins atualiza obedientemente sua tabela ARP local.
6. O pacote SYN-ACK passa pelo 2º dispositivo G-ARP. Infelizmente, uma vez que nunca viu o pacote SYN inicial, ele não está ciente da conexão, então a solta no chão.
7. A conexão nunca é aberta.

Isso é visível em ambos os hosts, observando os estados do soquete em netstat . E bem visível se você pegar pacotes na caixa do Jenkins.

Conexões PARA isso funcionar porque elas estão vindo através do 2º dispositivo G-ARP, e assim atualizando a tabela ARP do Jenkins com o dispositivo 'direito' para passar os pacotes. Enquanto essa conexão estiver ativa e passando tráfego, o tráfego de saída seguirá o caminho certo.

O dispositivo errado responde ao G-ARP

Esta é uma variação do acima. Apenas um dispositivo está configurado para o G-ARP, mas não é o correto. O G-ARP é quase definitivamente uma configuração ruim.

1. O Jenkins envia uma solicitação ARP para um endereço fora da sub-rede.
2. O dispositivo G-ARP responde que tem esses endereços.
3. Jenkins envia o pacote SYN para esse dispositivo.
4. O dispositivo não é, na verdade, um roteador ou não está configurado para transmitir pacotes como esse, então o coloca no chão.

Como no caso acima, quando você estabelece uma conexão, ela configura a tabela ARP para transmitir as coisas da maneira correta, desde que a conexão esteja ativa.

A correção mais fácil é verificar se a sua máscara de rede na caixa está correta para a sub-rede, pois ela ignora todo o problema do G-ARP.

A outra possibilidade é que há algo estranho com o gateway padrão que você configurou. Se é o que todo o resto é, você deveria estar vendo o mesmo comportamento para qualquer coisa usando aquele gateway; Se esse for o caso, verifique se o mesmo problema não acontece com outras VMs no mesmo host.

    

Answer 2

Revise a configuração de seus switches.

É um palpite, mas parece-me que seus switches são atingidos com muito tráfego, preenchendo suas tabelas MAC e fazendo-os esquecer o endereço MAC / porta do seu servidor.

Combinado com o STP, pode levar até 30 segundos para que seu tráfego passe pelo mudar novamente.