web-dev-qa-db-ja.com

Linuxが誤ったインターフェースでARPに応答するのはなぜですか？

次のLinuxネットワーキング設定があります。割り当てられたアドレス10.11.0.1/24のeth10ネットワークインターフェイスがあります。次に、ダミーアドレス0.0.0.1/32が割り当てられたTap0ネットワークインターフェイスがあり（インターフェイスを起動するためにダミーアドレスを割り当てました）、そこからのトラフィックは、Tap0インターフェイスを最初に作成したユーザー空間プログラムによって制御されます。 tap0インターフェースの反対側には、ARP要求を探して応答を作成するrawソケットを介してそれを使用するユーザースペースプログラムがあります。

ここで、ユーザースペースプログラムが10.11.0.1を要求するARPリクエストを作成すると、他のrawソケットユーザースペースプログラムがそれに応答することを期待します。ただし、2つの応答が返されます。1つはrawソケットプログラムから、もう1つはLinuxカーネルからのものです。

どうやら、Linuxカーネルは10.11.0.1がそれに属するアドレスであると推定し、したがって応答します。ただし、10.11.0.1は、tap0インターフェイスのアドレスではありません。これはeth10インターフェイスのアドレスです。

私の質問は、なぜLinuxカーネルはそれをするのですか？間違ったインターフェイスでARP応答を無効にする方法はありますか？

この問題の暫定的な解決策は、10.11.0.1以外のアドレスをrawソケット/ tap0の目的で使用することです。ただし、このシステムは、任意の開発マシンで実行できるアプリケーションのシステムレベルのテストであるため、他のインターフェイスとのIPアドレスの競合がないことを保証できません。したがって、間違ったインターフェイスでARP応答を無効にすると便利です。

この問題のもう1つの解決策は、ユーザー空間アプリケーションのインターフェイス全体を予約するネットマップを使用して、ユーザー空間アプリケーションの実行中にカーネルが何かに使用できないようにすることです。しかし、私はテストをnetmapなしで実行したいと思っています。

linuxlinux-networkinglinux-kernelarp
5
juhist

ARP応答を「間違った」と呼ぶのはなぜですか？システムのIPアドレスは、そのインターフェースを介して確実に到達できます。これが、最初にARP応答が送信される理由です。そうしないと、一部のトラフィックが最適でないパスを経由して流れるか、まったく流れない可能性があります。たとえば、tap0はVPN接続である可能性があり、このARP応答は、他のIPアドレスへのトラフィックがVPNを介して正しく流れるようにするのに役立ちます。

これを本当に実行したい場合は、 sysctlsarp_ignoreおよびarp_announceを必要な値に設定できます。

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.

そしてarp_ignoreは次のように記述されます：

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}

したがって、arp_ignoreを1（または2）に設定し、arp_announceを2に設定する必要があります。

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

テストの場合、おそらくこれで問題ありません。しかし、実際の本番システムは、おそらくあなたが経験した方法で動作し、プログラムはそれを処理できる必要があります。

8
Michael Hampton