インターネット上の標準のパケットルーティングメカニズムはホップ単位の動作です。つまり、ネットワーク内の各ノードは、動的ルーティングプロトコルから受信し、ルート管理者によって静的に指定された情報に基づいて、パケットの送信先を決定します。
ルートは、宛先ノードと次のルーター（次ホップ）のアドレスに到達するためにパケットを送信する必要があるインターフェイスです。
R1#sh ip rou | i 40. 40.0.0.0/8 is variably subnetted, 2 subnets, 2 masks O 40.0.0.0/31 [110/3] via 20.0.0.0, 00:01:54, FastEthernet0/0 O 40.1.1.1/32 [110/4] via 20.0.0.0, 00:00:05, FastEthernet0/0
方法は？ パスは、パケットが通過した（通過する）ノードのリストです。
1 10.0.0.1 16.616 ms 16.270 ms 15.929 ms 2 20.0.0.0 15.678 ms 15.157 ms 15.071 ms 3 30.0.0.1 26.423 ms 26.081 ms 26.744 ms 4 40.0.0.0 48.979 ms 48.674 ms 48.384 ms 5 100.0.0.2 58.707 ms 58.773 ms 58.536 ms
パッケージパスは、Windows OSではtracertユーティリティを使用して、GNU / LinuxおよびUnixライクシステムではtracerouteを使用して表示できます。 （tracepathなどの他のコマンドは考慮しません）。
これらのユーティリティは同じ動作原理を持っていると多くの人が信じていますが、そうではありません。 それを理解しましょう。
だから、tracertユーティリティ。
このユーティリティは、icmpプロトコルに基づいています。 次のスキームを検討してください。
ホストは、ルーティングテーブルで指定されたルーティングテーブルでttl 1を使用してICMP Echo-Requestを送信し、Router1はそのようなパケットを受信すると、宛先アドレスをチェックします。 このパケットは別のホストに宛てられているため、Router1は自身を中継ノードと見なし、パケットのライフタイムが0になるため、パケットのttlを減らして破棄します。パケットがドロップされたため、Router1はicmpパケットのソースにドロップの理由を示すメッセージを送信します-時間超過。 このicmpメッセージを受信したtracertユーティリティは、Router1を最初のホップとして示します（アドレス情報はicmpメッセージで示されます）。 次に、要求のttl icmpが送信ノードと受信ノード間の希望の数に等しくなるまで、ttl増分でプロセスが繰り返されます。 この例では、Server1が宛先ノードです。 パケットを受信した後、彼は宛先アドレスを確認し、リクエストが自分宛であることを確認し、ICMP Echo-Replyを送信します。これはtracertユーティリティがトレースを終了するトリガーになります。
結論：
Icmpは第3レベルのプロトコルであり、ポートについては何も知りません。 したがって、ポートを指定してトレーサーを作成することはできません。 ここで理解できたと思います。
Traceroute-このユーティリティは異なる原理で動作しますが、コマンドの出力は前のものと似ています。
TracerouteはICMP Echo-Requestに基づいているのではなく、udpフラグメントの送信とポートの可用性/到達不能メッセージの受信に基づいています。 前のスキームに戻りましょう。 ホストはudpフラグメントを生成し、IPパケットにカプセル化し、ttl = 1に設定します。 中継ノードであるRouter1は、このicmpパケットに、パケットのライフタイムの終了に関するメッセージで応答します。 このメッセージを受信したtracerouteユーティリティは、icmpパケット（Router1）のソースアドレスを最初のホップのアドレスとして示します。 次に、ttlパケットの増分でプロセスが繰り返されます。 すべてがtracertとほぼ同じです。 しかし、ICMP Echo-Requestを送信していません。tracerouteは、トレースが終了したことをどのように理解していますか？ 簡単です-udpヘッダーには、送信元ポートと宛先ポートのフィールドがあります。 送信元ポートが1023を超えるポートになることは論理的です。そして、宛先ポートを指定する方法は？ 前述のように、tracerouteユーティリティの動作は、宛先ポートの到達不能または可用性に関するメッセージの受信に基づいています。 つまり、udpフラグメントをポート45000（たとえば）からポート33434に送信します（このポートはデフォルトで使用されます）。 前の場合と同様に、Server1は宛先ノードです。 パッケージを受け取った後、彼はそれを開梱し、最高レベルのプロトコルに渡す必要があります。 ただし、サーバーではポート33434がデフォルトで閉じられるため、Server1は宛先ポートが到達不能であることに関するicmpメッセージを生成します（ICMPタイプ3「宛先未到達」コード3「ポート未到達」）。 このメッセージを受信すると、tracerouteはトレースが完了したと見なします。 トレースプロセス中、宛先ポート番号は試行ごとに増加します（33434、33435など）。 宛先ポートが開いていることがあります。 この場合、サーバーは、たとえば、TCP SYNパケットがトレースに使用されている場合、ホストイニシエーターにTCP ACKを送信します。これにより、トレースの終了もトリガーされます。
結論：
tracerouteユーティリティを使用すると、宛先ポートでトレースできます。
これを行うには、以下の例を分析します。
前の図を使用してトレースを作成します。
TCP SYNパケットの使用：
bormoglots@ubuntu-server-s1:~$ sudo traceroute -T -p 22 -w 1 -n 100.0.0.2 traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets 1 10.0.0.1 16.616 ms 16.270 ms 15.929 ms 2 20.0.0.0 15.678 ms 15.157 ms 15.071 ms 3 30.0.0.1 26.423 ms 26.081 ms 26.744 ms 4 40.0.0.0 48.979 ms 48.674 ms 48.384 ms 5 100.0.0.2 58.707 ms 58.773 ms 58.536 ms
UDPパケットの使用：
bormoglots@ubuntu-server-s1:~$ sudo traceroute -U -p 22 -w 1 -n 100.0.0.2 traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets 1 10.0.0.1 7.102 ms 6.917 ms 6.680 ms 2 20.0.0.0 17.021 ms 16.838 ms 17.051 ms 3 30.0.0.1 31.035 ms 30.859 ms 30.658 ms 4 40.0.0.0 41.124 ms 40.941 ms 40.728 ms 5 100.0.0.2 51.291 ms 51.045 ms 50.720 ms
ご覧のとおり、トレースは成功しました。 指定されたホストへのパスが表示されます。
次に、Router4インターフェイスにフィルターを配置します（図を参照）。
R4#sh run int fa0/0 Building configuration... Current configuration : 121 bytes ! interface FastEthernet0/0 ip address 40.0.0.0 255.255.255.254 ip access-group deny-to-server in duplex half ! end R4#sh access-lists deny-to-server Extended IP access list deny-to-server 10 deny tcp any host 100.0.0.2 log (32 matches) 20 deny udp any host 100.0.0.2 log (29 matches) 30 permit ip any any (128 matches)
もう一度トレースしてみましょう。
bormoglots@ubuntu-server-s1:~$ sudo traceroute -T -p 22 -w 1 -n 100.0.0.2 traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets 1 10.0.0.1 4.575 ms 4.490 ms 4.367 ms 2 20.0.0.0 18.431 ms 18.359 ms 29.573 ms 3 30.0.0.1 30.579 ms 30.690 ms 30.722 ms 4 40.0.0.0 52.518 ms !X 62.977 ms !X 62.898 ms !X
bormoglots@ubuntu-server-s1:~$ sudo traceroute -U -p 22 -w 1 -n 100.0.0.2 traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets 1 10.0.0.1 5.614 ms 5.523 ms 5.689 ms 2 20.0.0.0 18.364 ms 18.629 ms 18.556 ms 3 30.0.0.1 42.289 ms 42.225 ms 42.143 ms 4 40.0.0.0 41.984 ms !X 41.898 ms !X 41.815 ms !X
トレースは最後から2番目のホップで終了し、出力に兆候が現れました！ X.なぜこれが起こったのですか？ Server1へのパケットを受信するRouter4は、受信インターフェイスの禁止ルールに該当するため、パケットをドロップし、パケットがフィルタリングされたというメッセージを開始ホストに送信します（ICMPタイプ3「到達不能」コード13-「管理上禁止された通信」）。 これは、到達不能な宛先ポートメッセージでもあります。 したがって、このようなメッセージを受信したtracerouteユーティリティは、宛先ホストに到達せずに作業を終了します。 この場合、出力では、！X（Unix）または！A（Cisco）の記号で示されているように、パケットがフィルター処理されたことを理解することが重要です。
R1#traceroute 100.0.0.2 Type escape sequence to abort. Tracing the route to 100.0.0.2 1 20.0.0.0 24 msec 24 msec 16 msec 2 30.0.0.1 16 msec 36 msec 40 msec 3 40.0.0.0 !A !A !A
注：ICMPメッセージを送信せずにパケットがドロップする可能性があります（Cisco / HuaweiのNullインターフェースに送信するか、Juniperで破棄します）。 この場合、tracerouteユーティリティで指定された最大TTLが終了するまでトレースが実行されます（デフォルトでは最大30の希望ですが、通常は15〜18の希望で十分ですが、255まで手動で設定できます）。または、管理者が中断せずに出力にアスタリスクが含まれます。
注：ホストアドレスの代わりにアスタリスクが表示されるのは、さまざまな理由が考えられるため、 ここで詳しく説明します。
実際、tracerouteユーティリティは、ICMP Echo-Requestを使用するtracertユーティリティのように機能します。 これを行うには、-Iスイッチで開始する必要があります。 上記の例では、フィルターはICMPをブロックしないため、このプロトコルを使用してトレースすると、パケットパス全体が表示されます。
bormoglots@ubuntu-server-s1:~$ sudo traceroute -I -w 1 -n 100.0.0.2 traceroute to 100.0.0.2 (100.0.0.2), 30 hops max, 60 byte packets 1 10.0.0.1 4.073 ms 3.986 ms 3.890 ms 2 20.0.0.0 19.474 ms 19.389 ms 19.294 ms 3 30.0.0.1 30.147 ms 30.276 ms 30.826 ms 4 40.0.0.0 42.316 ms 42.240 ms 42.145 ms 5 100.0.0.2 52.705 ms 52.622 ms 52.521 ms
これらのユーティリティの基本原則を理解していただければ幸いです。 Windowsシステムの一部のポートでトレースする必要がある場合は、tcptraceなどのサードパーティユーティリティを使用できます。
ご清聴ありがとうございました！