Wireshark がパケットをキャプチャしていない限り、サーバーは他のサーバーに ping できません。また、ping プロセスの前にプロセスがパケットをキャプチャしていると思います。しかし、このプロセスを見つけるにはどうすればよいでしょうか?
答え1
わかりました。この問題は自分で解決しました。実際のところ、サーバーに送信されたパケットの IP アドレスは正しいのですが、MAC アドレスが間違っています。そのため、Wiredshark がオフになっている場合、ネットワーク インターフェイス カード (NIC) はそれを直接ドロップします。ただし、Wiredshark がオンになっている場合は、パケットをキャプチャして MAC アドレスを正しいものに変更します。
答え2
Windows 7 マシン (Enterprise、SP1) から Ethernet ターゲット デバイスに ping を実行したときに、同じ問題が発生しています。私の構成には 2 つの USB2Ethernet アダプターがあり、Windows の Ethernet インターフェイスはアダプターのドライバーから取得されます。このハードウェア構成は確実に機能します (Linux から ping を実行する場合は機能します)。ただし、Windows からは機能しません。
残念ながら、あなたの回答では問題の根本が明らかになりません。ICMP 応答に間違った MAC アドレスがあるという意味であれば、問題は実際になぜ間違っているのかということです。市販のソフトウェア (OS に同梱されている標準ツール) を使用していて、手作りの ICMP 要求/応答がない場合、質問はまだ未解決です。間違った MAC アドレスの問題の根本は何か? TCP/IP スタック (ICMP 実装はその一部) は、私の知る限り、最初に ARP ブロードキャスト要求を介して MAC アドレスを検出し、次に指定された応答に基づいて宛先 MAC アドレスを選択します。
とにかく、宛先 IP の静的 ARP エントリの設定を試みましたが (Windows ピアに接続された USB2Ethernet の MAC アドレスとターゲット Ethernet インターフェイスの MAC アドレスの両方を試しました)、今のところうまくいきません。
ターゲット システム (ping されているシステム) では、ICMP 応答が実際に送信されていることがわかりますが、Windows システムはそれをフィルタリングしているようです。
Wireshark がポートをリッスンすると問題は修正され、ターゲット システムとのネットワークは完全に機能します (ICMP および他のすべてのプロトコル)。
これは、Wireshark がスニッフィング中にイーサネット インターフェイスを導入する無差別モードや、私が知らない Windows の設定やサービスと関係があると思われます。