[OT] DNS 翻墙小工具

[Bojie Li]

帮人修电脑时谷歌不到是很恼火的事情，因此搞了个 HTTP/HTTPS 代理小工具，只需要把 DNS 服务器设置为 202.38.70.237，就可以访问 HTTP/HTTPS 了。如果不想全局代理，也可以把欲代理的域名通过修改 hosts 文件劫持到 202.38.70.237。为防止滥用，此 IP 限校内。这里的 HTTPS 代理不支持 WinXP。

代码比较烂，有需要的尽情拿去 :)

https://gitlab.lug.ustc.edu.cn/boj/sslproxy

[Sam Bliss]

在 2014年6月30日星期一UTC+8下午8时37分30秒，Bojie Li写道：

帮人修电脑时谷歌不到是很恼火的事情，因此搞了个 HTTP/HTTPS 代理小工具，只需要把 DNS 服务器设置为 202.38.70.237，就可以访问 HTTP/HTTPS 了。如果不想全局代理，也可以把欲代理的域名通过修改 hosts 文件劫持到 202.38.70.237。为防止滥用，此 IP 限校内。这里的 HTTPS 代理不支持 WinXP。

代码比较烂，有需要的尽情拿去 :)

https://gitlab.lug.ustc.edu.cn/boj/sslproxy

其实已经有 42.120.21.30 了，OpenerDNS 项目，能代理的不仅仅是谷歌。 

[Bojie Li]

2014-06-30 22:35 GMT+08:00 Sam Bliss <b13...@gmail.com>:

其实已经有 42.120.21.30 了，OpenerDNS 项目，能代理的不仅仅是谷歌。

我这个也能代理世界上任何一个网站啊。刚看了一下 OpenerDNS 的“动态三层代理”技术，其实就是解析一个域名的时候从代理服务器池里动态分配一个 IP，用来给这个域名做 https 代理。由于代理服务器都在国外，不用 https 就可能被墙。

不过，比较新的浏览器（除了 WinXP 都算比较新）在访问 https 网站的时候，会明文告诉服务器自己要访问哪个域名（SNI，Server Name Indication），服务器只要与这个域名对应的 IP 建立连接就行了。因此，如果不考虑 XP 用户，根本不需要把不同的域名解析到不同的 IP，一个 IP 就够了（当然，OpenerDNS 这样做还有负载均衡和防墙的目的）。

[Thomas Copper]

这个自己写的主要是面对校内用户嘛

--
-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en

---
You received this message because you are subscribed to the Google Groups "USTC_LUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bojie Li]

？？这个跟校内校外没什么关系，我在写这个的时候是不知道 OpenerDNS 的，毕竟只是两个小脚本，用不着做那么多前期调研。

不过 OpenerDNS 这种每个域名对应一个 IP 的解决方案在用户访问的域名数量较多时 IP 会不够用，我在推上也查到了相关抱怨: https://mobile.twitter.com/fqrouter/status/420428603403145216
我利用 SNI 的方案当然没有这个问题。

[StarBrilliant]

在 2014年7月1日 上午10:41，Bojie Li <boj...@gmail.com> 写道：
> ？？这个跟校内校外没什么关系，我在写这个的时候是不知道 OpenerDNS 的，毕竟只是两个小脚本，用不着做那么多前期调研。
>
> 不过 OpenerDNS 这种每个域名对应一个 IP 的解决方案在用户访问的域名数量较多时 IP 会不够用，我在推上也查到了相关抱怨:
> https://mobile.twitter.com/fqrouter/status/420428603403145216
> 我利用 SNI 的方案当然没有这个问题。

对。我和 OpenerDNS 谈过 SNI 他们没有理睬。不过诚心要买这么多 IP 就让他买吧。
如果是 SNI 可以直接用 sniproxy 哦，何必自己造轮子。
但是 SNI 似乎是明文发送域名信息，所以被封是迟早的事。

总之：
HTTP: tinyproxy transparent mode
HTTPS: sniproxy
DNS: dnsmasq
有轮子何必造。对不？（当然你的一键式解决方案更好）

[Bojie Li]

我也不知道 sniproxy 啊……我这个也用了 dnsmasq 把所有域名污染到一个 IP，而且 http 和 https proxy 是两个文件，两个 nodejs 进程，所以我确实重新造了轮子。

另外，SNI 信息是包含在 SSL 连接握手过程中客户端向服务器发送的第一条消息中的，因此不论你是否使用 sniproxy，明文的域名信息都会被墙（或任何中间人）知道。只是有可能墙还没有开发针对 SSL 的域名过滤机制。

[Yifan Gao]

如果只是防污染，可以使用开源软件AntiDnsPollution。原理很简单：

考虑DNS旁路污染的特性，真实的response还是会返回，因此只需过滤掉假的response就可以了。首先向一个任意地址发送请求，将返回的ip地址集合记下来（如果被污染则会有返回），再向一个没有被污染的上游DNS请求，再从返回地址中（依靠刚才说的集合）去伪存真就行了。

优点是无需任何墙外资源，也无需另建服务器。缺点是首次运行延迟略高，依赖java。

在 2014年6月30日星期一UTC+8下午8时37分30秒，Bojie Li写道：

[StarBrilliant]

在 2014年7月1日 下午12:41，Yifan Gao <ylgao...@gmail.com> 写道：
> 如果只是防污染，可以使用开源软件AntiDnsPollution。原理很简单：
> 考虑DNS旁路污染的特性，真实的response还是会返回，因此只需过滤掉假的response就可以了。首先向一个任意地址发送请求，将返回的ip地址集合记下来（如果被污染则会有返回），再向一个没有被污染的上游DNS请求，再从返回地址中（依靠刚才说的集合）去伪存真就行了。
>
> 优点是无需任何墙外资源，也无需另建服务器。缺点是首次运行延迟略高，依赖java。

如果只是防污染，可以用自由软件ChinaDNS <https://github.com/clowwindy/ChinaDNS>，使用
Python 编写，不依赖 Java。
但是本 thread 讨论的是利用 DNS 服务器的重定向作用架设支持 HTTP 和 HTTPS 的透明代理。

[Bojie Li]

哦，不是防污染，是把所有域名污染到代理服务器的 IP，以便做 http/https 代理。

顺便扯扯淡，GFW 的 DNS 旁路污染是不专业的表现，把 DNS 53 端口的请求全部导到一个集群，匹配上的丢包，其他的重新注入网络，就能堵上这个漏洞。我们算算：根据 Verisign 公布的数据，全世界发往 .com 顶级域名服务器的 DNS 请求大约是每天 200 亿次，其中几分之一来自中国。DNS 查询还要查境外的权威域名服务器，总的算下来全国发往境外的权威 DNS 请求应该是 100 亿次的量级（不包括 OpenDNS），峰值估计是 1M packet per second，如果只是为了屏蔽某些特定域名，一台 x86 就能处理了。

这个每天 100 亿次还可以从国内最大 DNS 解析商 DNSPod 公布的数据验证，每日解析量大约是 160 亿次。国内访问境外域名比访问境内域名肯定要少很多。

--

[Yifan Gao]

分析的好。希望boj别去造墙O(∩_∩)O~~

-- 
Yifan Gao

开启 2014年7月1日 at 下午1:58:42, Bojie Li (boj...@gmail.com) 写:

[Bojie Li]

2014-07-01 14:01 GMT+08:00 Yifan Gao <ylgao...@gmail.com>:

分析的好。希望boj别去造墙O(∩_∩)O~~

只要没人拿枪口指着我，应该不会去干那种事……

[Bojie Li]

刚才想了想，觉得现在 GFW 的 DNS 污染用旁路的方式可能是害怕系统故障或者被 DoS 攻击时影响到 DNS 系统的正常运行。采用旁路和直通要处理的数据量是一样的，因此现在肯定没有性能问题。可能 GFW 的设计者担不起系统故障或 DNS 流量过大时中断国际域名解析的责任（事实上由于污染规则配错，这种故障已经发生过了），就采用了旁路污染这种相对保守的做法。