sTcpTraceRoute Manual

# はじめに

Windows上で、TCP/UDP/ICMP なTracerouteを行うツールを作った。
そのマニュアル

元々、TcpTraceroute だけで満足する予定だったので、名称が「s<b>Tcp</b>TraceRoute.exe」だけど、気にしないでくれ。

# まとめ

## TCP で Traceroute したい

> sTcpTraceRoute.exe www.example.com 80 -Auto -DetectNoRoute -Strictly -Timeout 5000

## DNSサーバに対して UDP Traceroute したい

> sTcpTraceRoute.exe dns.example.com 53 -Auto -DetectNoRoute -Strictly -Timeout 5000 -UDP -DataFile dns.dat

## DNSサーバに対して、ソースポート固定で UDP Traceroute したい

> sTcpTraceRoute.exe dns.example.com 53 -Auto -DetectNoRoute -Strictly -Timeout 5000 -UDP -DataFile dns.dat -SourcePort 53

# 動作環境

C#/.NETFramework と RawSocket で作ったので、[winpcap](https://www.winpcap.org/) はいらない。

動作環境は .NET Framework 4 Client Profile &amp; UACな管理権限

# ダウンロードとインストール

[free158.html](http://rocketeer.dip.jp/sanaki/free/free158.htm)からsTcpTraceRoute.lzhをダウンロードして、lzh を解凍すればいい。それでおしまい

# usage

引数なしで実行する

# まずは TCP で Traceroute

対象をwww.yahoo.co.jpとすると、

> sTcpTraceRoute.exe www.yahoo.co.jp

で、80/tcp に対して TCP Traceroute を行う

> sTcpTraceRoute.exe www.yahoo.co.jp 443

で、443/tcp に対して TCP Traceroute を行う

# TTL の範囲

オプション「-MaxTTL」と「-MinTTL」で、TTL の範囲(開始と終了)を指定する事ができる。

# タイムアウトとインターバル

送信後に、パケットの受信までの時間を「-Timeout ≪ミリ秒≫」で指定できる

TTL=n と TTL=n+1 の実行間隔を「-Interval ≪ミリ秒≫」で指定できる

# 自分のネットワークインターフェイス

既定では、自分のネットワークインターフェイス一覧から最初の NIC にバインドしている自分のIPアドレス上で、プロミスキャスモードとなって ICMP TTL Exceed 監視をする
これは、複数 NIC のある Windows では応答パケットを適切に受信できない場合があるということを意味している

「-RecieveIPAddr」オプションで、応答パケットの受信監視するインターフェイス(NIC)を明示することができる。

また、
「-Auto」オプションでは、送信先IPアドレスから、自分の送信元IPアドレスを調べて、それにバインド(プロミスキャスモードで監視)することもできる。

# 厳密モード

既定は、とにかく ICMP TTL Exceed パケットを受信すれば、それでヨシということにしている。

- 「-Strictly」オプションでは、受信パケット(主に ICMP TTL Exceed パケット)から、原因となった「送信先アドレス」「プロトコル番号」から、自分宛の ICMP TTL Exceed なのか判定する。
- TCP/UDP Traceroute の場合は、「送信先ポート番号」もチェックする。
- TCP/UDP Traceroute の場合で、送信元ポート番号を固定した場合は、「送信元ポート番号」もチェックする
- ICMP Echo Request での Traceroue の場合は、送信データもチェックする
- ソースルーティングの際には、「送信先アドレス」は対象から外す
- ICMP Traceroute の場合、「Type=3,4,5,11,12」の時のみ「送信先アドレス」をチェックする

# その他の ICMP エラー通知

既定では、ICMP TTL Exceed 以外のエラー通知(ルーティングできないなど)は無視している

「-DetectNoRoute」オプションで、ICMP TTL Exceed 以外のエラーを受信すると、traceroute 処理を中断するようにした。

# UDP で Traceroute

対象を 8.8.8.8 とすると、

> sTcpTraceRoute.exe 8.8.8.8 -udp

で、80/udp に対して UDP Traceroute を行う

> sTcpTraceRoute.exe 8.8.8.8 53 -udp

で、53/udp に対して UDP Traceroute を行う

# 送信元ポートの固定

既定では送信元ポートは動的だが「-SourcePort」オプションで固定にする事できる。

私の記憶が確かなら、UNIXに同梱しているTraceroute の UDP 版は、ソースポートを指定できるオプションがあるが、データグラムを送信する度に、ソースポートがインクリメントされていくので、厳密の意味ではソースポートの固定ではないと思う。

sTcpTraceRoute.exe は「-SourcePort」オプションで送信元ポートを固定すると、スキャン(Traceroue)の最初から最後まで、ソースポートを固定したままスキャンする

# UDP/ICMP で送信するデータ

既定は「abcdefghijklmnopqrstuvwxyz」

以下のオプションで、送信データ(ペイロード)を明示する事もできる

- 「-DataFile ≪ファイル≫」
- 「-Data ≪文字列≫」
- 「-DataHex ≪16進数の文字列≫」

文字列の文字コードは、OS標準の文字コード(System.Encoding.Default オブジェクト)。

同梱の dns.dat は「www.yahoo.co.jp」を名前検索するDNSパケットのサンプル。

よって、

> sTcpTraceRoute.exe 8.8.8.8 53 -udp -DataFile dns.dat

で、DNS 問い合わせしながら UDP Traceroute することができる。
ターゲットに到着したら DNS パケットが返信される事で、Traceroute の終了判定ができる

その他に、

- IPMessenger のサンプル「ipmsg.dat」
- NTP のサンプル「ntp.dat」
- SNMP のサンプル「snmp.dat」
- TFTP のサンプル「tftp.dat」

を用意したけど、個々に自前で用意すればいいと思う。

# ICMP で Traceroute

対象を 8.8.8.8 とすると、

> sTcpTraceRoute.exe 8.8.8.8 -icmp

で、ICMP Traceroute を行う

既定は ICMP Echo Request と ICMP Echo Reply を使う

> sTcpTraceRoute.exe 8.8.8.8 -cicmp 13,0->14,0

とすると、ICMP タイムスタンプ要求(Type,Code=13,0)とICMP タイムスタンプ応答(Type,Code=14,0)の応答を待つ Traceroute をおこなう

よって、以下は同じ意味

> sTcpTraceRoute.exe 8.8.8.8 -cicmp 8,0->0,0
> sTcpTraceRoute.exe 8.8.8.8 -icmp

受信監視側で ICMP Code を任意のしたい場合は、指定しないでもよい。

> sTcpTraceRoute.exe 8.8.8.8 -cicmp 13,0->14

だと、送信は(Type,Code=13,0)で受信は(Type,Code=14,任意)となる。

# ICMPid とシーケンス番号

ICMP Traceroute の既定は、ICMP Echo Request なのだが、
既定の ICMP ID(ICMPヘッダの 5-6バイト目)は「0x0001」で、シーケンス番号(ICMPヘッダの 7-8バイト目)は固定で「0x0000」

- 「-ICMPid」で ICMP ID(5-6バイト目) を指定する事ができる
- 「-ICMPSeqInc」でデータグラムを送信する度にシーケンス番号(7-8バイト目)をインクリメントする

# ICMP ヘッダサイズ

ICMP Traceroute の際、ICMP ヘッダサイズは既定は、8バイト

「-IsICMPMinHeader」オプションで、ヘッダサイズを4バイトにすることができる。

「-IsICMPMinHeader」オプションと、「-DataXXXX」オプションをうまく使えば、8バイトヘッダな ICMP データグラムのICMPヘッダの 5-8バイト目を指定したスキャンも可能となるだろう

# IPv4 拡張ヘッダ

## レコードルートオプション

「-RecordRoute」オプションで、レコードルートすることができる

IPv4の制約上、記録できるルートは、9個です。

通常のTracerouteは、こちら側のインターフェイスだけど、レコードルートではあたら側のインターフェイスのアドレスが見えるのが、Tracerouteとの違いですよ。

![RecordRoute.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/182822/d5649ac4-b5cd-5d90-672e-b5606c5207d3.png)

## ソースルーティングオプション

- 「-SSR」でストリクトソースルーティングが指定できる
- 「-LSR」でルーズソースルーティングが指定できる

![SourceRouting.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/182822/92bab558-ac82-394d-38ff-75af301e6277.png)

詳細は「[詳解TCP/IP](https://www.amazon.co.jp/dp/4894713209)」

IPv4の制約上、指定できるルートは、9個です。

## RFC1393 Traceroute拡張オプション

「-TR」で、[RFC1393 Traceroute拡張](https://tools.ietf.org/html/rfc1393)で、Traceroute するけど、未テスト

![Traceroute1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/182822/02526bf6-d6c9-e710-c41d-af27ba4e27ab.png)

通常のTracerouteは、送信パケットごとに経路が動的に変化する場合、適切な経路情報を入手しているとは言えなくなってしまう。
RFC1393 の Traceroute拡張は、送信パケット一つで、各ルータが返信する事で、動的な経路でも適切な経路情報を入手することができる。

![Traceroute.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/182822/76ed2cf3-e632-5e42-1343-1a7d0d22cd8a.png)

# IPv6

今のところ、未対応。

# その他

[Windows の traceroute の注意点](https://qiita.com/tomoki0sanaki/items/9d9744ca7e1dc2a2d5fe)

# 2019/11/20

なんか、開発環境の Windows10 をアップデートしたら使えなくなった(RawSocket部が無反応)...(>_<)

# 2020/03/27

変化があった・・・
開発環境では動作するけど、運用環境では動作しない・・・なぜ!?
時間ができたらまた調べてみる・・・

# 2020/04/03

変化があった・・・
運用環境では動作しない条件は TcpTracerouteだけ? ICMPTraceroute は動作する・・・なぜ!?
時間ができたらまた調べてみる・・・

# 以上