Shadowsocks for OpenWRT / LEDE 拾遗

本文是《Shadowsocks + ChnRoute 实现 OpenWRT / LEDE 路由器自动翻墙》的补充,介绍了一些额外的操作,可以解决一些特定的问题。本人也会持续更新这篇文章。

目录:

1、让路由器本身走SHADOWSOCKS

2、使用作者提供的软件源安装及更新SHADOWSOCKS

3、使用计划任务检测连接状态,发生异常时候自动重启SHADOWSOCKS

4、使用计划任务自动更新CHNROUTE(IGNORE.LIST)文件


1、让路由器本身走shadowsocks

这里的步骤,chnroute和gfwlist方案里都有提到,这里单列出来。

首先shadowsocks的访问控制设置中,“代理自身”这一项,根据自己需求选择“正常代理”或者“全局代理”:

然后,切换到WAN口设置→高级设置,取消“


2、使用作者提供的软件源安装及更新shadowsocks

软件源位置:http://openwrt-dist.sourceforge.net/

由于该地址被部分ISP所墙,或者访问困难,所以这些ISP要以前面“1”的步骤为基础才能进行这一步。

可以直接使用作者的一键脚本,执行:

下面是手动的步骤(请参照 http://openwrt-dist.sourceforge.net/ 里的说明:

首先添加 a65535 的 gpg key,只有这样,第三方的包才能通过签名验证。执行:

打开Luci,定位到“系统”-“软件包”-“配置”选项卡,在软件源末尾加入两行:

OpenWrt:

LEDE:

OpenWrt请根据自己的CPU型号,LEDE请根据自己的CPU架构(可以执行 opkg print-architecture 查看),将ar71xx/mipsel_24kc替换成相应的文本,最后点击提交。

然后执行命令 opkg update ,如果卡住,就按Ctrl+C取消掉,然后重试,如果反复重试还是不行,那么你可能还是需要自行下载ipk后手工安装、更新。

相关的依赖包: ipset iptables-mod-tproxy libev libcares libpcre libmbedtls libsodium ,首次安装shadowsocks的话要先把这些依赖包的最新版本安装上,如果是升级shadowsocks,如果看到这些依赖包有新版本也推荐更新一下。

接下来可以在过滤器中输入关键词进行搜索,分别输入shadowsocks、chinadns、dns-forwarder进行搜索,找到最新的shadowsocks-libev, luci-app-shadowsocks, chinadns, luci-app-chinadns, dns-forwarder, luci-app-dns-forwarder,分别点击安装即可;

顺带说明,此软件源同样包含ShadowVPN和Redsocks2及其luci-app,作者都是a65535,有需要的可以自行下载安装。

而如果你需要让系统定期检查自动更新,可以参照:OpenWRT 自动更新软件包脚本


3、使用计划任务检测连接状态,发生异常时候自动重启shadowsocks

这一个也是以完成“1”的步骤为前提的,首先请确认已经安装了 ca-certificates ,如果是LEDE,还需要 ca-bundle 。同时要注意需要安装支持https的wget(opkg install wget)

新建一个脚本文件,比如 /root/ss_watchdog.sh :

把执行权限加上

该脚本通过尝试下载google主页(只是尝试下载并不会真的下载到路由器)来检测代理是否连通,如果尝试失败,会再次尝试下载百度主页,如果失败说明网络不通,此时什么都不做,如果下载成功,说明shadowsocks异常,那么就重启shadowsocks。 –timeout=10是指的超时时间,最好根据自己的链接速度调整一下,不要过长或者过短;网址可以根据自己的情况换成其他。

下面的步骤就是向crontab加上计划任务了(可以直接在Luci里面添加),比如每10分钟执行一次检测,就添加如下内容:

倒数第二行,前面的*/10就是每十分钟,接下来的4个* 是指任意小时、天、月、星期,这样一来 就是每10分钟执行一次了;后面是执行的命令/root/tester。

日志会输出到/var/log/shadowsocks_watchdog.log,可以通过它检查计划任务运行状态。

可以先停止shadowsocks,然后添加倒数第二行到计划任务并保存应用,此时计划任务内的命令会立即执行一遍,此时查看shadowsocks是否已经启动,并且查看日志文件。

而最后一行,在周日凌晨1点,定时清空日志文件,否则,如果你长期开着路由不管,不清空日志文件会变得非常大。


4、使用计划任务自动更新chnroute(ignore.list)文件

1.新建一个文件 /root/update_ignore_list.sh 写入如下内容:

2.使用 chmod +x /root/update_ignore_list.sh 添加可执行权限

3.打开路由器管.理页面 系统 - 计划任务 填写如下内容(每天 04:30 执行):


5、不开udp代理的chrome用户,禁用quic

不开UDP代理的话,chrome观看youtube视频可能会走quic协议,这个是基于udp的,如果没设置UDP代理,会直连,可能速度慢或者不通,建议直接关闭掉。

 

6、DNSMASQ的解析优化

这里直接引用之前某网友的问题和我的回答:

1.dnsmasq中配置uci add_list dhcp.@dnsmasq[0].cachesize=10000是配置查询dns缓存的大小吧,这个最大能设置多少呢?dns结果存路由器上占用的空间应该不大吧?

如果我没记错最大好像就是10000,具体大小酌情配置,主要看运行一段时间后内存占用情况;通常占用不会太高,调成10000没问题;改大可以让dnsmasq缓存更多的解析结果。不过实际效果不明显,因为大部分情况不会访问太多的网站。

2.按照上述,如果是dns缓存的话,那么第一次打开一个没打开过的外网,比如facebook,会慢一些,之后再次打开这个网站的话会很快,是吗?但实际上不是这样的,过一段时间(1分钟左右),打开facebook会发现很慢;我用dig查询了一下dns,第一次为700多ms,后面都为1s,过了几分钟dig查询,又变成了700多s, 所以想问下是否有缓存时间一说,如果有缓存时间,能否告知下怎么设置呢? 

dnsmasq的缓存除非你手工清除或者重启程序,默认情况下是不会清除的。但是要知道DNS记录有个东西叫TTL,说白了就是有效时间,假如你一次查询,得到的结果TTL剩余10分钟,那么10分钟之后重新查询,是不会读缓存的,因为此时认为缓存里的内容已经超过时效时间,变得无效了,因此会强制重新查询。由于现代网站大量使用CDN,而CDN服务商更新IP是很频繁的,因此CDN服务商的DNS record的TTL设置的时间都比较短,这是为了保证下游的DNS查询结果尽快更新到最新的IP。facebook用的CDN,我dig查询了一下,TTL似乎是一分钟,也就是,过了一分钟之后,系统还是会重新查询而不是读缓存。
其实CDN设这么短是为了保证CDN的可用性,大部分情况下不需要这么短;dnsmasq里面有一个选项,可以设置最小的TTL时间,如果DNS record的TTL小于这个值,就会被强制提升到这个值,官方的说明为:
–min-cache-ttl=

可知直接在/etc/dnsmasq.conf里添加一行设置这个值,单位是秒:
min-cache-ttl=1800
建议不要过大,3600以内吧,否则可能会有副作用

208 条评论

  1. Gin 回复

    感谢博主的工作。
    第一项“让路由器本身走shadowsocks”设置好以后路由自身还是可能无法翻墙。我看了一下感觉是这样,虽然在WAN口设置里面已经把DNS修改为127.0.0.1,但是默认查询的端口是53且无法指定,而路由自身访问53端口的请求并没有转发到5353端口,所以不能返回正确的结果。
    这个问题造成的直接后果是无法访问openwrt-dist.sourceforge.net源更新软件包。一个简单的解决办法是修改/etc/dnsmasq.conf文件,在最后增加:
    server=/sourceforge.net/127.0.0.1#5353
    这样更新就没问题了。楼上有朋友说路由器ping google.com会受到污染,同样的道理,在/etc/dnsmasq.conf最后增加:
    server=/google.com/127.0.0.1#5353
    就可以了。只不过这个办法需要一条一条手工写进去,费点事。好在路由平时需要配置访问的也就那么几个被墙的站点,差哪个自己填上去就好了。

    1. cokebar 文章作者 回复

      WAN口设置DNS为127.0.0.1后,路由器的DNS请求会转给本地的dnsmasq,dnsmasq在本博客的两种翻墙方案中均已做好防污染措施,不会出现DNS污染。本篇文章是那两篇的补充,不能单独来看。

      1. Gin 回复

        又仔细检查了一下过程,确实是我自己的问题。在使用脚本生成dnsmasq_gfwlist.conf文件时候由于疏忽指定了错误的端口号,造成所有gfwlist列表内的域名都无法获得结果。修改好以后就没问题了。至于ping不通google.com,似乎只是因为google.com不响应ping操作。所以我昨天的结论都是错的,看来真是不能熬夜。
        另外在测试的过程中,由于未净化的ipv6 DNS的存在,确实遇到一些不可预知的问题,已经按照你去年评论里的处理方式禁用了ipv6。现在大部分ISP都开始支持ipv6了,我觉得可以把这个补充到正文里,以后可能遇到这个问题的人会越来越多,不一定都会爬楼查评论。
        在shadowsocks + dnsmasq + DNS forward + ChinaDNS不能提供完整的针对ipv6的优化方案前,恐怕只能暂时使用这种简单粗暴的处理方式了。唯一的弊端是浏览只提供ipv6服务的网站时会受到影响。

        1. cokebar 文章作者

          google.com是响应ping操作的。ping不通是因为ping是ICMP协议,不是TCP/UDP;ss只代理TCP和UDP,所以ping是直连了。想要测试延迟可以用TCP ping工具,比如说psping。

1 2 6 7 8 9 10

发表评论

电子邮件地址不会被公开。 必填项已用*标注

请输入验证码 * 请输入正确的验证码