☰

パケットは返されるがトレースルートは失敗する

tag-icon • tag-icon wireshark networking
パケットは返されるがトレースルートは失敗する

traceroute から次の出力が得られます:

#traceroute -i eth1 -s 192.168.12.14 192.168.1.72

1  192.168.12.1 (192.168.12.1)  1.410 ms  2.076 ms  2.251 ms
2  * * *
3  * * *
etc..

しかし、別のターミナルでは、ターゲット ホストから正しい応答 (ポート到達不能) が到着しているのを確認できます。

9.964867 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)     
9.964879 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964886 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964904 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964923 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964927 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)

最初はファイアウォールの問題だと思いましたが、確認したところパケットはドロップされていませんでした。唯一思い浮かぶのは、これが 2 番目の NIC だということです...

最初の NIC 上の同じホストに対して traceroute を実行すると、上記と同じ Wireshark トレース (明らかにソース IP が異なる) が表示されますが、traceroute コマンドは成功します。

Wireshark が応答を確認できるのに、2 番目の NIC で traceroute が失敗する理由がわかりません。

ここでかなり基本的なことを見逃しているように思います...

答え1

Wireshark は、ネットワーク インターフェイスに到着したものを表示します。カーネルは明らかにそれらのパケットを確認していますが、何らかの理由で、それらを traceroute コマンドに配信しないことに決定しました。

カーネルがそれらのパケットを配信しないことを決定する原因として、いくつかの問題が考えられます。

  • リバース パス フィルタリングに適さない非対称ルーティングがrp_filter有効になっている可能性があります。
  • カーネルは、ICMP エラー メッセージの内容をローカル ソケットと一致させることができない場合があります。これは、パケットが切り捨てられ、そのような決定を行うのに十分な情報がないために発生する可能性があります。また、NAT 構成が壊れているために発生する可能性もあります。このため、一方向のパケットは NAT 経由でルーティングされますが、他の方向ではルーティングされません。
  • チェックサムが不正なため、カーネルがパケットをドロップする可能性があります。

rp_filterこれらのうち、 が最も可能性の高い説明であるように思われます。オペレーティング システムを指定していませんが、Linux システムの可能性があるので、次のコマンドを試してください: head /proc/sys/net/ipv4/conf/*/rp_filter。1すべてに が表示される可能性があります。これは、フィルターが有効になっていることを意味します。0パケットがドロップされているインターフェイスに対応する とallデバイス名に を書き込んでみてください。

答え2

各ボックスのルーティング テーブルの出力をここに投稿していただけますか? デフォルト ルートが無効または見つからない場合、パケットには戻りパスがありません。次の出力を投稿してください:

# IP ルートリスト

各 Linux ボックスで。

関連情報