广东珠海电信 深夜偷偷换成内网地址了 明天投诉

@dommyet 你的 RouterOS 是什么设备？

然而毛用都没有。局域网玩毛线。而且丢包率依然感人。


My traceroute [v0.86]
MBP112 (::) Sat Jul 30 23:12:22 2016
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 2605:e000:1c0d:40d0:1aa6:f7ff:fe5f:723 0.0% 166 0.9 0.9 0.7 3.7 0.3
2. 2605:e000:c0c:35::1 0.0% 166 10.2 11.0 8.1 105.9 7.9
3. 2605:e000:0:4::2:205 0.0% 166 16.9 15.8 9.3 42.4 4.8
4. 2605:e000:0:4::2:3b6 18.7% 166 11.5 12.8 9.2 28.4 3.2
5. ???
6. ???
7. 0.ae0.pr0.lax10-v6.tbone.rr.com 18.7% 166 19.8 19.6 14.0 37.6 4.1
8. 2001:1998:0:4::11c 0.0% 166 14.4 17.5 13.1 78.3 7.7
9. 10gigabitethernet2-17.core1.lax2.he.net 0.0% 166 22.0 17.9 13.6 40.9 4.7
10. cngi-bjix-as-ap-as23911.10gigabitethernet16-5.core1.lax2.he 89.7% 166 23.5 19.2 14.2 36.9 5.1
11. 2001:252:0:302::1 0.0% 166 160.7 162.3 159.9 178.8 3.2
12. 2001:252:0:100::1 83.0% 166 166.7 165.5 161.7 172.7 2.7
13. 2001:252:0:1::2 0.0% 166 167.7 167.9 162.3 193.9 3.8
14. 2001:c68::1 0.0% 166 161.6 162.4 160.0 198.2 3.7
15. 2001:c68:0:1200::1 12.0% 166 257.5 255.3 189.3 274.0 7.8
16. 2001:c68:0:1000::2 10.3% 166 247.7 255.8 190.4 269.3 7.1
17. 2001:c68:4800:202::2 16.4% 166 257.4 257.8 192.8 280.6 7.7
18. 240e::21:31:1203 19.5% 165 286.8 282.6 217.5 301.7 8.0
19. 240e:1f:0:180::3 11.6% 165 286.1 284.0 231.8 309.7 7.2
20. 240e:1f:0:216a::3 13.5% 164 297.8 285.9 237.7 308.2 7.1
21. ???

[yudi@MBP112 ~]$dig @240e:1f:1::1 www.google.com

; <<>> DiG 9.10.4-P2 <<>> @240e:1f:1::1 www.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28992
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com. IN A

;; ANSWER SECTION:
www.google.com. 600 IN A 203.98.7.65

;; Query time: 288 msec
;; SERVER: 240e:1f:1::1#53(240e:1f:1::1)
;; WHEN: Sat Jul 30 23:18:04 PDT 2016
;; MSG SIZE rcvd: 48

哈哈，回忆了下 tg 的关照。

@dommyet 电信广东是特别贵特别差（同是 RouterOS 用家握手）。

哈哈 tg 把 lz 的机器当 dns 服务器呢。向 lz 的机器请求 google 的 ip ，回来 6.6.6.6 。看来 dns 干扰系统早就支持 ipv6 了。应该是在骨干网上注入的假请求。

[yudi@MBP112 ~]$dig @240e:fa:20:b642:d84c:1d78:5d50:7814 www.google.com

; <<>> DiG 9.10.4-P2 <<>> @240e:fa:20:b642:d84c:1d78:5d50:7814 www.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24362
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: Message has 25 extra bytes at end

;; QUESTION SECTION:
;www.google.com. IN A

;; ANSWER SECTION:
www.google.com. 892 IN A 6.6.6.6
www.google.com. 892 IN A 6.6.6.6
www.google.com. 892 IN MX 65535 test3.com.

;; Query time: 163 msec
;; SERVER: 240e:fa:20:b642:d84c:1d78:5d50:7814#53(240e:fa:20:b642:d84c:1d78:5d50:7814)
;; WHEN: Sat Jul 30 23:34:46 PDT 2016
;; MSG SIZE rcvd: 114

@bclerdx RB951G-2HnD
@xieyudi1990 我在内网自己搭了个 DNS 国外域名走 dnscrypt 解析 可以避免污染 高墙偶尔会抽 dnscrypt 但是我有四条解析线路 没试过四条都被抽的 国内的域名就从国内 DNS 解析 也是四条线路 你可以试试自己搭一个
@mandymak 同意

@dommyet 事实上，这个 DNS 请求在到达你那之前就被抢答了。而且我在墙外也根本无法和你通信。
这套系统就部署了很多年了。所以甚至往一个没有 DNS 的 IP 甚至未使用的 IP 请求敏感域名，只要这个请求的 IP 数据包经过骨干路由上的干扰系统，就会有假的 DNS reply 。

所以你搭的这个 DNS 服务器估计也只能在你家用用。只要 DNS 数据包往骨干网上过，没卵用。

[yudi@MBP112 ~]$nslookup
> server baidu.com
Default server: baidu.com
Address: 123.125.114.144#53
Default server: baidu.com
Address: 180.149.132.47#53
Default server: baidu.com
Address: 220.181.57.217#53
Default server: baidu.com
Address: 111.13.101.208#53
> www.google.com
Server: baidu.com
Address: 123.125.114.144#53

Non-authoritative answer:
Name: www.google.com
Address: 37.61.54.158
>

@xieyudi1990 对的 目的就是在内网用 同时也是个缓存 提升查询速度的 应该是不管是什么来源和目的地只要经过高墙就会干扰

@xieyudi1990

Server: dc1.neverland.local
Address: 172.16.0.10

Non-authoritative answer:
Name: facebook.com
Addresses: 2a03:2880:2130:7f83:face:b00c:0:25de
173.252.90.36

@xieyudi1990 准确的说在城域网就有 fake reply 过来了，还没到骨干。一般是第 3 到第 4 跳。

@redsonic
@dommyet
对，似乎是地级市那一层。今天是我第一次逮到 ipv6 的 fake reply ， 6.6.6.6 还有个假的 mx 记录 test3.com 。嗯很不一样，很有意思。（还在测试中？似乎想干扰 /截获邮件？）

@redsonic 也不一定。刚刚那个 ipv6 的 fake reply 在 2001:c68::1 出现了。这一跳的 delay 和出口节点的 delay 差不多，所以我认为是在出口部署的。当然我不知道后面有没有其他的 fake replier ，因为我在墙外。

Host Loss% Snt Last Avg Best Wrst StDev
1. 2605:e000:1c0d:40d0:1aa6:f7ff:fe5f:723 30.1% 784 0.8 0.9 0.7 26.1 1.6
2. 2605:e000:c0c:35::1 0.1% 784 9.2 13.1 8.1 1517. 57.6
3. 2605:e000:0:4::2:205 0.0% 784 18.3 16.1 8.5 73.1 6.8
4. 2605:e000:0:4::2:3b6 32.6% 784 12.2 12.3 9.0 34.6 2.9
5. ???
6. ???
7. 0.ae0.pr0.lax10-v6.tbone.rr.com 19.1% 784 19.7 19.1 14.0 40.4 3.6
8. 2001:1998:0:4::11c 0.0% 783 13.9 16.5 13.1 110.5 7.9
9. 10gigabitethernet2-17.core1.lax2.he.net 0.0% 783 28.1 17.6 13.1 50.5 5.1
10. cngi-bjix-as-ap-as23911.10gigabitethernet16-5.core1.lax2.he.net 70.6% 783 18.4 18.6 14.5 45.4 3.6
11. 2001:252:0:302::1 0.0% 783 165.5 161.7 159.8 207.2 3.5
12. 2001:252:0:100::1 75.6% 783 167.2 165.8 161.4 207.9 6.9
13. 2001:252:0:1::2 0.1% 783 165.2 167.4 161.5 191.2 3.1
14. 2001:c68::1 2.0% 783 162.3 162.1 160.0 208.1 3.4
15. 2001:c68:0:1200::1 13.7% 783 256.8 255.0 195.1 297.6 6.5
16. 2001:c68:0:1000::2 12.8% 783 263.0 255.7 190.4 283.6 6.7
17. 2001:c68:4800:202::2 41.1% 783 270.8 257.7 190.4 282.1 8.3
18. 240e::21:31:1203 39.3% 782 283.2 282.6 215.3 316.2 8.3
19. 240e:1f:0:180::3 12.5% 782 282.7 284.1 218.9 311.0 7.2
20. 240e:1f:0:216a::3 10.6% 782 285.9 285.1 218.6 327.4 7.8
21. 240e:1f:0:180::3 99.9% 781 246.7 246.7 246.7 246.7 0.0
22. ???



ipv4 的话，好像就出口那里会有才有干扰。这几年出口的干扰倒是消失了（教育网似乎还在出口？），到了地级市一级。

看来这不是个别案例啊，我上周也是换内网了，打电话去投诉，当天就可以了，据说师傅当天处理了几十例这样的例子，如果不投诉的话，估计就是一直是内网 ip 了。

看了帖子随手登录路由看了一下，果然 172 开头的内网 ip ，广州 100m 光纤。立刻打 10000 号投诉，说尽快安排师傅处理，快则几小时，慢则 18 小时。

回想起近段时间家里 vpn 拨不回来，原来是这个搞的鬼， tnnd 。谢楼主！

@xieyudi1990 不用看 delay ，直接写段代码或 iptables 把 ip 的 ttl 改成 5 ，然后 dig www.google.com @8.8.8.8 依然可以得到 fake relay ，我不想再说什么了。 另外通过这种方法测试请求 http://www.baidu.com/www.google.com 得到 reset 也是第 4 ， 5 跳给的。

@redsonic 你没看明白。我已經说了，我人在墙外，只能从外往里探。"当然我不知道后面有没有其他的 fake replier ，因为我在墙外。 "

@xieyudi1990 要测试的话可以找个例如 6plat 这种提供 ipv6 地址的 vpn 服务。不过会不会被墙干扰而导致连不上就不清楚了。

@yexm0 今天确定的一点是，”至少“ 骨干上有 ipv6 的 dns 抢答干扰，而且似乎在测试什么。

算了不浪费时间了，再调戏墙娘剁手。退一步说关我啥事。

@redsonic 你这方法和我用的差不多。翻我几年前的帖子。 delay 是我在瞎想而已，不是主线。 dns 干扰 / rst 应该只是个旁路设备，和 delay 关系也不大。仔细看帖子，懒得说了。

@xieyudi1990 了解， 回复的也很有意思，请求 A 回复却带 MX ，这个是骗不了邮件客户端的，而且请求 MX 却没有劫持。从外到里也劫持，感觉应该是教育网里的某些人工作没做到位。