☰

Linux (4.15.0-130) と Windows (10) は ICMP を異なる方法で処理しますか?

tag-icon • tag-icon windows-10 traceroute icmp
Linux (4.15.0-130) と Windows (10) は ICMP を異なる方法で処理しますか?

不安定なネットワーク問題のある Windows 10 マシンのトラブルシューティングを試みているときに、ホストへの traceroute を実行したところ、カーネル 4.15.0-130 を搭載した Ubuntu 18.04 システムで表示される結果とは若干異なる結果が得られました。ハードウェア要因、不安定なプロトコル スタック、ドライバーの問題などを排除するために、Linux を実行している VirtualBox VM の Windows 10 とホスト システムの結果を比較しました。VirtualBox は NAT を使用してセットアップされています。つまり、Windows 10 はホストに接続し、ホストが実際のネットワーク I/O を処理します。そのため、両方のセッションは同じネットワーク アダプターを使用しており、すべてがホスト上の同じプロトコル スタックを通過します。VPN は使用されていません。クライアント マシンは、単に WiFi/3G インターネット ルーターに接続しているだけです。

私がトレースルーティングしているホストには、Linux (Firefox ウェブブラウザを使用) からはアクセスできますが、Windows 10 (Firefox を使用している他の Windows 10 マシン上、または Chrome を使用している VirtualBox 内) からはアクセスできません。

Windows (Linux 上の Virtual Box で実行) では次のようになります:

>tracert -d www.brewforafrica.co.za

Tracing route to www.brewforafrica.co.za [41.203.18.81]
over a maximum of 30 hops:

  1    <1 ms     1 ms    <1 ms  10.0.2.2
  2     3 ms     3 ms     3 ms  192.168.0.1
  3    56 ms    23 ms    36 ms  10.113.42.52
  4    83 ms    31 ms    22 ms  10.251.60.253
  5     *        *        *     Request timed out.
  6    74 ms    34 ms    29 ms  10.251.60.233
  7    88 ms    39 ms    20 ms  10.251.60.234
  8     *      103 ms    39 ms  10.113.145.33
  9    25 ms    33 ms    24 ms  196.207.35.36
 10    82 ms    32 ms    43 ms  192.168.133.110
 11    54 ms    25 ms    42 ms  41.21.235.25
 12    69 ms    80 ms    62 ms  10.118.24.61
 13   103 ms    35 ms    35 ms  196.60.9.24
 14    46 ms    45 ms    53 ms  197.189.193.1
 15    95 ms    53 ms    35 ms  41.203.18.81

Trace complete.

(注: 10.0.2.2 は VitualBox によって提供されるデフォルトのゲートウェイ アドレスです。Linux はそこからすべてのネットワークを処理するため、このホップは以下の traceroute には存在しません。) Linux を使用して同じ traceroute を繰り返すと (上記の Windows 10 を含む Virtual Box セッションを実行している同じシステム上)、次の結果が得られます。

$ traceroute -n www.brewforafrica.co.za

traceroute to www.brewforafrica.co.za (41.203.18.81), 30 hops max, 60 byte packets
 1  192.168.0.1  1.416 ms  1.580 ms  1.668 ms
 2  10.113.42.52  24.311 ms  25.119 ms  38.804 ms
 3  10.251.60.253  39.793 ms  39.875 ms  39.922 ms
 4  * * *
 5  10.251.60.233  40.122 ms  41.365 ms  51.445 ms
 6  10.251.60.234  51.910 ms  50.416 ms  50.508 ms
 7  10.113.145.33  50.836 ms  27.691 ms  27.251 ms
 8  196.207.35.36  31.254 ms  73.984 ms  63.871 ms
 9  192.168.133.110  73.479 ms  73.528 ms  62.612 ms
10  41.21.235.25  52.088 ms  61.699 ms  61.572 ms
11  10.118.24.61  62.102 ms  62.275 ms  61.833 ms
12  196.60.9.24  61.680 ms  51.679 ms  39.123 ms
13  197.189.193.1  40.032 ms  40.073 ms  43.791 ms
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
$

この違いの原因は何ですか? また、それは重要な意味を持つのでしょうか?

答え1

これは同じ traceroute ではありません。Linux はtraceroute実際には Windows のような ICMP エコーではなく、デフォルトで UDP プローブを送信します。Windowssudo traceroute --icmpに近づけるために使用します。(mtrついでに試してみてください。)

最終システムに、不明なポート1上の UDP パケットを静かに破棄するファイアウォールがある場合、応答がないということは、traceroute プログラムがパケットの行き先を知る方法がなく、プローブが最終的に最終宛先に到達したことや、TTL をどんどん大きくしてプローブし続ける必要がないことを認識する方法がないことを意味します。

1同じことは、あらゆる種類の traceroute プローブ2でも発生しますが、UDP をドロップする方が ICMP エコーをドロップするよりはるかに一般的です。(意図的にブロックする必要すらありません。一部のオペレーティング システムでは、デフォルトでブロックが実行され、UDP や TCP さえも無視され、標準では ICMP ポート到達不能が要求される場合でも何も起こりません。これらのオペレーティング システムでは、これを「ステルス モード」と呼び、何らかのセキュリティ機能であると主張しています。)

2 traceroute 専用のパケット タイプはありません。ツールは、実際のサービスに混乱を与えることなく、最終ホストからの応答を生成する可能性のあるものを送信するだけです。これには ICMP エコーだけでなく、高ポートの UDP パケットや TCP SYN も含まれます。

関連情報