為什麼traceroute通過外網到了一個內網地址?

12-28

這個Traceroute 經過一條隧道。

隧道的一端是一個A分公司，網段有172.16.38.0/24、10.0.1.0/24；

另一端是另一個B分公司，網段有10.0.0.0/24。

當位於A分公司的一台主機172.16.38.x/24 traceroute 10.0.0.3時，就發生了以上一幕。

從第四跳就進入了Internet，隧道IP頭（外層）複製了內層IP頭的TTL數值，所以可以探測隧道兩端之間經過的路由跳數。

如果沒有複製TTL，則無法探測隧道兩端之間的跳數。

第二跳出現的超時，可能是由於"Disable ICMP Error Message " 造成的。

外網還是內網屬於人為設置的規矩，對網路協議棧來說一視同仁
數據經由的節點下一跳是經過查路由表確定的

通過以上2條，可以推斷是目的為10.0.0.3有特殊的路由表，使其經由某公網路徑到達。

一般來說，經常出現此類情況的場景是site-to-site VPN，例如10整個段都是固有的內網IP段，不同段有不同用途，不同段之間通過VPN連接起來。而VPN承載的流量，其實是在公網上通過隧道，經由加密後再傳輸的。大公司不同分公司的網路，基本來用類似的設計。

這是因為內網和外網在ip層沒有本質區別，所謂的內網，實際上就是被網關（物理上），按照子網掩碼（虛擬上），分割與虛擬出來的一個局部網路。

所以traceroute會如實反饋內網地址，與外網並無差異。

實際上，是否能看到traceroute的結果，完全取決於該設備是否同意響應你的traceroute，如果它不響應，你看到的就是* * *。

個人第一念頭是VPN，但是如果有「明顯」的VPN的話，題主不應該不會留意到這個問題。畢竟一般不關注網路情況的朋友不會去用trancert。

還有一種情況就是一些安全軟體（特別是殺毒軟體）會提供所謂「真實域名」的功能，目標是防釣魚，將用戶需要訪問的域名在其商家架設的伺服器內去尋找對應的IP，也可能出現如上情況。

還有一類可能是一些校園網要求訪問通過其伺服器對外訪問，因此網址信息會事先經過其網路管理系統，在驗證訪問請求之後，再將相應的信息提供給相應的網路伺服器。

北京聯通亂播或者有些特殊用途，導致有到10.0.0.0/24的路由。

從另一方面看，內網和公網地址在路由尋下一跳的時候並沒有什麼不同，你的網關/路由器因為沒有10.0.0.0/24的路由，所以根據默認路由往上一層丟，一直到聯通以後就分三種情況了：

只有一條默認路由，比如家寬什麼的BRAS可能就只有一個默認路由，接入城域網什麼的（只是打個比方）；
路由表裡收到了10.0.0.0/24的路由，它明確知道下一跳要丟給誰；
運營商配置很規範，把10.0.0.0/8，192.168.0.0/16，172.16.0.0/12，100.64.0.0/10給空路由了（看樣子北京聯通並沒有這麼做）；

題主這個情況就是一路默認路由，到了城域網發現咦!竟然有路由可達，然後你就traceroute到了~

ps. HE的bgp tool也報了AS4808 announces bogons不過並不是這段地址

大概就是。。。可能因為。。。
某些運營商他們內部互聯用的是私有地址，比如10.x.x.x或者172.16.x.x什麼的。。正好你想trace的地址，和他們的互聯地址雷同，所以就出現這個情況了。。。
有一次幫某客戶看了一下網路情況，C城寬頻，trace了好多跳還是10.x.x.x的地址，看的一臉懵逼，那是第一次發現還有這種情況

我估計10.0.0.0/0是聯通內部路由，但聯通設備上外網和內網路由沒有做隔離。

vpn隧道是不可能的，隧道內是看不到隧道外的公網IP』

說明路徑裡面存在一個這樣IP的路由點。所以跟蹤到這個IP的時候就完成了。

C:Usersaaa&>tracert -d 10.0.0.1

通過最多 30 個躍點跟蹤到 10.0.0.1 的路由

1 &<1 毫秒 &<1 毫秒 &<1 毫秒 192.168.1.1

2 1 ms &<1 毫秒 &<1 毫秒 192.168.2.1

3 4 ms 3 ms 3 ms 182.126.224.1

4 4 ms 3 ms 4 ms 219.154.128.205

5 * 7 ms 7 ms 61.168.39.173

6 * 11 ms * 61.168.36.218

7 9 ms 10 ms 9 ms 10.0.0.1

跟蹤完成。

每一感覺像是路由去的路徑與返迴路徑不一致造成的