ifcfg-eth0.200 não está respondendo às transmissões arp

Question

Eu tenho um roteador Centos fazendo um trabalho estupendo em uma configuração semelhante a esta:

• eth0 - > sem IP
• eth0.200 - > 192.168.200.1
• eth0.201 - > 192.168.201.1
• ... até
• eth0.213 - > 192.168.213.1

Eu tenho o ipv4 forwarding enable para permitir roteamento de intervalo e, em seguida:

• eth1 - > sem IP
• eth1.201 - > 10.1.29.40
• eth0.202 - > 10.1.29.48
• ... até
• eth0.213 - > 10.1.29.136

iptables faz SNAT quando qualquer uma das redes eth0 procura algo da Internet, usando o intervalo de IPs de 10.198.29.138 a 10.198.29.142 como IPs públicos. Tudo funciona muito bem. O problema é que eu preciso da interface VLAN 192.168.200.1 para residir na eth1. Quando eu o movo para ifcfg-eth1.200, vejo em uma captura de pacote que muitos clientes tentam preencher suas tabelas ARP perguntando qual endereço MAC pertence a 192.168.200.1, mas eth1.200 nunca responde! Eu vejo outro eth0.XXX respondendo a difusões ARP, mas não 200. Poderia ser uma coisa do iptables, ou algo mais?

Meus iptables são assim:

EDIT/RESOLUÇÃORESUMIDAGRANDEGRAÇASADAVIDHOUDEPORSEUCOMENTÁRIO

Eupudeexperimentarsozinhoaosolucionarumproblemadiferente,oqueocomandosysctl-wnet.ipv4.conf.eth0/202.rp_filter=0faz:

SERVER<==eth0||eth1==>MACFF:11||MACFF:22IP1.1.1.1||IP3.3.3.1

seeth0receberumasolicitaçãoARPpara3.3.3.1,SERVERnãoresponderáporpadrão.Depoisdedesabilitarofiltrodecaminhoreverso,SERVERrespondeaospedidosARPONeth0dizendo"ei, IP 3.3.3.1 está em MAC FF: 11", enquanto na realidade, está em eth1.

Então o próximo pacote chega na eth0 destinado ao MAC FF: 11 e IP 3.3.3.1, e por causa da tabela de roteamento, tudo voltando para um IP 3.3.3.x sairia da eth1, então meus pacotes estavam ficando perdido em um buraco negro, mas isso é outra história.

No meu caso, tenho algo mais parecido com isto:

          SERVER
     <==eth0||eth1==>
  MAC FF:11 || MAC FF:22

<==eth0.200 || eth1.200==>
 IP 3.3.3.1 || IP 1.1.0.1

<==eth0.201 || eth1.201==>
 IP 1.1.1.1 || IP 3.3.3.9

<==eth0.202 || eth1.202==>
 IP 1.1.2.1 || IP 3.3.3.17

<==eth0.203 || eth1.203==>
 IP 1.1.3.1 || IP 3.3.3.25

<==eth0.204 || eth1.204==>
 IP 1.1.4.1 || IP 3.3.3.33

assim por diante até eth0.213. O problema é que, como você pode ver, a rede 1.1.0.0 está na eth1, enquanto a 3.3.3.0 está na eth0, e as outras redes estão invertidas.

Espero pelo que encontrei mais tarde com o comando sysctl sugerido, que se o RPF estiver desabilitado, o SERVER responderia por último aqueles pacotes ARP solicitando o MAC 1.1.0.1 em eth1.200, mas infelizmente não serei capaz de confirmar .

Na verdade, posso confirmar que esse comando pode ser executado somente nas subinterfaces afetadas e elas aplicarão as alterações imediatamente.

    

Answer 1

O Linux foi projetado para responder a solicitações ARP em qualquer interface. Supõe-se que o host possua o endereço IP e não a interface específica. O que você está vendo é chamado ARP Flux.

Se suas interfaces existirem no mesmo Domínio de Broadcast da Camada 2, você verá isso. Você menciona que está usando VLANs, o que deve fazer com que isso não seja verdade, mas isso depende de onde a VLAN está sendo marcada (pelo SO ou switch, etc).

Você pode alterar esse comportamento no Linux usando o sysctl

arp_ignore - INTEGER

Define different modes for sending replies in response to received ARP requests that resolve local target IP addresses:

0 - (default): reply for any local target IP address, configured on any interface

1 - reply only if the target IP address is local address configured on the incoming interface

2 - reply only if the target IP address is local address configured on the incoming interface and both with the sender's IP address are part from same subnet on this interface

3 - do not reply for local addresses configured with scope host, only resolutions for global and link addresses are replied

Editar: Depois de reler sua pergunta, parece que você pode precisar desabilitar o filtro de caminho inverso em cada NIC.

sysctl -w net.ipv4.conf.eth0/102.rp_filter=0
sysctl -w net.ipv4.conf.eth0/103.rp_filter=0