遠傳電信 icmp ping/traceroute 造假延遲 + speedtest造假測速

前幾天拉的遠傳e指雲遊方案的500M光纖

我這拿到的無論是動態IP還是固定IP 中國聯通過來都是繞路的
但從這條網路 ping / traceroute / mtr 中國聯通的IP 延遲都異常的低

仔細一測之後發現 其實遠傳把去中國的ICMP協議封包給劫持了 背後出去的IP根本不一樣
也就是遠傳把這些ICMP協議的封包NAT成別的IP出去 所以所呈現出的結果當然跟實際應用不一樣
營造出直連+低延遲的假象

02:31:13.218913 IP 210.68.1.1 > 221.229.x.x: ICMP echo request, id 134, seq 22402, length 40
02:31:13.219100 IP 221.229.x.x > 210.68.1.1: ICMP echo reply, id 134, seq 22402, length 40
02:31:14.221277 IP 210.68.1.1 > 221.229.x.x: ICMP echo request, id 134, seq 22460, length 40
02:31:14.221531 IP 221.229.x.x > 210.68.1.1: ICMP echo reply, id 134, seq 22460, length 40
02:31:15.227568 IP 210.68.1.5 > 221.229.x.x: ICMP echo request, id 134, seq 24550, length 40
02:31:15.227762 IP 221.229.x.x > 210.68.1.5: ICMP echo reply, id 134, seq 24550, length 40
02:31:16.227297 IP 210.68.1.6 > 221.229.x.x: ICMP echo request, id 134, seq 25305, length 40
02:31:16.227511 IP 221.229.x.x > 210.68.1.6: ICMP echo reply, id 134, seq 25305, length 40

背後出去的IP變成 210.68.1.x 且出去的IP是會跳動的
=> ICMP往中國電信、聯通方向測都是假的結果 跟實際使用情況根本不同

(ps. 被造假ICMP的IP已知在ip header的 record route 數據一定會被丟棄)


換成TCP測試 就現出原形了 其實基本上都是繞路的 高延遲+慢


既然遠傳會玩ICMP造假 那speedtest上或許也有可能利用這樣的方式
讓測速點背後NAT去不同的IP 仔細一測 的確如此
隨便取一個中國電信廣州的測速點 名字是"ChinaTelecom-GZ" ID: 17251

其測試點所在位置為 gzspeedtest.com:8080
(ps. speedtest 現在預設是使用8080 port做測速 但仍會保留80 port做備用或者其他用途)

以下為tcp trace 測試結果
遠傳電信 icmp ping/traceroute 造假延遲 + speedtest造假測速

tcp trace是現在才做的 因為是半夜兩邊延遲差距不大 但實際上在尖峰時段 延遲跟速度差距當然是好幾倍

所以往中國電信、聯通測速卻在尖峰也有速度 延遲也低 八成也是實際連到測速點的時候 IP根本不一樣

遠傳 210.68段的路由是比較好 所以大概遠傳讓這些測速跟ICMP ping之類的東西都偷偷NAT用這個網段的IP出去


說真的 這樣造假不是很容易找到破綻啦 大陸測過來300ms 台灣測過去卻不到100ms 肯定有鬼


不過本來是做好本來大陸就不會直連的打算 連大陸就用其他ISP連
不過發現遠傳在營造直連假象 反而讓我有點不愉快

確實
icmp跟tcp如果差太多就是icmp被優化
中華ADSL幫測一下.‍‍‍‍‍

寶貝:)開心最重要!
中華ADSL幫測~UDP:80&8080&33434.有很多時候商人的洗腦話術聽聽就好.
寶貝:)開心最重要!

pomolio wrote:
確實icmp跟tcp...(恕刪)


ICMP假直連不是沒見過啦 但是回來還是原路
直接NAT別的IP出去就比較呵呵了 擺明來造假

不過其實也沒差..一開始的打算就是去大陸不用遠傳
寶貝:)開心最重要!

akw28888 wrote:
前幾天拉的遠傳e指...(恕刪)

這種欺騙用戶的惡意行為不知NCC管不管
之前用了seednet好多年
原來被騙了這麼多年
當初也一直奇怪
直連中國ping值低於50
繞日本ping值超過200
但是實際使用直連卻沒比繞日本好
好的不學 到是學這個ping優化挺快的
遽聞某些IDC也常這樣搞
一TCPPING馬上現出原形

NeverGiveUp!! wrote:
參考某樓某張圖.若...(恕刪)


那位兄臺似乎很忌諱直接打去客服問為什麼有人的IP是static的XD
我打客服換十幾個人,機房跟我聯絡過N遍了

路由完全不給調整
路由完全不給調整
路由完全不給調整

還有IP部分,遠傳(一下打來速博一下又遠傳?)機房也說

e指雲遊固1IP哪來的static
e指雲遊固1IP哪來的static
e指雲遊固1IP哪來的static

挖塞 挖洞給人家跳XD

NeverGiveUp!! wrote:
參考某樓某張圖.若...(恕刪)


遠傳去 129.250.35.250 的確是連去台灣啊 只是 "回程繞路"罷了
如果正常去日本 延遲會是32ms左右

請善用 https://ssp.pme.gin.ntt.net/lg/lg.cgi 測試

簡單來說就是遠傳八成為了costdown
將遠傳的NTT 優先權降低 *AS path prepend - 即加長路徑 讓NTT選擇的最佳路徑變更
導致路由是 NTT -> FlagTel -> 遠傳
但NTT跟FlagTel這兩個ISP之間只在洛杉磯有互連
所以才會出現明明去台灣 卻是很高的延遲


====== 有關這點 遠傳根本不給改 他就是要costdown
關閉廣告
文章分享
評分
評分
複製連結

今日熱門文章 網友點擊推薦!