Solicitação ARP sendo enviada para uma sub-rede diferente do Ubuntu Linux

Question

Esta questão é muito semelhante a esta:

O Linux está enviando solicitações ARP para hosts em outros sub-redes?

Principal problema - O servidor Ubuntu Linux está enviando solicitações ARP solicitando um endereço MAC de um host em uma sub-rede diferente.

Um roteador tem quatro redes de Classe C diferentes conectadas fisicamente. Nenhuma VLAN ou qualquer outra separação.

O roteador tem um endereço IP em cada uma das quatro sub-redes da Classe C. Isso é o que permite o roteamento entre as quatro sub-redes.

O servidor Ubuntu Linux tem o endereço IP x.x.250.2.

Quando um ping é feito para uma das diferentes sub-redes (x.x.249.x), algumas solicitações são bem-sucedidas e outras não. Para aqueles que não o são, o Wireshark (pacote sniffer em execução no servidor Ubuntu Linux) mostra que está enviando pacotes ARP ("Who has IP x.x.249.x?")

Por que isso está ocorrendo? Nenhum pacote ARP deve ser enviado do servidor destinado a algo que não esteja em sua mesma sub-rede.

A configuração de rede no servidor é x.x.250.2. A máscara de sub-rede é 255.255.255.0. O gateway é x.x.250.1. Definir estaticamente.

A tabela de roteamento não foi modificada e é apenas o padrão para isso:

    Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         x.x.250.1   0.0.0.0         UG    0      0        0 eth0
x.x.250.0   0.0.0.0         255.255.255.0 U     0      0        0 eth0

O cache de arp no servidor Linux mostra muitos endereços MAC para sistemas na rede x.x.249.xe também na x.x.250.x. Mais uma vez, isso não deveria estar acontecendo.

Agora - Um computador com Windows XP foi usado para fins de teste. Coloque na mesma sub-rede que o servidor Linux. Ele pode pingar esses endereços na sub-rede x.x.249.x que o servidor Linux não pode.

Deve haver algum tipo de bug potencial na pilha TCP do Ubuntu / Linux. O envio de pacotes ARP para outras redes / sub-redes não deve estar acontecendo.

    

Answer 1

Isso foi resolvido.

O Linux obviamente não joga exatamente pelas regras regulares da pilha TCP como as máquinas Windows.

Eu reiniciei o servidor Linux. Fiz um ping para um endereço IP que era problemático (x.x.249.76).

Um redirecionamento ICMP foi recebido do roteador (xx250.1) dizendo "Ei, você pode falar diretamente com xx249.76 e não precisa passar por mim). Imediatamente, uma vez recebida, as respostas do ping expiraram e saia.

O roteador é um roteador MicroTik e aposto que também é baseado no Linux.

Como essas quatro sub-redes estavam todas no mesmo roteador, o dispositivo MikroTik THOUGHT não precisava retransmitir as mensagens. Errado.

A solução foi atualizar o arquivo /etc/sysctl.d/10-network-security.conf e essas linhas foram adicionadas:

net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

Isso disse ao meu servidor Linux para ignorar completamente quaisquer redirecionamentos ICMP.

O servidor foi reiniciado. Iniciando o ping x.x.249.76 e os avisos de redirecionamento ainda foram recebidos, mas foram ignorados e o servidor continuou a executar o ping com sucesso no endereço IP.