☰

2つのNICを集約するマシンによる「合法的な」ARPポイズニングによりクラッシュ

tag-icon • tag-icon networking ip arp
2つのNICを集約するマシンによる「合法的な」ARPポイズニングによりクラッシュ

奇妙なことが起こっており、脅迫も行われており、私たちはこの問題を解決する必要があります。

状況：

私たちのデバイス (ネットワーク カメラ) は、ネットワーク経由でビデオをレコーダー/サーバー (Live555 / WIS Streamer を使用) にストリーミングします。ビデオは UDP パケットです。

特定のサーバーを使用する特定のサイトでは、ビデオの送信中に Live555 ストリーマーの 1 つのスレッドがときどき (約 24 時間) 停止します。他のスレッドは継続しており、カメラへの IP 経由の接続は維持されています (カメラから Web ページを表示したり、PING を実行したりできます)。

私たちは疑っている: サーバー。2 つのネットワーク ポートがあり、それらを集約します。MAC は 2 つありますが、IP アドレスは 1 つです。これを Wireshark で調べると、カメラが 1 つのポート (A と呼ぶことにします) にストリーミングしているのがわかります。次に、もう 1 つのポート (B と呼ぶことにします) から ARP を取得します。デバイスは MAC A へのパケットの送信を停止し、MAC B への 1 つのパケットをワイヤ上に送信して、その後停止したように見えます。

さらに詳しい情報: サーバーは、おそらく誤った構成などの結果として、「間違った」ポートからの ARP パケットを破損しているようですが、それらのパケットはデバイスによって読み取られ、処理されます。これは、ドライバーまたはカーネル ネットワークが誤って構成されているか、CPU サイクルを節約するためにチェックサムをスキップしていることが原因である可能性があります。

この厄介な状況から、いくつかの疑問が生じます。

  1. パケット チェックサムをチェックしたり、チェックを有効にしたりするには、カーネル ネットワーク コードのどこを確認すればよいでしょうか。当社のハードウェアは組み込みデバイスであるため固定されており、ドライバーを微調整することは決して悪い考えではありません。
  2. send()ポート上で継続的にデータを送信し、その下で ARP テーブルが移動するときにプロセスがロックアップする原因となる障害メカニズムを推測できる人はいますか?

追加編集: ARP は実際には破損しておらず、Wireshark がパケットを正しく識別していないだけではないかと考えています (パケットが十分に長いため FSC ワードが存在するはずだと考えていますが、現在はゼロ パディングだけであると考えています)。これで、この質問のパート 2 が残ります。ARP テーブルの変更によって送信プロセスが停止するのを防ぐにはどうすればよいのでしょうか。

さらに追加するには編集します:ポート状態やプロセス状態に関する質問を無視していると思われたくありません。この問題はめったに発生しません (平均して 24 時間に 1 回程度)。また、簡単にアクセスできない 1 つの (リモート) インストールでのみ発生します。ラボで再現してより詳細な診断を行えるように努力していますが、システム ウォッチドッグは問題が発生してから約 3 分以内にリセットされるため、ニュースが届く頃にはすでに再起動して正常に動作し始めています。

Wireshark 情報を追加するために編集します: ここで Wireshark のキャプチャを要約する最良の方法はわかりません (キャプチャしたパケットを約 1 TB アップロードするのは非常に困難です) が、試してみます。Cam:X&Cam:Yは、異なるポートから Live555 WIS Streamer の 2 つの同一インスタンスによってストリーミングされる RTSP ビデオの 2 つのストリームです。サーバー 'A' と 'B' は、サーバー上の 2 つの NIC の MAC です。

パケットのシーケンスは次のようになります。

UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
UDP Packet from Cam:X -> Server 'A'
UDP Packet from Cam:Y -> Server 'A'
ARP Packet to Cam from Server 'B' "<my IP> is now on 'B'"
Intel ANS Probe broadcast from Server 'B', Sender ID '1' team ID 'B'
Intel ANS Probe broadcast from Server 'A', Sender ID '2' team ID 'B'
<silence> from Cam:X
UDP Packet from Cam:Y -> Server 'B'
UDP Packet from Cam:Y -> Server 'B'
UDP Packet from Cam:Y -> Server 'B'

この時点では、ストリーム内に他のパケットはありません。Intel ANS パケットは NIC からの ARP と常に一致するわけではありませんが、完全性のために含めておくことにしました。

この問題はタイミングに非常に敏感なようです。サーバーから定期的にこれらの「チーム」ARP を受信しますが、問題が発生するのはごくまれです。ネットワーク スタック コードに ARP テーブルの変更に敏感な特定のポイントがあるかのようです。ダウンするのは常に同じストリーム インスタンスではなく、他のインスタンス (および他のすべてのネット トラフィック (HTTP など)) は引き続き正常に動作します。

チーム化された NIC は、セッション中にこのような ARP を実行すべきではないようですが、もちろん、トラフィックがすべて UDP である場合は、どのセッションも認識しません。

答え1

まあ、少しだけ与えるだけでも閉鎖これに対して、顧客は問題のあるネットワーク カードを再設定し、すべてが機能しました。そのため、好奇心旺盛な人にとっては残念なことに、このケースを解決するために何ができたかを詳しく調べるために誰かにお金を払う人はいないということです。

関連情報