ARP応答に間違ったMACアドレスが含まれています

Question

有線と無線のアダプターを備えたLinuxを実行するロボットを持っています。起動すると無線に接続します。有線に（静的またはDHCPを使用して）IPを割り当てると、正常に機能しているように見えます。のように、ifconfigは適切なIPを示し、routeは適切なルートを示します。ただし、有線IPのARP要求を実行すると、ARP応答にワイヤレスMACが含まれます。

???ロボットで実行されているブリッジがないので、なぜ有線MACを取得しないのですか？

ワイヤーが切断されると、ワイヤードIPはpingに応答します...

ロボットが有線のIPリクエストにワイヤレスインターフェイス経由で応答するのはなぜですか？

編集：同じIPサブネット上の有線アダプターと無線アダプターの両方。同じIPサブネット上のコンピューター（別のコンピューターで試した）からARP要求を行います。

関連ルート出力：

Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ra0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

これは非常に削減されたLinuxなので、artptables、iptables、sysctl、brctlなどのツールはありません。

編集：要求に応じた図

network diagram

編集：私はトラフィックをダンプし、ARPテーブルを調べています。 192.168.0.110のARP要求は、24：3C：20：06：3E：6Dを含むARP応答を返します。 ARP応答パケットの送信元MACも24：3C：20：06：3E：6Dです。言及したように、_filter、_ignore、および_announceをいじってみました here が、役に立ちませんでした。

編集：（どちらのインターフェースでも）ゲートウェイを設定しても、違いはありません（そうするべきではありません）。

編集：これは以前のバージョンのOS（openembeddedに基づく）では問題なく動作しました。彼らが何かを変えたことは可能ですか？

sciurus · Answer

表示されているのは、同じネットワーク上に2つのインターフェースがある場合の正常な動作です。このLWN記事で説明されています。

dev-rowbot · Answer

これは古い問題であることはわかっていますが、最近、組み込みデバイスでまったく同じ状況に遭遇しました。デバイスにはイーサネットとwifiの両方のインターフェースがあり、両方のインターフェースをいつでも同じネットワーク上でアクティブにできますが、ネットワークトラフィックは「優先」インターフェースを介してルーティングする必要があります。

ほとんどのユーザーはこのようにデバイスを構成することはありませんが、理論的には可能です。

最初に、NetgearルーターがIPアドレスの競合を報告するため、2つのMACアドレスが1つのIPを共有していたため、問題を見つけました。どうやら、このシナリオではルーターの動作が悪くなり、ユーザーのネットワークを台無しにするでしょう。

ルーター（イーサネット+ wifi）、Windowsラップトップ（イーサネットのみ）、埋め込みデバイス（イーサネット+ wifi）のみを含むプライベートネットワークを作成しました。デバイスでWireshark、tcpdump、Windowsでarpを使用すると、次の動作を確認できます。

デバイスのifconfigに、別個のwlnとイーサネットIP、および別個のMACアドレスが表示される
場合によっては（非常にまれですが）、Windowsのarp –aで正しいIP-MACの組み合わせが表示されることがあります。
ほとんどの場合、windowsからのarp –aは、wlnとeth0の両方が同じMACアドレスを持っていることを示します
Windowsからwlnまたはeth0のいずれかにpingを実行すると、ping応答はwlnから送信され、eth0から送信されることはほとんどありません。 tcpdumpは、wlnが4つのpingのうちの1つにのみ応答したことを示します（例）。
Windowsがeth0 IPのarp "who has"メッセージを送信すると、eth0とwlnの両方のインターフェイスが応答して、そのIPを持っていることを通知します

アイテム3はアイテム5が原因であると思います。wlnはeth0だけが応答するはずのarpメッセージに応答しているため、arpテーブルがめちゃくちゃになっています。項目4も項目5が原因であると思います。pingはMACアドレスに基づいて送信されます。最後に受信したarpメッセージはwlnから送信され、eth0 IPを持っていると言っているため、pingは誤ってwlnインターフェースにルーティングされます。

多くの掘り起こしとテストの後、ソリューションは実際には本当に簡単でした。この記事を参照してください- http://blog.cj2s.de/archives/29-Preventing-ARP-flux-on-Linux.html

Linuxカーネルネットワークドライバーは、既知のインターフェイスに対するarp要求が受信されると（別のインターフェイスで受信された場合でも）、arpに応答するように構成されています。

この設定は問題を解決します：

echo 1 > /proc/sys/net/ipv4/conf/wln/arp_ignore echo 1 > /proc/sys/net/ipv4/conf/eth0/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

Insyte · Answer

間違ったインターフェイスに対してARP応答を受け取ったと言うとき、実際にトラフィックをダンプしているのですか、それとも結果のARPテーブルを見ているだけですか。 bothインターフェースのARP応答を受け取っている可能性があります...

とにかく、あなたの問題に対する答えは、rp_filterとarp_filterを適切に操作することにあると思います。それぞれのドキュメントは以下に含まれています。

私は最初にこれを試すことをお勧めします：

echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter

あなたもこの変更を行う必要があります：

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

 rp_filter-BOOLEAN 1-RFC1812 で指定されているように、逆パスによるソース検証を行います。単一のホームホストとスタブネットワーク ルーターに推奨されるオプション複雑な（ループフリーではない） ネットワークが低速で信頼性の低いプロトコル（RIPの一種）を実行している、 、または静的ルートを使用している場合に問題が発生する可能性があります。ソースの検証。 インターフェイスでソースの検証を行うには、conf/all/rp_filterもTRUEに設定する必要があります デフォルト値は0 。一部のディストリビューションでは、起動スクリプトでそれを有効にします 。 arp_filter-BOOLEAN 1-同じ上に複数のネットワークインターフェイスを持つことができます サブネットを使用し、カーネルがそのインターフェースからARPされたIPからパケットをルーティングするかどうかに基づいて、各インターフェースのARPが応答されるようにします 。したがって、ソースを使用する必要があります これが機能するためのルーティングに基づく）。言い換えれば、どのカード（通常は1）がarp要求に応答するかを制御できる 。 0 デフォルト）カーネルは、アドレスでarp要求に応答できる 他のインターフェースから。これは間違っているように見えるかもしれませんが、正常に通信できる可能性が高くなるため、通常は理にかなっています。 IPアドレスは、 特定のインターフェイスではなく、Linux上の完全なホストによって所有されます。 load- バランシングのようなより複雑な設定の場合のみ、この動作は問題を引き起こします。 少なくとも1つの conf/{all、interface}/arp_filterがTRUEに設定されています。 それ以外の場合は無効になります

より完全な扱いについては、この記事を参照してください：

---（http://www.embedded-bits.co.uk/tag/rp_filter/

Jayen · Answer

これは以前のバージョンのOS（openembeddedに基づく）では問題なく機能したため、私の解決策はOSの次のバージョンを待つことでした。私の推測では、ワイヤレスカーネルモジュールにはバグがありました。

Gaumire · Answer

Insyteのコメントのフォローアップ。

名前を付けましょう：

PC1-右上
PC2-左上
PC3-左下

有線と無線の両方のメディアを介して3台のPCからロボットにアクセスできます。また、それらは同じサブネット上にあるため、有線メディアに対するarp要求がどのように通過したかは確実にはわかりません。つまり、スイッチがarp要求をブロードキャストするとき、ロボットは両方のインターフェイスで[図を参照]でそれを受信します。これにより、有線メディア上のIPのarp要求を受信しますワイヤレスメディアあまりにも多くの場合、ボックスのワイヤレスメディアの物理アドレスで応答され、そのIPが構成されています

私は過去にこの問題を抱えていました。それはあなたの問題には正確ではありませんでしたが、似ていました。デフォルトでは、Linuxは、IPが構成されているインターフェースに関係なく、arpリクエストを受信するインターフェースの物理アドレスで応答します。したがって、あなたのケースでは、PC3をロボットのeth0インターフェースに直接接続し、192.168.0.101に対してarpリクエストを実行すると、ra0の代わりにeth0インターフェースの物理アドレスが返されます。

私の展開シナリオは：

[RTR] | ------------ eth0 --- [サーバー]
| ----- switch1 | ----- eth1 ----- [サーバー]

両方のインターフェースが接続する同じスイッチです。それがあなたを助けることを願っています。

ルーターには、サーバー上の2つの異なるインターフェイス上の2つの異なるネットワーク用に、インターフェイス上にプライマリおよびセカンダリIPアドレスが設定されています。しかし、eth0のIPアドレスのeth1でarp要求を受信すると、eth1の物理アドレスで応答しました

それを防ぐために、これまでのところ私にとってはうまくいきました

# echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce # echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore # echo 2 > /proc/sys/net/ipv4/conf/ra0/arp_announce # echo 1 > /proc/sys/net/ipv4/conf/ra0/arp_ignore

ロボットのどこかに配置して、起動時に適用できるようにします。

推奨事項：2つの異なるサブネットを構成することをお勧めします（たとえば、ra0で192.168.1.x/24とeth0で192.168.2.x/24）。PCでIPエイリアスを使用できます。 2つのIPの。同じホスト上の同じサブネットに2つの送信パスを設定することはできません。ロボットが他のロボットよりも優先するものがない限り、そうではありません。ロボットは、1つのパスのみを通過してパケットを送信できます。

いくつかの読み：---（arp_announce 、 arp_ignore