Traceroute手冊翻譯+特殊案例分析

TRACEROUTE 手冊翻譯

簡介

traceroute -- 打印網絡數據包到網絡主機的路由信息
複製代碼

格式

traceroute [-adeFISdNnrvx] [-A as_server] [-f first_ttl] [-g gateway] [-i iface] [-M first_ttl] [-m max_ttl] [-P proto] [-p port] [-q nqueries] [-s src_addr] [-t tos] [-w waittime]
            [-z pausemsecs] host [packetsize]
複製代碼

詳細描述

• 互聯網是一個龐大而複雜的網絡硬件聚合體，經過網關鏈接在一塊兒。跟蹤單個數據包的路由路徑（或找到那些丟棄你的數據包的惡意網關）可能很困難。因此traceroute利用IP協議「生存時間TTL」信息，嘗試從每一個網關沿着到某個主機的路徑引出"ICMP TIME_EXCEEDED響應"和具體路徑。

• 惟一必需的參數是目標主機名或IP號。默認探測數據報長度爲40個字節，但能夠經過在目標主機名以後指定數據包大小（以字節爲單位）來增長此值。

詳細參數說明

-a      爲每個跳躍節點開啓AS#查詢
    -A as_server    
            打開AS＃查找並使用給定的服務器而不是默認服務器。
    -d      啓用socket調試
    -D      當收到對咱們的探測數據報的ICMP響應時，打印發送的數據包與ICMP響應引用的數據包之間的差別。打印一個顯示傳輸數據包中字段位置的鍵，而後是十六進制的原始數據包，接着是十六進制的引用數據包。引用數據包中未更改的字節顯示爲下劃線。注意，IP校驗和和引用數據包的TTL預計不匹配。默認狀況下，此選項僅發送每跳一個探測。
    -e      防火牆逃避模式。使用固定目標端口進行UDP和TCP探測。
    -f first_ttl
            設置第一個傳出探測包中使用的初始生存時間。
    -F      設置「不分段」比特。
    -g gateway
            指定鬆散的源路由網關（最多8個）。
    -i iface
            指定網絡接口以獲取傳出探測包的源IP地址。這一般僅適用於多宿主主機。（有關執行此操做的其餘方法，請參閱-s參數。）
    -I      使用ICMP ECHO而不是UDP數據報。（等同於"-P icmp"）
    -M first_ttl
            設置傳出探測包中使用的初始生存時間值。默認值爲1，即從第一跳開始。
    -m max_ttl
            設置傳出探測包中使用的最大生存時間（最大跳數）。默認值爲net.inet.ip.ttl hops（與TCP鏈接相同的默認值）。
    -n      以數字方式而不是符號和數字方式打印跳躍地址（爲路徑上找到的每一個網關保存名稱服務器地址到名稱查找）。
    -P proto
            發送指定IP協議的數據包。當前支持的協議是：UDP，TCP，GRE和ICMP其餘協議也能夠指定（經過名稱或編號），但traceroute不會實現其數據包格式的任何特殊知識。此選項對於肯定路徑中的哪一個路由器可能會根據IP協議號阻止數據包頗有用。但請參閱下面的BUGS。
    -p port
            特定協議。對於UDP和TCP，設置探針中使用的基本端口號（默認爲33434）。 traceroute但願沒有任何東西在UDP端口上監聽目標主機上的base + nhops-1（所以將返回ICMP PORT_UNREACHABLE消息以終止路由跟蹤）。若是某些內容正在偵聽默認範圍內的端口，則此選項可用於選擇未使用的端口範圍。
    -q nqueries
            將每一個「ttl」的探測次數設置爲nqueries（默認爲三個探測器）。
    -r      繞過正常的路由表並直接發送到鏈接網絡上的主機。若是主機不在直接鏈接的網絡上，則會返回錯誤。此選項可用於經過沒有路由的接口ping本地主機（例如，在路由被路由（8）丟棄以後）
    -s src_addr
            使用src_addr（必須以IP號碼，而不是主機名）做爲傳出探測數據包中的源地址。在具備多個IP地址的主機上，此選項可用於強制源地址不是發送探測數據包的接口的IP地址。若是IP地址不是本機的接口地址之一，則返回錯誤而且不發送任何內容。 （有關其餘方法，請參閱-i標誌。）
    -S      打印每一個躍點未應答的丟包率。
    -t tos  將探測包中的服務類型設置爲如下值（默認爲零）。 該值必須是0到255範圍內的十進制整數。此選項可用於查看不一樣類型的服務是否會產生不一樣的路徑。 （若是您沒有運行4.4BSD或更高版本的系統，這多是學術性的，由於正常的網絡服務，如telnet和ftp不容許您控制TOS）。 並不是全部TOS值都是合法或有意義的 - 請參閱IP規範以瞭解定義。 有用的值多是`-t 16'（低延遲）和`-t 8'（高吞吐量）。
    -v      詳細輸出。 列出了除TIME_EXCEEDED和UNREACHABLE以外的已接收ICMP數據包。
    -w      設置等待探測響應的時間（以秒爲單位）（默認爲5秒）。
    -x      切換IP校驗和。 一般，這會阻止traceroute計算IP校驗和。 在某些狀況下，操做系統能夠覆蓋部分傳出數據包，但不會從新計算校驗和（所以在某些狀況下，默認狀況下不計算校驗和，使用-x會致使計算校驗和）。 請注意，使用ICMP ECHO探測器（-I）時，最後一跳一般須要校驗和。 因此在使用ICMP時總會計算出它們。
    -z pausemsecs
            設置探針之間暫停的時間（以毫秒爲單位）（默認爲0）。 某些系統（如Solaris）和路由器（如Ciscos）限制ICMP消息。 與此一塊兒使用的推薦值是500（例如1/2秒）。
複製代碼

該程序試圖經過啓動具備比較小的小ttl（生存時間）的UDP探測包，而後偵聽來自網關的ICMP超時信息回覆來跟蹤IP包在某一個特定因特網內的路由信息。咱們用一個ttl開始咱們的探測並每一跳都+1，直到咱們獲得一個ICMP信息端口沒法訪問（這意味着咱們到達主機）或達到最大值（默認爲net.inet.ip.ttl，固然這個值能夠用-m標誌改變）。在每一個ttl設置發送三個探針（能夠用-q標誌更改），並打印一行顯示ttl+IP地址+每一個探測的網關和往返時間的信息。若是探測答案來自不一樣的網關，則將打印每一個響應系統的地址。若是在5秒內沒有響應。超時間隔（使用-w標誌更改），爲該探測器打印*。

一般咱們不但願目標主機處理UDP探測數據包，因此traceroute會把目標端口設置爲一個不太可能在用的端口值（若是目標上的某些clod使用該值，則可用-p標誌改變）。

一個可能的示例使用和輸出：

[yak 71]% traceroute nis.nsf.net.
 traceroute to nis.nsf.net (35.1.1.48), 64 hops max, 38 byte packet
 1  helios.ee.lbl.gov (128.3.112.1)  19 ms  19 ms  0 ms
 2  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms  19 ms
 3  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms  19 ms
 4  ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  39 ms  40 ms  39 ms
 5  ccn-nerif22.Berkeley.EDU (128.32.168.22)  39 ms  39 ms  39 ms
 6  128.32.197.4 (128.32.197.4)  40 ms  59 ms  59 ms
 7  131.119.2.5 (131.119.2.5)  59 ms  59 ms  59 ms
 8  129.140.70.13 (129.140.70.13)  99 ms  99 ms  80 ms
 9  129.140.71.6 (129.140.71.6)  139 ms  239 ms  319 ms
 10  129.140.81.7 (129.140.81.7)  220 ms  199 ms  199 ms
 11  nic.merit.edu (35.1.1.48)  239 ms  239 ms  239 ms
複製代碼

注意，第2和第3行是相同的。這是因爲第二跳系統上的一個有缺陷的內核lbl-csam.arpa會轉發零ttl的數據包（4.3 BSD的分佈式版本中的錯誤）。因此要注意，您必須猜想數據包經過了哪些路徑，由於NSFNet（129.140）不爲其NSS提供地址到名稱的轉換。

下面是一個更有意思的案例:

[yak 72]% traceroute allspice.lcs.mit.edu.
 traceroute to allspice.lcs.mit.edu (18.26.0.115), 64 hops max
 1  helios.ee.lbl.gov (128.3.112.1)  0 ms  0 ms  0 ms
 2  lilac-dmc.Berkeley.EDU (128.32.216.1)  19 ms  19 ms  19 ms
 3  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  19 ms  19 ms
 4  ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  19 ms  39 ms  39 ms
 5  ccn-nerif22.Berkeley.EDU (128.32.168.22)  20 ms  39 ms  39 ms
 6  128.32.197.4 (128.32.197.4)  59 ms  119 ms  39 ms
 7  131.119.2.5 (131.119.2.5)  59 ms  59 ms  39 ms
 8  129.140.70.13 (129.140.70.13)  80 ms  79 ms  99 ms
 9  129.140.71.6 (129.140.71.6)  139 ms  139 ms  159 ms
 10  129.140.81.7 (129.140.81.7)  199 ms  180 ms  300 ms
 11  129.140.72.17 (129.140.72.17)  300 ms  239 ms  239 ms
 12  * * *
 13  128.121.54.72 (128.121.54.72)  259 ms  499 ms  279 ms
 14  * * *
 15  * * *
 16  * * *
 17  * * *
 18  ALLSPICE.LCS.MIT.EDU (18.26.0.115)  339 ms  279 ms  279 ms
複製代碼

請注意，網關12,14,15,16和17跳要麼不發送ICMP超時消息，要麼發送它們的ttl過小而沒法返回到用戶主機。 14-17正在運行MIT C Gate-way代碼。鬼知道12跳發生了啥。

上面的靜音網關12多是4中的錯誤的結果。由於，對於網關，剩餘的ttl爲零的時候，ICMP超時信息必然不會返回給咱們。 當它出如今目標系統上時，此錯誤的行爲會更有趣：

1  helios.ee.lbl.gov (128.3.112.1)  0 ms  0 ms  0 ms
 2  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  19 ms  39 ms
 3  lilac-dmc.Berkeley.EDU (128.32.216.1)  19 ms  39 ms  19 ms
 4  ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  39 ms  40 ms  19 ms
 5  ccn-nerif35.Berkeley.EDU (128.32.168.35)  39 ms  39 ms  39 ms
 6  csgw.Berkeley.EDU (128.32.133.254)  39 ms  59 ms  39 ms
 7  * * *
 8  * * *
 9  * * *
 10  * * *
 11  * * *
 12  * * *
 13  rip.Berkeley.EDU (128.32.131.22)  59 ms !  39 ms !  39 ms !
複製代碼

請注意，有12個「網關」（13個是最終目的地），而且它們的後半部分徹底「丟失」。真正緣由的是rip（運行SunOS3.5的Sun-3）正在使用咱們到達的數據報中的ttl做爲其ICMP回覆中的ttl。所以，回覆將在返回路徑上超時（因爲未發送ICMP，所以未向任何人發送通知ICMP），除非咱們使用至少兩倍路徑長度的ttl進行探測。 即，rip實際上只有7跳。 以ttl爲1的返回信息是分析這個問題的線索。

traceroute在ttl <= 1以後會打出"!"。因爲供應商提供了大量過期的（DEC的Ultrix，Sun 3.x）或非標準（HPUX）軟件，若是不妥善選擇探針主機則會常常看到這種問題。

原做者

由Van Jacobson先生在Steve Deering先生的提一下進行撰寫。 而且由上千位開發者提出修改意見，特別是來自C. Philip Wood，Tim Seaver和Ken Adelman的修改意見。