这是一个创建于 3262 天前的主题，其中的信息可能已经有所发展或是发生改变。
使用的是 DNSPOD 的公共 DNS ，然后国外 IP 通过 ChinaDNS 走 5353 端口，嗯这不是重点。
突然 Goolge 上不去了，很费解。
$ dig www.google.com.hk +short
120.52.73.138
IP ： 120.52.73.138 来自：河北省廊坊市 联通沃云
我晕，联通你内网 SNI PROXY 我可以接受，但你别瞎 xx 挟持啊。
请教各位，国内有支持非 53 端口的公共 DNS 吗？
35 条回复 • 2016-02-15 14:27:38 +08:00
 |
1
sailtao 2016-01-26 03:41:09 +08:00
今天晚饭时还与同事聊到这个话题，简单说下吧，在大局域网内使用了一些国外 IP ，并且也分配给用户也是国外 IP ，当普通（不翻墙）访问这些 IP 的时候实际是访问局域网内某个设备，所以之前有人出现了 ping 8.8.8.8 延迟非常低的情况，这招是不是比墙来的更简单有狠呢。
|
 |
3
zyqf 2016-01-26 07:06:36 +08:00  2
|
 |
4
raysonx 2016-01-26 09:31:03 +08:00 via Android
果然，之前搞劫持代理被投訴後開始玩新花樣了。
如果只是聯通的自建 DNS 會解析到緩存服務器就算了，如果第三方或自建 DNS 也這樣的話，投訴。 |
 |
5
heyf 2016-01-26 09:47:02 +08:00 via iPhone
|
|
6
raysonx 2016-01-26 10:20:50 +08:00
|
 |
7
xmoiduts 2016-01-26 10:27:26 +08:00 via Android
@raysonx 我听过这样的一种方法，不知道可行性如何：
允许 cdn 服务商和网站将少量服务器部署在运营商内网，并将资源解析到它们上面。这样既不跨网，又不算劫持。 不知道这和 bgp 机房有没有关联。 |
|
8
raysonx 2016-01-26 10:36:12 +08:00
@xmoiduts 得到網站和 CDN 服務商的准許當然就不算劫持了，但這樣的話聯通那套東西不就成了 CDN 了麼。聯通現在瞎搞劫持肯定會導致大量問題的。比如將境外服務器解析到內網，天呐，網絡中又不是只有 HTTP 協議，你讓各種其他協議怎麼辦，比如我用 SSH 登錄機器會被搞成登錄聯通的緩存服務器？所以，聯通絕對腦子抽風了。
|
|
9
xmoiduts 2016-01-26 11:01:55 +08:00 via Android
@raysonx 我不用联通的宽带，家里方正用这组劫持服务器下载静态资源却比直连还要快（方正也有缓存服）。当然我知道这是缓存。以后考虑用它们加速下载，重要文件校验 md5 。 ssh 也劫持的话那可真是坑了。
|
|
10
raysonx 2016-01-26 11:07:46 +08:00
@xmoiduts 感覺以後全站 HTTPS 是趨勢。國外的大型網站很多都全站 HTTPS 了，國內淘寶、百度的搜索服務已實現全站 HTTPS ，京東也在內測全站 HTTPS 。隨著 HTTPS 的普及，劫持已經變得越來越沒意義了。
|
|
11
xmoiduts 2016-01-26 11:22:52 +08:00 via Android
@raysonx 是的，出去看看，基本是个站就 https 。以后内网正规 cdn 才是减少跨网流量的正解。
|
|
13
xmoiduts 2016-01-26 11:37:54 +08:00 via Android
@ykqmain 所有的行为都只是成本，既然劫持既能省流量，又不会带来罚款，运营商“何乐不为”呢？
|
 |
14
yexm0 2016-01-26 11:39:55 +08:00 via Android
坐等电信也作死
|
|
16
xmoiduts 2016-01-26 12:01:11 +08:00 via Android
@ykqmain 基本生活条件满足之后，显然需要更高的需求。我对未来还很迷茫，听说出国读书要划掉家里一辈子的积蓄。我这种 gpa 不到 3 的学渣还是再看看形势吧。这个假期初涉 linux 和 py ，评估一下适不适合我用咯。
|
|
17
sailtao 2016-01-26 12:03:18 +08:00 via Android
这个靠 DNS 和 https 都无法解决，地址解析正确，但是路由把你引导去了伪设备，只有 VPN 这类方式出去了才能有效解决
|
|
18
raysonx 2016-01-26 12:36:09 +08:00
@sailtao 對於聯通這種規模的運營商來講，你說的這種方法成本太高了，當然他們要是誠心搞還是能搞出來。
不過劫持總是有辦法發現的。 |
 |
19
Khlieb 2016-01-26 14:23:06 +08:00 via Android
|
 |
21
suikator 2016-01-26 14:53:47 +08:00 via Android
114dns 支持 tcp 查询
|
|
22
raysonx 2016-01-26 15:01:10 +08:00
@sailtao 之前不管劫持 TCP 的方式還是劫持 DNS 都是通過旁路搶答的方式，通過交換機的鏡像口就可以部署，還可以輕鬆控制劫持的頻率和規則。
如果按你說的方法，會導致所有流量被引入這些緩存服務器，不管是 HTTP 還是其他流量。相對於中國這麼大的互聯網來講，對處理能力的要求可能比雙十一還要恐怖得多，更不用提如何保證各種加密流量和自定義協議的通信了。 |
|
25
sailtao 2016-01-26 15:32:21 +08:00 via Android
首先需要访问这些 IP 的人不会特别多，其次把需要被访问的 ip 配置到交换机，再用交换机做负载均衡，除了响应 ping 的数据包，其他包全部抛弃，除非你有超大流量 DDOS 攻击能堵死，可是堵死了又能怎样，就算不把 IP 挂载到设备，任何响应都没有，让你在局域网内出不去的目的达到了
|
|
26
sailtao 2016-01-26 15:37:12 +08:00 via Android
@raysonx 你还没想明白，不需要你能访问，目的是让你在局域网内出不去，即使这些需要被访问的 IP 没有任何设备承载，目的已经达到，如果能 ping 通或能被访问，我还担心记录的操作呢
|
|
27
raysonx 2016-01-26 15:49:05 +08:00
@sailtao 從目前聯通的動作來看，它只是為了節省網間互聯的流量費用而已，並沒有切斷連接的意圖。你說的這些觀點太可怕了，目前還沒有見到這麼做的跡象。
|
 |
30
kokutou 2016-01-26 18:02:18 +08:00 via Android
|
 |
31
datocp 2016-01-26 21:04:53 +08:00
至少本地电信也是这样，所以上次配置 chinadns 时已经失效，解析 google 随机返回 百度或者阿里的网站。。。至少在 2015 年夏天用 pdnsd 类似方法还是正常的。自己又习惯用电信的 dns 。最后只能所有非国内网段走 vpn ， gfw list 上的域名用 dnsmasq 载入 server=/google.com/8.8.8.8 ，但是还是发现有部分国外域名无法正常解析。
当然了电信这么做到底是阴谋论，还是其它问题不得而知。在 DNS 版块，早些时候也有朋友建立自己的 DNS 服务器，但是也是频繁被污染最后放弃了。所以本地电信 ISP 到底是有意为之，还是无意被间接污染就不清楚了，电信连自己的备用 DNS 不工作都不清楚。。。但是至少上网是麻烦多多，又不能多说什么。。。谁叫这些网站本来就不存在。。。 可能 dnsmasq.conf 这样配置就大概可以解决一些国外域名无法解析的问题，奇怪的是电脑按这个配置文件淘宝解析出来的是国内 ip ，平板上又是美国 ip ，也不知道这个 strict-order 怎么工作的。 bogus-nxdomain=60.191.124.236 no-negcache strict-order server=8.8.4.4 #server=4.2.2.2 server=61.153.177.197 |
|
32
raysonx 2016-01-26 22:51:52 +08:00
已在路由器裡面把這段地址拉黑了：
iptables -I FORWARD -d 120.52.72.0/23 -j REJECT --reject-w ith icmp-net-prohibited 對於 OpenWrt ： iptables -A forwarding_rule -d 120.52.72.0/23 -j REJECT --reject-w ith icmp-net-prohibited |
 |
33
akw2312 2016-01-27 00:01:58 +08:00
@raysonx 聯通好像是通過 DNS 劫持整個劫持走？
台灣這邊 hinet 的做法比較適合點 只劫持走「 TCP 80 端口」 其他端口、 UDP 、 ICMP 全部都不劫持 => 這東西多數用於大型視頻站上面 但是人一多還是卡的要死 ww |
 |
34
LGA1150 2016-01-27 14:07:34 +08:00 via Android
配置 6in4 隧道，然后用 2001:4860:4860::8888
|
Select Language