Windows 或 Linux 等操作系統上，有一個非常有用的工具，稱為traceroute命令（在 Windows 上，等效命令稱為tracert）。此命令行工具使系統管理員或網絡工程師能夠解決常見的網絡問題。
每當用戶抱怨與網站或服務器的連接速度很慢時，管理員都會使用跟蹤路由來探測瓶頸。此外，如果服務器無法訪問，則使用 traceroute 命令，因為它會顯示網絡路由的哪個特定部分有問題。
Traceroute 是如何工作的？
traceroute 命令通過將網絡數據包發送到目標主機來工作。每個主持人還將顯示他們的響應時間。
通過分析路由，網絡工程師可以確定路由是否最優。響應時間為查明哪些躍點存在延遲問題提供了重要線索。
要獲得通常的 traceroute 結果以及國家、地區、城市等地理定位結果，系統管理員可以使用 Python IP2Trace 工具。下面是 IP2Trace 帶來的功能的簡單演示。
安裝 Python IP2Trace
讓我們開始演示。首先，您需要安裝一些先決條件。注意：以下安裝步驟適用于 Debian 11 Linux 操作系統，因為那是我們的演示機器。
其次，要安裝Python和 IP2Trace，請運行以下命令：
Python
sudo apt update
sudo apt install python3 python3 - pip
sudo pip install IP2Trace
之后，下載 IP2Location BIN 數據庫文件。您可以獲取IP2Location LITE 數據庫并免費下載。
下載包含 BIN 的壓縮文件后，提取 BIN 文件并將其存儲在我們推薦的文件夾/usr/share/ip2location中。如果文件夾不存在，只需創建它。
使用 DB25 的 IP2Trace 使用的簡單演示
使用 IP2Trace 命令非常簡單。下面我們將從我們的 DB25.BIN 文件（默認文件夾是上面推薦的文件夾）中查詢 IP 地址 8.8.8.8的基本地理位置數據。
Python
1
Sudo ip2tracepy 8.8.8.8 -d DB25。_ 垃圾桶
看下面的結果：
IP2Trace 命令的演示結果
* 默認情況下，IP2Trace 在數據可用時返回國家代碼、地區和城市。
每條線路都是一個主機或沿到最終目標服務器的路由的躍點。注意IP地址后面的3個數字。這些是發出的 3 個數據包中每個數據包的響應時間。
由于我們使用的是 DB25 數據庫，讓我們修改上面的命令以從 BIN 文件中輸出更多字段。我們要顯示國家代碼、國家名稱、地區名稱、城市名稱、ISP 名稱、網絡速度和使用類型。分析這些數據有助于進一步深入了解問題的根本原因。
Python
Sudo ip2tracepy 8.8.8.8 -d DB25。_ BIN - o country_code country_name region_name city_name isp net_speed usage_type
看下面的結果：
修改后的 IP2Trace 命令的演示結果
發現IP2Location Traceroute Application中的命令支持的各種選項。您也可以使用以下命令。
Python
sudo ip2tracepy - h
優點
IP2Trace通過添加地理位置信息改進了現有的 traceroute 命令。
地理位置數據可以更輕松地解決網絡問題。
與 C IP2Trace 相比，安裝 Python IP2Trace 更容易。
缺點
需要安裝 Python 才能運行。
必須有在控制臺中運行命令的經驗。
需要定期更新 BIN 文件以保持地理位置的準確性。
結論
Traceroute 是網絡和系統管理員常用的命令行工具。例如，系統管理員使用跟蹤路由來監控互聯網連接。它有助于可視化路徑流量，包括丟包和高延遲。
Traceroute 就像ping命令一樣，可以幫助我們排查網絡故障，但ping 有時候會有局限性，例如下面192.168.1.1 ping 不通192.168.3.1，但我們不知道問題是否在 H1-R1、R1-R2、R2-R3 或 R3-S1 之間。假設你知道有多少臺路由器以及每臺設備的IP 地址，那么你可以逐跳去ping測試，但對于一個大型網絡在你不知道中間設備以及流量路徑的情況下，你可能會需要使用traceroute來快速判斷問題點在哪。
那么，traceroute 是如何工作的呢？
Traceroute 使用 IP 數據包頭中的 TTL（生存時間）字段。通常TTL 用于在存在路由環路時能夠防止數據包永遠無休止的轉發下去，每當路由器轉發 IP 數據包時，TTL 減 1，當TTL 為零時，IP 數據包將被丟棄。
traceroute是如何工作的請看下面案例，假設從 (192.168.1.1) 向 S1 (192.168.3.1) 發送跟蹤，H1 發送的第一個 IP 數據包的 TTL 為 1；
當 R1 收到此 IP 數據包時，它想要將其轉發給 R2，但它必須將 TTL 從 1 減少到 0，結果IP 數據包將被丟棄，R1 將使用TTL 超出消息響應 H1，H現在將發送第二個包其TTL為 2；
R1 會將 TTL 從 2 減少到 1，轉發它到R2，現在 R2 必須丟棄它，R2 將回復一個 TTL超時消息。H1現在將發送另一個 TTL 為 3 的 IP 數據包；
R1將TTL從3減少到 2，R2將其從 2 減少到1，R3將不得不丟它，R3將TTL 超時消息發送給 H1，緊接著H1 將發送的最后一個 IP 數據包其 TTL 為 4;
每個路由器都會將 TTL 減 1，另一端的服務器S1將收到一個 TTL 為 1 的 IP 數據包，并以ICMP 協議回復 H1。現在我們知道目的地是可達的，并且了解了路徑上所經過的設備。
traceroute發送的每個 IP 數據包都稱為一個probe。Traceroute 可用于 ICMP、UDP 和 TCP，具體取決于其操作系統類型。
Traceroute的wireshark報文分析：
上面有兩臺主機，H1 是 Windows 計算機（192.168.1.1），H2 是Linux 計算機（192.168.1.2）
如下為windows系統的traceroute:
C:\Users\vmware>tracert 192.168.3.1
Tracing route to 192.168.3.1 over a maximum of 30 hops
1 1 ms 1 ms <1 ms 192.168.1.254
2 1 ms 1 ms 1 ms 192.168.12.2
3 1 ms 1 ms 1 ms 192.168.23.3
4 1 ms <1 ms <1 ms 192.168.3.1
Trace complete.
通過上面的輸出我們可以看到所有的路由器，對于每一跳，traceroute 將發送三個 IP 數據包，這樣是為了獲得每跳的往返時間的平均值，讓我們看看 Wireshark 中的 IP 數據包是什么樣的，這是第一個包；
上面我們看到第一個 TTL 為 1 的 IP 數據包，我們可以看到這是一個ICMP請求，當 R1 收到這個 IP 數據包時，它會這樣回應：
上面我們看到 R1 用 TTL 超時消息響應 H1，在抓包文件中，你會看到上面的兩個數據包發了三次。我們看下一個IP包：
這一次TTL 值為2，將發往R2；
第三個包TTL 值為3；
R3 回復TTL 超時消息
最后，H1 將發送一個TTL值為4 的IP 數據包；
這個最后一個包發往S1，并可以看到ICMP reply報文：
這就是 traceroute 在 Windows 上的工作方式，下面看traceroute在Linux上面的工作方式。
Linux 上的 traceroute 命令的工作方式與 Windows 類似。一個重要的區別是它不使用 ICMP，而是使用 UDP。它還允許您指定要發送的 IP 數據包（探測）的數量。為了便于觀看wireshak，僅配置發送一次探測；
$ traceroute -N 1 -q 1 192.168.3.1
traceroute to 192.168.3.1 (192.168.3.1), 30 hops max, 60 byte packets
1 192.168.1.254 (192.168.1.254) 1.202 ms
2 192.168.12.2 (192.168.12.2) 1.122 ms
3 192.168.23.3 (192.168.23.3) 1.192 ms
4 192.168.3.1 (192.168.3.1) 1.886 ms
下面是這個 traceroute 在 Wireshark 中的樣子
上面我們可以看到 H2 正在發送 UDP 數據包而不是 ICMP 請求，如下是第一個報文：
上面我們看到 H2 發送的第一個 TTL 為 1 的 IP 數據包，我們看到它使用的是UDP，目的端口號是33434，R1回復如下信息：
由于 TTL 為零，R1 將其丟棄并回復 TTL 超時消息，如下第二個TTL為2的數據包；
上面的數據包與第一個相同，只是可以看到目標端口號從 33434 增加到 33435，R2 將會繼續丟棄：
TTL 為 3 的數據包：
上面你可以看到目標端口號從 33435 增加到 33436，R3 會繼續丟棄此報文：
最后一個數據包的 TTL 為 4，目的端口號為 33437：
這個包將一直傳送到S1，由于 S1 沒有監聽這些 UDP 端口號中的任何一個，它會回復目標/端口不可達：
這里告訴 H2 我們已經到達目的地了
思科IOS
我們還可以在 Cisco IOS 上使用 traceroute 命令。與 Linux 一樣，Cisco 使用 UDP 進行跟蹤路由。從 R1 到 S1 進行跟蹤，使用單個探針：
R1#traceroute 192.168.3.1 probe 1
Type escape sequence to abort.
Tracing the route to 192.168.3.1
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.12.2 0 msec
2 192.168.23.3 4 msec
3 192.168.3.1 0 msec
在上面我們看到這條軌跡到達了目的地。
Cisco IOS 上的跟蹤路由可能非常慢，這是因為它將嘗試對每個 IP 地址進行 DNS 查找，為了使其更快，請確保可以解析這些查找或使用no ip domain-lookup 命令禁用 DNS 查找。
以下是 Wireshark 報文：
這個抓圖和剛剛看到的Linux抓圖是一樣的，所以不再添加更多的截圖了。
故障排除案例：
在這個例子中我只需要三個路由器：
讓我們從一個無法到達的目的地開始，在 R3 上添加一個具有 IP 地址的環回口：
R3(config)#interface loopback 0
R3(config-if)#ip address 3.3.3.3 255.255.255.255
目前，路由器都不知道如何到達 3.3.3.3。讓我們先看看 traceroute 輸出是什么樣的：
R1#traceroute 3.3.3.3
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
1 * * *
2 * * *
3 * * *
上面我們看到沒有一個探測器可到達目的地，然后我們在 R1 上添加一條靜態路由，以便此流量至少到達 R2：
R1(config)#ip route 3.3.3.3 255.255.255.255 192.168.12.2
并執行另一個跟蹤路由：
R1#traceroute 3.3.3.3
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.12.2 4 msec 0 msec 4 msec
2 192.168.12.2 !H * !H
現在我們可以看到 R1 能夠轉發它，R2 響應它不可達，然后我們在 R2 上添加靜態路由：
R2(config)#ip route 3.3.3.3 255.255.255.255 192.168.23.3
再嘗試一個跟蹤：
R1#traceroute 3.3.3.3
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.12.2 0 msec 4 msec 0 msec
2 192.168.23.3 4 msec * 0 msec
現在我們可以到達目的地了。
源不可達
我們可以使用 traceroute 來確定我們是否可以到達某個目的地，但也可以使用它來檢查其他路由器是否知道您的來源，這次在R1 上面添加一個環回口：
R1(config)#interface loopback 0
R1(config-if)#ip address 1.1.1.1 255.255.255.255
我現在將使用 1.1.1.1 作為我們的源對 192.168.3.1 進行跟蹤路由，我們知道 192.168.3.1 是可達的，因為我們之前嘗試過，讓我們來看看：
R1#traceroute 192.168.3.1 source loopback 0
Type escape sequence to abort.
Tracing the route to 192.168.3.1
VRF info: (vrf in name/id, vrf out name/id)
1 * * *
2 * * *
3 * * *
此跟蹤失敗，沒有人知道如何到達 1.1.1.1。讓我們在 R2 上添加一條靜態路由：
R2(config)#ip route 1.1.1.1 255.255.255.255 192.168.12.1
R2 現在知道如何達到 1.1.1.1。讓我們再次嘗試該 traceroute：
R1#traceroute 192.168.3.1 source loopback 0
Type escape sequence to abort.
Tracing the route to 192.168.3.1
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.12.2 0 msec 4 msec 0 msec
2 * * *
3 * * *
R2 做了響應，這說明問題不在 R1 和 R2 之間，而是在更遠的地方。讓我們添加最后一個靜態路由：
R3(config)#ip route 1.1.1.1 255.255.255.255 192.168.23.2
R3 現在也知道如何到達 1.1.1.1，讓我們試試那個跟蹤：
R1#traceroute 192.168.3.1 source loopback 0
Type escape sequence to abort.
Tracing the route to 192.168.3.1
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.12.2 0 msec 4 msec 0 msec
2 192.168.23.3 4 msec 0 msec 0 msec
3 192.168.3.1 0 msec 0 msec 4 msec
現在成功完成。
結論
通過此文檔相信您已經了解了traceroute 如何使用 IP 數據包中的 TTL（生存時間）字段向目標發送探測，從而允許我們發現從源到目標的路徑，您還看到了 Windows 如何使用 ICMP 和 Linux 如何使用 UDP 進行跟蹤路由，我們還研究了如何使用 traceroute 對源和/或目標未知的網絡可達性問題進行故障排除，如果您在某些路由器的跟蹤中看到一些星號（超時），則也可能該路由器（或防火墻）可能配置了訪問列表，并配置為不響應任何 TTL 過期消息。