奇妙な問題に遭遇しています。どなたか情報を追加していただけるとありがたいです。
テストとして、2 つの異なるサブネットを構成しました。1 つのマシン 10.10.11.9/30 (あるサブネット上) を別のマシン 10.10.11.1/30 (別のサブネット上) から ping しようとしています。ping は機能しません (当然です)。
しかし、Wireshark で同じことを検出しようとすると、「到達不能」メッセージが表示される代わりに、通常の ICMP 要求と応答が表示されます。パケットが経路を見つけているかのようです...
スクリーンショットを添付しました
pingとWireshark用
IP パケットのヘッダーチェックサムを計算しようとしましたが、それでも Wireshark でキャプチャされたパケットのチェックサムは正しいようですが、ping ではすべてのパケットが失われたことが示されます。
誰か情報を追加できますか?
どうもありがとう
答え1
設定が実際に説明どおりであると仮定すると（誤って誤って設定されているものはありません）、クライアント 10.10.11.1/30 に 10.10.11.9/30 へのルーティング方法に関する情報（デフォルト ゲートウェイ、静的ルートなど経由）がない限り、ICMP パケットは送信されません。
Cisco Paket Tracer で試してください。2 つのクライアントと、その間にある 1 つのスイッチでネットワークをセットアップします。デフォルト ゲートウェイが設定されていない限り (クライアントが異なるブロードキャスト ドメインにある限り)、クライアントは ARP パケットを送信しません。
これは、現在の構成が何らかの「ルーティング解決」を提供しているため、ICMP パケットが実際に送受信されていることを意味します。おそらく、デフォルト ゲートウェイ、静的ルートなどを介してです。レイヤー 2 をチェックして、フレームがどの MAC アドレスに設定されているかを確認します。直接クライアントに、またはルーターに設定されているか。私のコメントに書いたように:
ICMP パッケージは、ルーター、静的ルート、"proxy-arp" などの "特殊な" 構成などを介して送信される必要があります。レイヤー 2 では何が起こりますか? IP アドレスはどのようにして MAC アドレスに解決されるのでしょうか? これにより、そもそも応答がある理由 (あるはずがない) の解決方法がわかると思います。
受信したパケットが ping 統計に表示されない理由は別の問題です。ファイアウォールがブロックしている可能性があります (ping コマンドは個々の ping に関するエラーや確認を表示せず、概要のみを表示するため、そう推測します)。
私が考えられる唯一の説明は、システムを混乱させる何らかの奇妙な構成があるということです (たとえば、送信先と同じ IP アドレスを持ち、送信元としてブロードキャスト ドメイン内にある 2 番目のクライアントなど)。フレームの MAC アドレスを実際のクライアントの MAC アドレスと比較することで、レイヤー 2 でもこれをチェックできます。
結果論: デフォルト ゲートウェイ、静的ルートなどを設定しましたか? ルーターには、たとえば 24 ビットのネットワーク マスクがありますか? この場合、サブネットは異なりますが、ルーターとクライアントのブロードキャスト ドメインは重複しています。これが現在の動作を説明できます。
答え2
ネットマスクの混乱が原因で、ネットワークの状態が悪くなります。
ICMP 要求の前には、直前またはそれより前に ARP 要求が存在します。明らかに ARP 要求は成功したため、いずれかのノードが要求の場所を認識し
10.10.11.9、その MAC アドレスを返しました。そうでなければ、ICMP は送信されませんでした。PING 要求は「ネットに到達できません」(または少なくとも「ホストに到達できません」) を返すはずでしたが、そうはなりませんでした。そのため、ICMP 要求は正常に送信され、成功コードとともに返されました。
ping コマンドが依然として 100% のパケット損失を報告するのはなぜかという疑問が残ります。
おそらく別のネットワークから来たため、ping コマンド自体が応答を破棄したとしか考えられません。
私の結論は、ネットワーク上の他のノードが を使用している
10.10.11.x/24ため、ping を配信し、10.10.11.1/30ノードに大きな混乱を引き起こしているということです。