OpenWrt路由器为什么会翻墙失败或不稳定

给路由器刷上OpenWrt,并按照 本教程设置了服务端和客户端,但还是不能翻墙,或者不稳定,有时能翻,有时不能翻,怎么办?

ping 服务器的ip 看看速度怎么样

ping 1.0.9.8

检查shadowsocks服务端启动时有没有带上 -u参数

-u enable udprelay mode
TPROXY is required in redir mode

本教程使用的,也就是官方的shadowsocs-libev服务端是默认启动带上 -u 参数的。但有的朋友可能使用其他版本的服务端,如Python版,就不能保证服务端启动时默认就带 -u 参数。

可以这样查询服务端是否启动,及启动参数:

$ ps -aux | grep ss-server
#.../usr/bin/ss-server -c /etc/shadowsocks-libev/config.json -a root -u -f /var/run/shadowsocks-libev/shadowsocks-libev.pid

可见上面启动时已经带了 -u 参数。

登录OpenWrt路由器查询翻墙相关进程有没有启动

root@eastking:~# ps | grep ss-
#.../usr/bin/ss-redir -b 0.0.0.0 -c /etc/shadowsocks.json -f /var/run/shadowsocks.pid
#.../usr/bin/ss-tunnel -b 0.0.0.0 -c /etc/shadowsocks.json -l 3210 -L 8.8.8.8:53 -u

root@eastking:~# ps | grep dnsmasq
#.../usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf -k -x /var/run/dnsmasq/dnsmasq.pid    

上面的查询显示,ss-redir ss-tunnel dnsmasq都已经正常启动。

有时虽然ss-redir ss-tunnel dnsmasq等进程都在,但已经失去响应了,这就需要:

重启 shadowsocks,登录路由器,运行命令:

/etc/init.d/shadowsocks restart

restart 内部分 stopstart 两步执行,实际测试发现,少数时候 stop 并不能关闭 shadowsocks相关进程,那么只能:

重启OpenWrt路由器

翻墙不稳定,有时能连上被墙网站,有时连不上

shadowsocks-libev加密翻墙的方式加大了墙的辨识难度,但不是不可能被辨识。因此,还是有可能受到干扰的。解决方法:更换加密方式,如改成 bf-cfb

一般情况下这样就能解决问题。

登录路由器用dig查询被墙域名

本教程预编译的翻墙固件都安装了 bind-dig,方便调试。

注:本教程默认的 tunnel 转发端口都是 3210

正常的结果类似如下:

root@eastking:~# dig @localhost -p 3210 google.com

; <<>> DiG 9.9.7-P3 <<>> @localhost -p 3210 google.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38460
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             299     IN      A       74.125.226.33
google.com.             299     IN      A       74.125.226.36
google.com.             299     IN      A       74.125.226.32
google.com.             299     IN      A       74.125.226.38
google.com.             299     IN      A       74.125.226.41
google.com.             299     IN      A       74.125.226.39
google.com.             299     IN      A       74.125.226.35
google.com.             299     IN      A       74.125.226.46
google.com.             299     IN      A       74.125.226.37
google.com.             299     IN      A       74.125.226.40
google.com.             299     IN      A       74.125.226.34

;; Query time: 290 msec
;; SERVER: 127.0.0.1#3210(127.0.0.1)
;; WHEN: Mon Dec 28 11:55:30 CST 2015
;; MSG SIZE  rcvd: 215

延伸阅读:

ShadowSocks教程:shadowsocks是否支持udp转发是什么来的

udp是什么:UDP 是User Datagram Protocol的简称, 中文名是用户数据报协议,是OSI(Open System Interconnection,开放式系统互联) 参考模型中一种无连接的传输层协议,提供面向事务的简单不可靠信息传送服务,IETF RFC 768是UDP的正式规范。UDP在IP报文的协议号是17。 UDP协议全称是用户数据报协议[1] ,在网络中它与TCP协议一样用于处理数据包,是一种无连接的协议。在OSI模型中,在第四层——传输层,处于IP协议的上一层。UDP有不提供数据包分组、组装和不能对数据包进行排序的缺点,也就是说,当报文发送之后,是无法得知其是否安全完整到达的。UDP用来支持那些需要在计算机之间传输数据的网络应用。包括网络视频会议系统在内的众多的客户/服务器模式的网络应用都需要使用UDP协议。UDP协议从问世至今已经被使用了很多年,虽然其最初的光彩已经被一些类似协议所掩盖,但是即使是在今天UDP仍然不失为一项非常实用和可行的网络传输层协议。 与所熟知的TCP(传输控制协议)协议一样,UDP协议直接位于IP(网际协议)协议的顶层。根据OSI(开放系统互连)参考模型,UDP和TCP都属于传输层协议。UDP协议的主要作用是将网络数据流量压缩成数据包的形式。一个典型的数据包就是一个二进制数据的传输单位。每一个数据包的前8个字节用来包含报头信息,剩余字节则用来包含具体的传输数据。

shadowsocks-android 的 DNS (UDP) 转发功能

从 2.1.2 开始,shadowsocks-android 开始支持透明的 DNS (UDP) 转发功能。这项功能包括两个部分:

  1. NAT(ROOT)模式下,仅支持转发 DNS 的 UDP 数据包。
  2. VPN 模式下,支持转发所有的 UDP 数据包。

限制:

  1. 当前只有 1.4 以上的 libev 或 nodejs 实现的服务器端才支持此项功能。
  2. libev 服务器端还需要在命令行中加上 -u 的参数。
  3. 此项功能默认关闭,依然由 pdnsd 负责转发 TCP 的 DNS 查询。

网友提出的几个问题:

问题一:shadowsocks-libev 默认启用了 udp relay 吗?

请问udp relay功能是否有必要打开?我看shadowsocks-android是有这个选项支持该功能的,但shadowsocks-qt5貌似不支持。 另外,config.json里面是不是不支持写明是否需要打开udp relay,而必须要ss-server -c /etc/shadowsocks/config.json -u这么写吗?

debian下文件在/etc/init.d/shadowsocks-libev,找到

start-stop-daemon –start –quiet –pidfile $PIDFILE –chuid $USER:$GROUP –exec $DAEMON — \
-c “$CONFFILE” -a “$USER” -u -f $PIDFILE $DAEMON_ARGS \

发现已经默认加上-u参数,1.6.1版测试结果

问题二:shadowsocks android vpn 模式要避免 dns 污染要打开 UDP 转发吗?

国内ps4联机很蛋疼,于是在路由器里搞了一个支持shadowsocks的固件,作者说支持udprelay,会转发udp数据包。 于是我就在我的服务器里开通了一个支持udprelay的ss账号,用的是最新版的ss-libev,启动参数中加了-u,应该没错。 实测ps4也可以打开youtube,但是ps4网络测试结果为nat类型失败。 我不确定是路由器固件作者的问题还是ss-libev的udprelay功能有bug,所以我需要一个可以很好支持udprelay的ss账号,进行测试。

问题三:shadowsocks 现在能不能代理游戏,我看说支持 UDP 了?

对代理游戏有一定需求(MAC版的美服 BATTLE.NET),现在SS能不能直接全局代理游戏,搜索了下貌似之前的一个版本就添加了对UDP的支持且默认开启,是不是意思是开了全局模式就默认代理UDP/TCP了?

问题四:不确定 SS 服务器端是否支持 UDP 转发,有办法测试么?

买了个套装服务,内含SS,找了个703N的路由器刷了openwrt官方镜像开始一步一步安装shadowsocks-libev版,我的想法是用这个703N做全局翻,所以DNS解析也用udp转发到8.8.4.4:53,但测了半天不好用,才想起对面的SS服务器端未必开了这个功能,现在我如何确定服务器端是否打开了UDP转发? 或者UDP转发这个功能压根和服务器端没关系?

ss-tunnel.exe -c config.json -l 53 -L 8.8.8.8:53 -u
nslookup www.youtube.com 127.0.0.1

如有返回结果则开启了udp转发

/etc/init.d/shadowsocks 这个脚本里本身已经设置了 -u ,不是这样执行的。如果你要手动加 -u, 则是 ss-server -c /etc/shadowsocks/config.json -u

results matching ""

    No results matching ""