Por que o Linux responde ao ARP em interfaces incorretas?

4

Eu tenho a seguinte configuração de rede Linux: há uma interface de rede eth10 com o endereço atribuído 10.11.0.1/24. Em seguida, há uma interface de rede tap0 com endereço fictício atribuído 0.0.0.1/32 (atribuí um endereço fictício para ativar a interface) e o tráfego de / para isso é controlado por um programa de espaço do usuário que criou originalmente a interface tap0. Do outro lado da interface tap0, existe um programa userspace usando-o via sockets raw que procura por requisições ARP e constrói uma resposta.

Agora, quando o programa userspace constrói uma requisição ARP solicitando 10.11.0.1, eu espero que o outro programa de espaço de usuário de soquete bruto responda a ele. No entanto, recebo duas respostas: uma do programa de soquete bruto e outra vinda do kernel Linux.

Aparentemente, o kernel do Linux deduz que 10.11.0.1 é um endereço pertencente a ele e, portanto, responde. No entanto, 10.11.0.1 não é um endereço da interface tap0. É um endereço da interface eth10.

Minha pergunta é: por que o kernel do Linux faz isso? Existe alguma maneira de desativar as respostas do ARP na interface errada?

Minha solução provisória para este problema é usar outro endereço que não o 10.11.0.1 para os propósitos raw socket / tap0. Mas, como esse sistema deve ser um teste em nível de sistema para um aplicativo que pode ser executado em qualquer máquina de desenvolvimento, não posso garantir que não haja conflitos de endereços IP com outras interfaces. Assim, seria bom desabilitar as respostas do ARP na interface errada.

Outra solução para esse problema é usar o netmap que reserva toda a interface para o aplicativo userspace, evitando que o kernel o use para qualquer coisa enquanto o aplicativo userspace estiver em execução. Mas gostaria que meus testes fossem executados sem o netmap.

    
por juhist 23.02.2017 / 17:23

1 resposta

6

Por que você chama a resposta ARP de "errado"? O endereço IP do sistema pode certamente ser alcançado através dessa interface. É por isso que a resposta ARP é enviada para começar. Não fazer isso pode fazer com que algum tráfego flua por meio de caminhos menos ideais ou de forma alguma. Por exemplo, tap0 pode ser uma conexão VPN e essa resposta ARP ajuda a garantir que o tráfego para o outro endereço IP flua corretamente por meio da VPN.

Se você realmente quiser fazer isso, defina os sysctls arp_ignore e arp_announce para valores desejados.

arp_announce - INTEGER
  Define different restriction levels for announcing the local
  source IP address from IP packets in ARP requests sent on
  interface:
  0 - (default) Use any local address, configured on any interface
  1 - Try to avoid local addresses that are not in the target's
  subnet for this interface. This mode is useful when target
  hosts reachable via this interface require the source IP
  address in ARP requests to be part of their logical network
  configured on the receiving interface. When we generate the
  request we will check all our subnets that include the
  target IP and will preserve the source address if it is from
  such subnet. If there is no such subnet we select source
  address according to the rules for level 2.
  2 - Always use the best local address for this target.
  In this mode we ignore the source address in the IP packet
  and try to select local address that we prefer for talks with
  the target host. Such local address is selected by looking
  for primary IP addresses on all our subnets on the outgoing
  interface that include the target IP address. If no suitable
  local address is found we select the first local address
  we have on the outgoing interface or on all other interfaces,
  with the hope we will receive reply for our request and
  even sometimes no matter the source IP address we announce.

  The max value from conf/{all,interface}/arp_announce is used.

  Increasing the restriction level gives more chance for
  receiving answer from the resolved target while decreasing
  the level announces more valid sender's information.

E arp_ignore é descrito como:

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
  4-7 - reserved
  8 - do not reply for all local addresses

  The max value from conf/{all,interface}/arp_ignore is used
  when ARP request is received on the {interface}

Então, você desejaria definir arp_ignore para 1 (ou possivelmente 2) e arp_announce para 2.

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

Para testes, provavelmente é bom fazer isso. Mas um sistema de produção real provavelmente se comportará da maneira que você experimentou, e seu programa precisa ser capaz de lidar com isso.

    
por 23.02.2017 / 17:51