Openwrt路由自动翻墙配置小记

还是去年7月初的时候,家里用了7年的DI-524M随着百兆宽带的升级终于退役了。那个时候也是刚刚买好VPS,就想着好好折腾一下家庭网络,于是买了一台WNDR3700v4(虽然购买之时已经算是旧型号的路由器了,但是方便买得到的可以刷Openwrt的路由着实不多)(WNDR4300v1也是选项之一,不过要是买到了v2还要想着去换货,太麻烦)开始折腾。 代理方案自然是选择了shadowsocks;至于DNS污染解决和流量分流问题,则有很多方案可以选择:ChinaDNS、dnsmasq、dnsmasq + pdnsd、当然也有直接使用shadowsocks自带的UDP转发功能或ss-tunnel功能。

关于详细的各方案的设置,都可以在飞羽博客上找到详细的配置步骤,飞羽博客上关于这个话题的文章归档页面如下:

https://cokebar.info/archives/978

同时在此也感谢博主cokebar的辛勤付出。不过飞羽博客的“关于”页面有这样一段话(当然这个网站可算不上是大陆站点,只是一个中文站点罢了):

不推荐转载至大陆站点,博主有权要求删除相关内容。

ChinaDNS方案是所有这些方案里最省力的方法,只要安装ChinaDNS和luci-app-ChinaDNS这两个包就可以便利地使用图形界面进行简单的配置了,完全可以说是省时省力省心的方案。但是最后却没有采用这个方案,其中的原因是ChinaDNS在路由器上平安无事地运行了3天后,路由器罢工了。

哦!我亲爱的路由器,你这是怎么了?看在上帝的份上,你可不能停止工作啊!真是见鬼,我还要上网做些有趣的事情呢。哦,是新的软件不能适应?真是太不可思议了,一台路由器还有不适应的问题?嘿,伙计,听着,你要是再不好好工作,我就用靴子踢你的主板!我发誓,我真的会这样做。

嘛,具体表现是访问google和wikipedia时都简单地得到了链接超时的错误信息。不过也没有去检查具体的原因是什么。 dnsmasq方案和shadowsocks自带的UDP转发方案从DNS上获得的A记录都是通过UDP协议传送到路由器端,只是,GFW实现DNS污染的主要方法之一就是将包含正确A记录的UDP包丢弃。墙外主要公共DNS服务器早就是GFW照顾的对象了(到现在很有可能已经无一幸免,包括Comodo DNS之类)。

在自己的VPS上自建DNS进行DNS转发(比如使用dnsmasq作服务端)是另一个简单的选择,使用高端口代替53端口进行DNS查询也是解决问题的途径之一(顺带一提支持非53端口查询的公共DNS并不多),可是不要忘记GFW还有随机丢包的技能。想象着正在开心地使用互联网的你看到了如下信息(包括DNS_PROBE_FINISHED_NO_INTERNET和ERR_CONNECTION_TIMED_OUT): ERROR

Orz

pdnsd + dnsmasq方案是我现在正在使用的方案。pdnsd与dnsmasq所不同的是,它可以指定获得查询记录的协议,自然tcp_only是现今的最佳选项了。仍需使用dnsmasq的理由?pdnsd并不能指定域名使用特定的上游DNS服务器,分流的功能只能由dnsmasq实现了。至于具体的配置,可以参考博主sunteya的文章,链接如下:

https://wido.me/sunteya/use-openwrt-resolve-gfw-dns-spoofing

好吧,我实在没有主动复制粘贴整合的兴趣。顺带一提,DNS查询的详细步骤也可以通过博主sunteya在上述页面中所画的示意图得知。

在这个方案中,dnsmasq会根据请求的域名选择使用不同的服务器,选择通过pdnsd查询的域名的记录会通过TCP协议由墙外上游DNS传输至指定的pdnsd端口,dnsmasq会从这个端口获取记录返回IP地址以完成查询(shadowsocks会通过IP地址和路由表的比对确定这次访问使用代理还是直连);而通过本地(墙内)DNS服务器查询的记录则直接返回(自然这部分域名对应的IP地址位于shadowsocks直连的路由表之中)。可以说是使用pdnsd作为查询记录的代理服务器了。(至于shadowsocks自带的ss-tunnel功能是否可以实现,我表示一无所知orz,不过配置方法飞羽博客上也已经提到了)

最后应该说点什么作为总结吧。飞羽博客上的方法可以说是最为详细的了,博主cokebar实在是作出了很大的贡献啊!此外并不是说TCP查询可以完全防止DNS污染,只能说相对于UDP查询更为可靠。至于支持加密的SOCKS5方案,唔,还是不作评论为好。外加一些补遗吧(其实补遗才是主要的233):如果想要将默认DNS设置为pdnsd,可以使用如下命令:

rm /etc/resolv.conf
echo "nameserver 127.0.0.1:1053">>/etc/resolv.conf

最后:

reboot

以使更改生效(此处假设pdnsd工作端口为1053)。wido.me上的方案是特定域名选择pdnsd查询,不过在这个GFW封的网站越来越多的时代——还是选择特定域名墙内查询的方案吧orz

最后的最后,补充一个不那么重要的小知识:

server=/example.com/127.0.0.1#1053

server=/.example.com/127.0.0.1#1053

这两者的区别在于前者适用于abcexample.com(即abcexample.com会使用pdnsd查询),而后者只能适用于abc.example.com

事实上server=/cn/127.0.0.1#1053这种写法是完全被允许的,但是server=/*.cn/127.0.0.1#1053这种写法是不合适的,因为只有在查询*.cn时才会使用pdnsd,但是*.cn显然不存在,这条规则也就此作废。

最后的最后的最后,贴上两条官方文档的地址:

2月22日更新:

嘛,总有一种把伪教程写成科普文的感觉。不知道这种废话风格会不会被人接受啊。

唔,pdnsd+dnsmasq方案好像随着年前墙的再次升级而部分失效了。我也是直到年前开始着手解决这个问题的时候才找到了dnscrypt方案(加密DNS查询)。嘛,在此为通过搜索引擎找到这个站点(总归会有人通过这种方式访问网页的吧orz)又没时间东看看西看看的各位贴上本站另一篇介绍dnscrypt方案伪教程的链接

Leave a Reply

Your email address will not be published. Required fields are marked *