web-dev-qa-db-ja.com

NOTHINGが実行されているときの着信および発信トラフィック

何も実行されていない（少なくとも私が知っていることは何もない）システム。着信トラフィックと発信トラフィックをリッスンすると、次の出力が出力されます。

192.168.1.1              => all-systems.mcast.net             0b     26b     19b
                         <=                                   0b      0b      0b
192.168.1.2              => 224.0.0.251                     128b     26b     19b
                         <=                                   0b      0b      0b

（26bまたは128bだけが表示されない場合もありますが、実際の情報が送信されているように、大きな数字にジャンプします）

これはどういう意味ですか？

192.168.1.1はゲートウェイ、私のルーターです

192.168.1.2は私、私のマシンです

しかし、all-systems.mcast.netは誰ですか？また、224.0.0.251は誰ですか？そしてもっと重要なのは、なぜパケットが送信されているのですか？

これを見つけました： https://davidsimpson.me/2015/11/16/why-is-my-machine-contacting-all-systems-mcast-net/ しかし、私はDLNAサーバーを実行していません。それで、私は誰に放送していますか？

最後の（そして重要な質問）は、192.168.1.2が何かと接触していることは理解でき、192.168.1.1が私と接触していることは理解できますが、192.168.1.1がすべてのシステムと接触しているのをなぜ見ているのか理解できません。 .mcast.netでは、マシンを監視すると、ルーターからのトラフィックが送信されていないことがどのように表示されるのでしょうか。私はそれを見ることができないはずですよね？

私が使用しているユーティリティは次のとおりです。

   iftop - display bandwidth usage on an interface by Host

ユーティリティtcptrackとnetstatは何も表示しません。したがって、唯一のもっともらしい説明は、このユーティリティがそのトラフィックの原因であるということです。

質問の更新

したがって、このマルチキャストのものは、私のシステムのカーネルと、60秒に1回の非常に基本的な質問と回答のシステムであるタイマーを備えたルーターにも統合されているようです。理由はよくわかりませんし、いい人が説明してくれた後は、そうは思いません。だから私はそれをオフにしたいと思います。出来ますか？

linuxnetworkingnetstatwiresharktraffic
2
bunden

表示されているパケットは通常のマルチキャストサービスです（プロセスはブロードキャストパケットに似ていますが、それ自体はブロードキャストではありません）。ネットワーク内の出力トラフィックも（通常）ごくわずかです。

実際には、自分で生成したトラフィックだけでなく、ネットワーク上の他のマシンによって生成されたアドレスのトラフィックも表示されます。

  • 224.0.0.1はall-systems.mcast.netです

デフォルトでは、すべての（Linux）サーバーは、ネットワークで224.0.0.1にマルチキャストすることを定期的にアナウンスし、近くのルーターにマルチキャストを話すことができるように報告します。これらのパケットは、それらを送信するLinuxカーネルである必要があります。

  • 224.0.0.251はmDNSです

224.0.0.251に関しては、サービスのアナウンスと検出のためにAvahi/zeroconfによって使用されます。

Avahiは、マルチキャストDNS/DNS-SDサービス検出用のシステムを含む、無料のゼロ構成ネットワーキング（zeroconf）実装です。

Cisco-マルチキャストの概要 を参照してください。

参照 TLDP-TCP/IP HOWTOを介したマルチキャスト

クラスDアドレス-マルチキャストアドレス/224.0.0.0-239.255.255.255

o224.0.0.1はすべてホストグループです。そのグループにpingを実行すると、ネットワーク上のすべてのマルチキャスト対応ホストが応答するはずです。すべてのマルチキャスト対応ホストは、起動時にすべてのマルチキャスト対応インターフェイスでそのグループに参加する必要があるためです。

自分に合わないパケットを見る場合は、（通常は）すべてのステーションに送信されるので、ブロードキャストとマルチキャストパケット/アナウンスを聞くことになっています。ここでは掘り下げないニュアンスがあります。私がリンクしている紹介を参照してください。

最後に、iftopはトラフィックを確認しますが、トラフィックを生成する責任はありません。

サーバーが属するマルチキャストグループも確認できます。

netstat -g

最後に、通常のユーザー/ユーザーがプログラムを実行していないということは、システムが何もしていないことを意味するわけではありません。 Linuxはマルチユーザー/マルチタスクシステムであり、バックグラウンドで多くのハウスキーピング機能が実行されています。

5
Rui F Ribeiro

マルチキャストIPトラフィックには、通常のユニキャストまたはブロードキャストトラフィックとは異なるルールがあります。マルチキャストIPアドレスが送信元アドレスとして使用されることはありません。常に宛先アドレスのみです。マルチキャストを送信しているシステムは、通常のIPアドレスを送信元アドレスとして使用します。各マルチキャストIPアドレスはマルチキャストグループを指定します：そのマルチキャストアドレスに送信されたものはすべて、そのグループに属するすべてのホストによって受信されます。 （またはそれが理論です。実際には、サブネットまたは組織を超えてマルチキャストをルーティングするための特定の調整を行わない限り、マルチキャストトラフィックはデフォルトでそれらの制限で停止する傾向があります。）

ホスト内の一部のソフトウェアがreceiveマルチキャストトラフィックを希望する場合、ホストのカーネルに「このマルチキャストIPアドレスにアドレス指定されたマルチキャストを受信したい」と通知します。次に、カーネルはそのマルチキャストIPアドレスをリッスンするマルチキャストアドレスのリストに追加し、IGMPレポートメッセージを送信します：「これらのマルチキャストIPにアドレス指定されたマルチキャストトラフィックを受信したい：」。このIGMPレポートは、それ自体がマルチキャストIPメッセージです。 Linuxでは、IGMPはカーネルレベルで処理されます。これが、IGMPに関与するプロセスがない理由です。

マルチキャスト対応ルーターは、定期的に（通常は60秒ごとに）IGMPクエリメッセージを送信します。基本的には、「このセグメントのすべてのシステムに：マルチキャストトラフィックに関心がある場合は、今すぐ報告してください」。これもマルチキャストIPメッセージであり、224.0.0.1 = all-systems.mcast.netに送信されます。これはおそらくルーターが送信しているものです。そのアドレスに付けられたDNS名が示すように、すべてのマルチキャスト対応ホストは、224.0.0.1にアドレス指定されたマルチキャストトラフィックを常にリッスンする必要があります。

マルチキャスト対応ホストは、次の2つの状況でIGMPレポートを送信することになっています。

  • 特定のマルチキャストIP宛てのトラフィックのリッスンを開始または停止する場合、または
  • iGMPクエリメッセージを受信したとき。

通常、ホストのカーネルはこれを自動的に処理します。 Linuxでは、cat /proc/net/igmpを使用して、システムが各ネットワークインターフェイスで現在リッスンしているマルチキャストIPを確認できます。残念ながら、マルチキャストIPは16進数で報告され、バイト順序は通常のIPアドレス形式とは逆になります。たとえば、224.0.0.1は「010000E0」として表示されます。 224.0.0.251は「FB0000E0」です。

マルチキャスト対応ルーターは、その一部である各ネットワークセグメントにIGMPクエリを送信し、応答として取得したIGMPレポートを追跡します。これにより、あるマルチキャストIPアドレスへのマルチキャストトラフィックをあるネットワークセグメントから別のネットワークセグメントにルーティングする必要があるかどうかを知ることができます。

例外：セグメント内にIGMPクエリがあり、送信元IPアドレスがこのルーターよりも低い場合に別の送信元がすでに存在する場合、このルーターはクエリを送信せず、代わりにリッスンします。ただし、ルーター間のマルチキャストトラフィックを調整するために、マルチキャストルーティングプロトコルを使用して他のIGMPクエリソースとの通信を試みる場合があります。

マルチキャスト対応ホストが3つの連続するIGMPクエリに応答しない場合（つまり、180秒）、ルーターは、ホストがマルチキャストトラフィックに関心がなくなったと見なします。これにより、ホストが再起動したり、電源が切れたり、ネットワーク接続が失われたりした場合に、不要なマルチキャストストリームがクリーンアップされます。

単純な家庭用Wi-Fiネットワークでは、マルチキャストの有用性は限られています。Wi-Fiネットワーク内のホストのグループは、マルチキャストを使用する場合でも、単にブロードキャストを使用する場合でも、すべての人の共有無線帯域幅を消費します。ただし、有線ネットワークまたはメッシュWi-Fiネットワークでは、マルチキャストにより、スイッチやAPがIGMPメッセージを監視できるため、特定のマルチキャストパケットを特定のスイッチポートまたはWi-Fiセルに送信する必要があるかどうかを知ることができます。そうではありません。これにより、特定のマルチキャストに関心のないユーザーの帯域幅が節約されますが、スイッチ/ APの作業が増えます。この機能は「IGMPスヌーピング」として知られています。

0
telcoM