☰

ホストと仮想マシンのARP結果が異なります。

tag-icon • tag-icon networking windows virtual-machine vmware arp
ホストと仮想マシンのARP結果が異なります。

最近では、VMWare Playerを使用してWindowsホストにLinux仮想マシンを構成しました。ネットワークアダプタをブリッジネットワークに設定し、「コピー」オプションを選択しました。 IPアドレスは物理ネットワークにありますが、このコマンドを使用すると、arp -aホストと仮想マシン間で異なる結果が生成されます。ホストはWi-Fiネットワーク上の他のホストを検索できますが、仮想マシンは検索できません。

ホストがスイッチのように動作し、ネットワーク情報をVMに転送することを知っているので、VMが実際のネットワークにアクセスできると仮定していますが、なぜそれができないのかわかりません。このブリッジされたネットワークが正確にどのように機能するのか、そして仮想マシン内で実際のネットワークを取得できるかどうかを知りたいです。

- - 編集する - -

興味深いことに、いくつかの結果は見ましたが、すべてではありませんでした。arp-scan -l

出力は次のとおりです。

  1. arp -aWindowsホストの結果
  2. arpLinux VMの結果
  3. arp-scan -l仮想マシンで

  Windowsホストでの「arp -a」の結果   Linux VMの「arp」結果   仮想マシンの「arp-scan -l」

答え1

私はあなたの家が正しいかどうか完全にはわかりません。私はブリッジされたネットワークデバイスを頻繁に使用していますが、経験上、仮想マシンの1つのネットワークトラフィックがやや孤立しています。私は使うキーボード仮想マシンしかし、私が使っているブリッジング技術はLinuxホストが提供するものなので、まったく同じではありませんが、似ているかもしれません。

あなたの使い方はarp私も混乱しています。このコマンドは、システムが最近接続したシステムとシステムARPキャッシュに保持されているIPアドレスマッピングのMACアドレスのみを表示します。このコマンドは、対応するarpキャッシュの内容を表示します。

はい

VMホスト+ゲスト1人がいます。

所有者

$ arp -a
hostX (192.168.1.226) at XX:XX:XX:XX:XX:XX [ether] on br0
hostY (192.168.1.7) at XX:XX:XX:XX:XX:XX [ether] on br0
hostZ (192.168.1.5) at XX:XX:XX:XX:XX:XX [ether] on br0
hostA (192.168.1.1) at XX:XX:XX:XX:XX:XX [ether] on br0

ゲスト

$ arp -a
hostA (192.168.1.1) at XX:XX:XX:XX:XX:XX [ether] on eth0
hostY (192.168.1.7) at XX:XX:XX:XX:XX:XX [ether] on eth0
hostB (192.168.1.100) at XX:XX:XX:XX:XX:XX [ether] on eth0
hostC (192.168.1.8) at XX:XX:XX:XX:XX:XX [ether] on eth0
hostX (192.168.1.226) at XX:XX:XX:XX:XX:XX [ether] on eth0

ブリッジはレイヤ 2 デバイスであるため、arpVM ホストの VM ゲストからデータが受信されるという証拠は見られないことが予想されます。

抜粋9.2.5。ブリッジ - Redhat Documentation

ブリッジは、MACアドレスに基づいてネットワーク間トラフィックを転送するリンクレイヤデバイスであるため、レイヤ2デバイスとも呼ばれます。各ネットワークに接続されているホストを特定し、設定されたMACアドレステーブルに基づいて転送決定を行います。ソフトウェアブリッジは、仮想化アプリケーションで1つ以上の仮想NICとNICを共有するなど、ハードウェアブリッジをエミュレートするためにLinuxホスト内で使用できます。

追加のデバッグ？

tcpdumpゲストとホストVMの両方でネットワーク分析ツールを使用します。これにより、ボトルネックが発生した場所がわかります。

$ sudo tcpdump -i eth0

-i監視したいネットワークインタフェースにパラメータを変更します。

答え2

これarp(8)このコマンドは、オペレーティングシステムのアドレス解決プロトコルで使用される変換テーブルの内容を表示します。このテーブルには、主にarp who-hasローカル要求に対するキャッシュされた応答が含まれています。

ブリッジされたネットワークを持つ仮想マシンがあるがローカルネットワーク上のホストと積極的に通信していない場合、arpテーブルは非常に小さい可能性があります。

同様に、ホストに複数のローカルネットワークがありますが、そのうちの1つだけがVMにブリッジしている場合は、実際に別のネットワークにブリッジすることはありません。そうですか？

GigEブリッジはありますがWiFiはないようです。

あるいは、WiFiを接続しましたが、アクセスポイントが新しいMACアドレスを好まない可能性があります。

答え3

攻撃の状況（arp -nLinux VMではまったく何も返さない）によると、LinuxでIPアドレスを設定するのを忘れているため、ARPエントリを取得できなかったようです。

Linuxで静的割り当てを手動で設定していますか、またはdhclientLinux VMで静的割り当てを実行していますか？ifconfig問題をさらに識別するための出力も提供されませんでした。

また、アクセスポイントがネットワーク拡張を望まない場合もあることを考慮する必要があるかもしれません。

関連情報