Shadowsocks-libev: The correct UDP iptables rule for ss-redir.
I found two version UDP rule for ss-redir, I have no idea which version to choose.
version1: From ss-redir.asciidoc#example
$: ip rule add fwmark 0x01/0x01 table 100
$: ip route add local 0.0.0.0/0 dev lo table 100
$: $ipt -A SHADOWSOCKS -p udp -j TPROXY --on-port 1082 --tproxy-mark 0x01/0x01
version2: From README.md#advanced-usage
root@Wrt:~# iptables -t mangle -N SHADOWSOCKS_MARK
root@Wrt:~# ip route add local default dev lo table 100
root@Wrt:~# ip rule add fwmark 1 lookup 100
root@Wrt:~# iptables -t mangle -A SHADOWSOCKS -p udp --dport 53 -j TPROXY --on-port 12345 --tproxy-mark 0x01/0x01
root@Wrt:~# iptables -t mangle -A SHADOWSOCKS_MARK -p udp --dport 53 -j MARK --set-mark 1
root@Wrt:~# iptables -t mangle -A OUTPUT -j SHADOWSOCKS_MARK
Thanks
zw963
All 89 comments
For use with router.
zw963
on 4 Sep 2017
honwen
on 4 Sep 2017
@madeye , I see two guides, one is from README.md#advanced-usage, one is from ss-redir.asciidoc#example, I don't know which better.
zw963
on 5 Sep 2017
And what difference about following command
# ip rule add fwmark 0x01/0x01 table 100
# ip route add local 0.0.0.0/0 dev lo table 100
# ip rule add fwmark 1 lookup 100
# ip route add local default dev lo table 100
which is the correct choice for a asus router transparent proxy?
zw963
on 5 Sep 2017
Maybe show my problem is better than just ask why.
https://github.com/zw963/asuswrt-merlin-transparent-proxy/blob/master/route/opt/etc/iptables.sh
this is my iptables.sh rule for my AC5300, UDP rule is added recent days.
I am not sure those UDP is worked as execpt, could anyone point out some
improper/wrong usage? Or, maybe I missing some rule?
Thanks
zw963
on 5 Sep 2017
@chenhw2, @madeye , 谁有时间, 麻烦给解释一下, 先谢啦.
zw963
on 5 Sep 2017
Try PREROUTING chain instead of OUTPUT chain.
madeye
on 5 Sep 2017
Try PREROUTING chain instead of OUTPUT chain.
What does you means?
https://github.com/zw963/asuswrt-merlin-transparent-proxy/blob/master/route/opt/etc/iptables.sh
I am not use OUTPUT chain, tcp and udp all apply with PREROUTING chains
zw963
on 5 Sep 2017
看了你的规则, 谈一些看法, 抛砖引玉吧
# 这行代码为什么要开启?
# $ipt -I OUTPUT 1 -p tcp -j SHADOWSOCKS
这条开启后, 路由器自身也可以通过 ss 代理上网了, 不开启的话只有路由器下的设备能通过代理.
$ipt -A SHADOWSOCKS -p udp --dport 53 -j TPROXY --on-port 1082 --tproxy-mark 0x01/0x01
关于udp, 你就只有这条规则. 但是只对 53端口的 udp 才有效果. 如果你只想转发 DNS 查询到远端服务器, 还不如用 ss-tunnel 呢
overcache
on 5 Sep 2017
@icymind
这条开启后, 路由器自身也可以通过 ss 代理上网了, 不开启的话只有路由器下的设备能通过代理.
谢, 这个和我理解一致.
关于udp, 你就只有这条规则. 但是只对 53端口的 udp 才有效果. 如果你只想转发 DNS 查询到远端服务器, 还不如用 ss-tunnel 呢
我有用 ss-tunnel, 我这里的 1082 的确就是 ss-tunnel 的端口,
ss-redir 是 1080, 而且 ss-redir 没有开启 -u .
你的意思: 这条规则如果用 ss-tunnel, 是无用的吗?
zw963
on 5 Sep 2017
如果你已经设置了 dnsmasq 将 dns 转发到 1082, 那么这条规则就是无用的.
overcache
on 5 Sep 2017
@icymind , 搞错啦, 我完全搞错啦, 谢谢提示, 难怪别人跟我反馈, 加了 UDP rule 之后, 反而 DNS 不能用了.
但是只对 53端口的 udp 才有效果.
这句话不是很明白.
假设我使用 ss-redir(不用 ss-tunnel 了), 并且开启了 dup relay, 也应用了这些 UDP rule,
我还需要配置 dnsmasq 的默认 DNS 吗? 例如: server=/#/8.8.4.4#53
$ipt -A SHADOWSOCKS -p udp -m set --match-set FREEWEB dst -j RETURN
$ipt -A SHADOWSOCKS -p udp --dport 53 -j TPROXY --on-port 1080 --tproxy-mark 0x01/0x01
我的本意: 如果是白名单(FREEWEB)中的域名, 直接返回, 不是白名单的(国外的)域名, 走 ss-redir (1080 端口)
zw963
on 5 Sep 2017
但是只对 53端口的 udp 才有效果.
我的意思是你的这条规则$ipt -A SHADOWSOCKS -p udp --dport 53 -j TPROXY --on-port 1080 --tproxy-mark 0x01/0x01只匹配 53 端口的 udp (-p udp --dport 53), 对匹配到的包打标记.
- 应用了 udp rule 后还需要配置 dnsmasq 吗?
如果 udp 能转发成功, 那就不需要了. 但是你确定要所有的 dns 查询都发送给服务器查询吗? 那样的话国内的网站可能会解析到一个比较慢的地址.
- 已经配置了dnsmasq, 还需要设置 udp rule 吗?
如果你想转发 53 端口之外的 UDP, 那就需要.
overcache
on 5 Sep 2017
@icymind ,
对匹配到的包打标记.
这里打了标记, 怎么用呢? 是不是和下面的两行一起工作?
# ip rule add fwmark 0x01/0x01 table 100
# ip route add local 0.0.0.0/0 dev lo table 100
是的. 按我的理解, 大概意思是:
ip route add local 0.0.0.0/0 dev lo table 100
添加一个 id 是 100 的路由表, 该表的数据默认从 lo 回环设备发送出去
ip rule add fwmark 0x01/0x01 table 100
对标记是 0x01/0x01 的数据包, 查询 id 是 100 的路由表, 根据路由表的内容决定他的路径.
至于路由表100里是什么内容, 我就不知道了. 我没看到有任何规则往里面添加内容呢
overcache
on 5 Sep 2017
@icymind , 标记那个懂了, 谢谢.
不过, 有关 ss-redir 现在已经完全晕了.
下面是手动启动 ss-redir, 开启 udp relay 支持, 和另一个 ss-tunnel.
# ss-redir -u -c /opt/etc/shadowsocks.json -vvv
2017-09-05 10:57:26 INFO: initializing ciphers... aes-256-cfb
2017-09-05 10:57:26 INFO: UDP relay enabled
2017-09-05 10:57:26 INFO: listening at 192.168.50.1:1080
2017-09-05 10:57:26 INFO: running from root user
# ss-tunnel -c /opt/etc/shadowsocks.json -b 127.0.0.1 -l 1082 -L 8.8.4.4:53 -u
2017-09-05 11:04:43 INFO: initializing ciphers... aes-256-cfb
2017-09-05 11:04:43 INFO: UDP relay enabled
2017-09-05 11:04:43 INFO: listening at 127.0.0.1:1082
2017-09-05 11:04:43 INFO: running from root user
然后, 在路由器里面, dig -p 1082 www.google.de 返回正确结果 (ss-tunnel)
dig -p 1080 www.google.de 就没有结果.(ss-redir)
这是不是不正常啊?
zw963
on 5 Sep 2017
事实上 , 1080 端口(ss-redir) 日志一点反应都没有, 仿佛没有收到 udp 请求.
admin@RT-AC5300-5E70:/tmp/home/root# dig www.google.de -p 1080
; <<>> DiG 9.10.5 <<>> www.google.de -p 1080
;; global options: +cmd
;; connection timed out; no servers could be reached
@icymind , 看样子就没有监听 udp 的端口, 請指教.
admin@RT-AC5300-5E70:/tmp/mnt/sda1/entware/etc# netstat -an |grep 1080
tcp 0 0 192.168.50.1:1080 0.0.0.0:* LISTEN
udp 0 0 192.168.50.1:1080 0.0.0.0:*
监听了. 只不过 udp 没有
LISTEN字样罢了.另外你监听的是 192.168.50.1:1080, 并没有监听 127.0.0.1, 建议监听 0.0.0.0
即使你监听了 127.0.0.1,
dig -p 1080 www.google.de也不会有预期的结果. 我的理解是这样(可能是错的):
dig时, 产生一个目标地址是127.0.0.1:1080的UDP包, ss-redir 拿到了这个包, 然后用ss协议封装后发送到了服务器. 服务器打开封包, 发现地址是 127.0.0.1:1080, 然后就发送到了服务器的 1080 端口, 并不会解析. 如果你只想看 ss-redir 日志有没有变化, 那倒是一个可行的办法.
如果你想验证 ss-redir 能不能查询 dns, 应该:
- 正经地发送一个 dns 查询,
dig @8.8.8.8 google.com - iptables 把 8.8.8.8 的 udp 包转发到 1080端口.
- ss-redir 拿到一个目标地址是
8.8.8.8:53的 udp 并把它发送到服务器 - 服务器发送 dns 查询, 拿回结果, 发送给 ss-redir, ss-redir 再把结果返回
一篇, 希望能帮助你理解. 没问题就关闭 issues 吧
overcache
on 5 Sep 2017
@icymind, 那篇文章链接有错. :smile:
zw963
on 5 Sep 2017
好吧, 我发现我刚刚收藏了你的文章! 哈哈.
https://icymind.com/learn-from-gfw/
而且下午我还推荐给 issue #1667 看, 如果是这篇的话, 我已经拜读过了!
zw963
on 5 Sep 2017
即使你监听了 127.0.0.1, dig -p 1080 www.google.de 也不会有预期的结果.
好像是的, 重启后, 验证了下. (如果没错的话)
参照你那篇文章的例子:
- dnsmasq 添加选项:
server=/#/8.8.8.8#53
- 添加 rule, 把 8.8.8.8 udp 转发到 1080
iptables -t nat -A OUTPUT -p tcp --dport 53 -d 8.8.8.8 -j REDIRECT --to-port 1080
iptables -t nat -A OUTPUT -p udp --dport 53 -d 8.8.8.8 -j REDIRECT --to-port 1080
- dig 失败
; <<>> DiG 9.10.5 <<>> @8.8.8.8 www.google.de
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
@icymind, 你在 https://icymind.com/learn-from-gfw/ 中的测试结果, 是在路由器上吗?
真是奇了怪了.
zw963
on 5 Sep 2017
哎, 不做死了, 我还是 ss-redir + ss-tunnel 凑合着用吧.
真的是 : 不懂原理出了问题简直就像傻逼似的, 根本就没法解决。 ...
@icymind, 最后一个问题, 一切根源的始作俑者是因为这个 issue.
https://github.com/shadowsocks/shadowsocks-libev/issues/1632
当时看 Youtube 速度超级慢, 然后, @madeye 答复说, 可能是 udp relay 的问题,
答复如下:
As mentioned above, it's caused by QUIC and UDP relay. Two possible solutions:
Disable QUIC in Chrome. (Search the issue tracker for more details)
Follow the script of OpenWRT (TPROXY kernel module is required) or flash your router to OpenWRT instead.
好吧, 麻烦 @madeye 再回答一下, 当时你说的 udp relay 问题, 是指的 ss-redir 的 udp relay + iptables 问题, 还是说 ss-tunnel 的 udp relay 问题?
是不是我这种 ss-redir + ss-tunnel 的方案就没有你说的问题?
zw963
on 5 Sep 2017
@icymind, 有空也指教下. 哈
zw963
on 5 Sep 2017
ss-tunnel 只转发 DNS, Youtube 的 QUIC协议不关 ss-tunnel 的事. 关掉 Chrome 的 QUIC 最省事.
不想折腾这些原理的话, 不妨试试 😄
overcache
on 5 Sep 2017
确认下是否quic的问题，y2be时检查是否走了udp443，也就是通常所说的直连，没有经过ss。
是的话简单解决即可（不用mangle用nat也应该可以，10800为随意未使用的端口）：
iptables -t mangle -A PREROUTING -p udp -m set --match-set youtube dst -j TPROXY --on-port 10800 --tproxy-mark 0x01/0x01
dnsmasq.d中加入ipset文件youtube.conf
ipset=/.googlevideo.com/youtube
baggiogogo
on 5 Sep 2017
@baggiogogo ,
是的话简单解决即可（不用mangle用nat也应该可以，10800为随意未使用的端口）：
iptables -t mangle -A PREROUTING -p udp -m set --match-set youtube dst -j TPROXY --on-port 10800 --tproxy-mark 0x01/0x01
这里 10800 是 ss-tunnel 端口还是 ss-redir 端口呢?
zw963
on 6 Sep 2017
不想折腾这些原理的话, 不妨试试 VRouter 😄
Cool, 我不用 Mac, 不过 Linux 是不是应该更简单了, 连 VirtualBox 都不要了?
zw963
on 6 Sep 2017
@chenhw2, @madeye , 劳烦, 你们谁在有空的时候, 能讲一下 $ipt -A SHADOWSOCKS -p udp --dport 53 -j TPROXY --on-port 1082 --tproxy-mark 0x01/0x01 从前面的讨论来看, 这行代码是对匹配的包打了一些标记, 这个应该是没有问题的, 但是打了标记, 我们又能干啥? 这行代码的真实用意到底是做什么的?
似乎整个 shadowsocks 缺乏对这个的讨论, 每个人提到这个, 都讳莫如深的感觉, 或者给一些完全看不懂变量名啥意思的代码供参考, 没有头绪啊, 我想要解释, 五句话以内应该能讲清楚吧 ...
@chenhw2 , 请问, 这里面的哪一条 rule, 跟之前打标记的那个 UDP rule 有关?
include_ac_rules() {
local protocol=$([ "$1" = "mangle" ] && echo udp || echo tcp)
iptables-restore -n <<-EOF
*$1
:SS_SPEC_LAN_DG - [0:0]
:SS_SPEC_LAN_AC - [0:0]
:SS_SPEC_WAN_AC - [0:0]
:SS_SPEC_WAN_FW - [0:0]
-A SS_SPEC_LAN_DG -m set --match-set ss_spec_dst_sp dst -j RETURN
-A SS_SPEC_LAN_DG -p $protocol $EXT_ARGS -j SS_SPEC_LAN_AC
-A SS_SPEC_LAN_AC -m set --match-set ss_spec_src_bp src -j RETURN
-A SS_SPEC_LAN_AC -m set --match-set ss_spec_src_fw src -j SS_SPEC_WAN_FW
-A SS_SPEC_LAN_AC -m set --match-set ss_spec_src_ac src -j SS_SPEC_WAN_AC
-A SS_SPEC_LAN_AC -j ${LAN_TARGET:=SS_SPEC_WAN_AC}
-A SS_SPEC_WAN_AC -m set --match-set ss_spec_dst_fw dst -j SS_SPEC_WAN_FW
-A SS_SPEC_WAN_AC -m set --match-set ss_spec_dst_bp dst -j RETURN
-A SS_SPEC_WAN_AC -j SS_SPEC_WAN_FW
$(gen_prerouting_rules $protocol)
COMMIT
EOF
}
@zw963 To use ss-redir udp relay with ASUS, you have to change 1 rule,
ss-redir.json
{
"server":"VPS IP",
"server_port":VPS PORT,
"local_address":"192.168.1.1",
"local_port":1080,
"password":"password",
"method":"chacha20-ietf-poly1305",
"timeout":60
}
iptables rule
iptables -t mangle -A SHADOWSOCKS -p udp -m set --match-set gfwlist dst -j TPROXY --on-ip 192.168.1.1 --on-port 1080 --tproxy-mark 0x01/0x01
--on-ip 192.168.1.1 is a point.
odkrys
on 6 Sep 2017
@odkrys, Hi, Your example use a black list (gfwlist), But, I use a white list.
Following is my rule, FREEWEB is whitelist which can access directly from china.
ipset -N FREEWEB iphash
iptables -t mangle -A SHADOWSOCKS -p udp -m set --match-set FREEWEB dst -j RETURN
iptables -t mangle -A SHADOWSOCKS -p udp --dport 53 -j TPROXY --on-port 1082 --tproxy-mark 0x01/0x01
What I expect is: if DNS match FREEWEB, use default DNS, othersize, redirect DNS to 1082(ss-tunnel)
But, I don't know above rule if work as expect.
Thanks
----------- Update --------
if change your's rule to white list, how to do that?
zw963
on 6 Sep 2017
I have no idea about whitelist.
I just use countable sites on list.
When you test the rules, you must add --on-ip 192.168.1.1 in rule.
let's check, https://ly798.github.io/2016/01/02/%E5%B0%8F%E7%B1%B3mini-%E7%A7%91%E5%AD%A6%E4%B8%8A%E7%BD%91/
odkrys
on 6 Sep 2017
@zw963
不是任何使用中的端口，任何随意无用的端口即可，当YouTube走quic时，走得通它会走，走不通会回到tcp去，这样就不用费力处理udp部分了，另外是方便kcptun之类的加速，如果走了quic，就享受不到了，app之类的不能关闭quic的也可以正常使用。
另外一定要用udp转发的话，分情况的，游戏这些的话你上面这些iptables就可以了，涉及到dns还要处理OUTPUT链。
baggiogogo
on 6 Sep 2017
这样或许直观一点
UDP在 表: Mangle 中处理
具体 TPROXY 的用法可以参考 http://itoedr.blog.163.com/blog/static/1202842972013631258540/
honwen
on 6 Sep 2017
不是任何使用中的端口，任何随意无用的端口即可
@baggiogogo , 晕哦, 难道我又完全错了.
iptables -t mangle -A PREROUTING -p udp -m set --match-set youtube dst -j TPROXY --on-port 10800 --tproxy-mark 0x01/0x01
这条 rule 的 --on-port 竟然指定到一个完全没有被监听的端口, 是这样的意思吗?
我一直以为这个端口必须是 ss-redir 监听的那个端口.
好吧, 如果上面 --on-port 10800 理解没错的话, 请问, 这条语句到底在做什么事情?
zw963
on 6 Sep 2017
@chenhw2 , 请教几个在我的理解范围内的问题:
tcp dpt 80 match-set koolproxy dst, 这里的koolproxy是白名单还是黑名单?- 我没看错的话, 上面实在 mangle 表里面加了一条 tcp 的 rule ? 意义何在?
- udp dpt:53, 你这里 53 的全部 return, 那如果访问 y2be, 难道也用本地 dns 解析?
还望解答. 谢谢.
zw963
on 6 Sep 2017
@zw963 这两个是我自己另外的处理，与SS无关，可以忽略
honwen
on 6 Sep 2017
@chenhw2 , 为了节省你宝贵的时间, 我创建了一个我的脚本的新的分支,
并加了很多注释, 麻烦你看一下, 直接就问题来解决问题.
zw963
on 6 Sep 2017
@zw963 没有梅林设备，只搞过LEDE/OpenWRT
honwen
on 6 Sep 2017
@chenhw2 , 我只是想找到只使用 ss-redir 实现透明代理的路子, 这点 merlin 和 openwrt 是相同的吧?
你可以指导下我那个脚本该如何编写吗?
zw963
on 6 Sep 2017
@zw963 这两个是我自己另外的处理，与SS无关，可以忽略
你截的那个图里面, 有那个和 ss-redir 做透明代理(udp relay)有关呢?
你可以告诉我哪一行, 或者再截个部分图, 或者你可以直接指导下
我那个 iptables.sh 文件该如何编写这块的 rule 呢?
zw963
on 6 Sep 2017
@zw963 带SS字样（不区分大小写）的都是和ss-redir 做透明代理(udp relay)有关
honwen
on 6 Sep 2017
@chenhw2 , 好吧, 能看出一点儿眉目的, 貌似只有下面两条, 有些疑问
- SS_SPEC_LAN_AC ... udp dpts:22:1023, 这行有没有关系?
- 最后一条 rule,
tproxy redirect 0.0.0.0:1234 mark 0x1 0x1, 里面的那个 1234 端口, 是什么端口呢?
zw963
on 6 Sep 2017
@zw963
您搞混了，关键不知您到底想解决的是什么问题，是quic的问题，还是一定要做udp转发。
解决quic有三个办法，1关闭浏览器quic（这样对于app就无解了），2使quic走不通重新回到SS tcp去（任何简单的iptables只要能达到这个效果，那都可以），3做udp转发（这样会涉及到dns问题，除非dns做tcp查询），复杂程度依次递增1<2<3
如果一定要做udp转发，那思路和ss-redir透明转发tcp是一样的，假设采用tcp查询dns，只处理PREROUTING肯定是不够的，还要处理OUTPUT。
至少要加上以下（中间应该也需要加内网地址防止回环，仅供参考），
iptables -t mangle -N SHADOWSOCKS_MARK
iptables -t mangle -A SHADOWSOCKS_MARK -d 8.8.8.8 -p udp --dport 53 -j MARK --set-mark 1
iptables -t mangle -A OUTPUT -p udp -j SHADOWSOCKS_MARK
以上都是在不开ss-tunnel只用ss-redir的情况下，另外如果做udp转发，ss-redir肯定要加-u的，不加它只处理tcp，相应ss-server也必须加-u。
baggiogogo
on 6 Sep 2017
@icymind , 为什么我参照你的下面配置, 在路由器上从来不工作 ...
先配置dnsmasq用4个8查询Evil-Domain: 把127.0.0.1#1080改为8.8.8.8#53
然后再用iptables把发往8.8.8.8的数据包转发给ss-redir:
iptables -t nat -A OUTPUT -p udp --dport 53 -d 8.8.8.8 -j REDIRECT --to-port 1080
然而通过观察，虽然ss-server收到了udp数据，但是udp的目标地址仍然是127.0.0.1#1080。这个方法并不奏效。
添加一条规则，试试如果使用TCP查询DNS，ss-server能不能进行正常的DNS解析:
iptables -t nat -A OUTPUT -p tcp --dport 53 -d 8.8.8.8 -j REDIRECT --to-port 1080
再次通过nslookup发起查询，结果观察到ss-server收到数据后成功向8.8.8.8发送请求，并将响应发回了ss-redir。
@baggiogogo
您搞混了，
是的, 完全搞乱了.
关键不知您到底想解决的是什么问题，是quic的问题，还是一定要做udp转发。
这里有描述我的精确问题. 谢谢, 看了你的答复, 看样子我少了 SHADOWSOCKS_MARK 之类的代码??
zw963
on 6 Sep 2017
@baggiogogo, 能否直接针对那个 iptables.sh, 指点一二?
zw963
on 6 Sep 2017
@baggiogogo , 且不论我是否理解具体含义
我根据你最近的回复, 我改写了 udp rule,
你看下, 给点指导意见, 例如哪些地方写的部队, 或者根本没有必要.
我的目的暂时先定为一个, 让 ss-redir 可以支持 DNS 查询.
ip rule add fwmark 0x01/0x01 table 100
ip route add local 0.0.0.0/0 dev lo table 100
ipt="$iptables -t mangle"
$ipt -N SHADOWSOCKS
$ipt -N SHADOWSOCKS_MARK
# 本地回环 ip 集合.
for i in $localips; do
$ipt -A SHADOWSOCKS -d "$i" -j RETURN
done
$ipt -A SHADOWSOCKS -p udp -m set --match-set FREEWEB dst -j RETURN
$ipt -A SHADOWSOCKS -p udp --dport 53 -j TPROXY --on-port 1080 --tproxy-mark 0x01/0x01
$ipt -A SHADOWSOCKS_MARK -d 8.8.8.8 -p udp --dport 53 -j MARK --set-mark 1
# 应用规则, 注释这行代码, 重启后会让 UDP rules 失效.
$ipt -I PREROUTING 1 -p udp -j SHADOWSOCKS
$ipt -A OUTPUT -p udp -j SHADOWSOCKS_MARK
抱歉，不是太懂脚本，但看大意是差不多了，您能否实际尝试一下能否正常工作，如还是不行晚点我用树莓派试验。
很好理解的，PREROUTING是针对局域网进入路由的请求（比如DNS），如果以这个路由作为一个dns服务器，那局域网的请求进入以后，路由自身还要出去真正的dns服务器查询随后反馈，路由器这个请求就需要用OUTPUT。
麻烦就麻烦在tproxy用法上，确实有点云里雾里的，处理tcp链的nat就很容易理解。
baggiogogo
on 6 Sep 2017
@baggiogogo , 已经有重大进步, 目前, 我已经可以直接 dig @8.8.8.8 www.google.de, 而且可以确定
当我执行 dig 命令时, ss-server 收到了 package 并且返回了正确的响应.
[udp] server received a package
[udp] cache missing 127.0.0.1:53 <-> ...
下面是 udp rule 以及我的理解,
ip rule add fwmark 0x01/0x01 table 100
ip route add local 0.0.0.0/0 dev lo table 100
ipt="$iptables -t mangle"
$ipt -N SHADOWSOCKS
# 这里的 rule 用来给所有需要通过 ss-redir 来查询 DNS 的 udp 设定 mark.
$ipt -N SHADOWSOCKS_MARK
# 本地回环 ip 集合, 不需要添加 mark.
for i in $localips; do
$ipt -A SHADOWSOCKS_MARK -d "$i" -j RETURN
done
# 如果匹配 FREEWEB, 也不需要添加 mark
$ipt -A SHADOWSOCKS_MARK -p udp -m set --match-set FREEWEB dst -j RETURN
# 剩下的全部都设定 mark 为 1
$ipt -A SHADOWSOCKS_MARK -d 8.8.8.8 -p udp --dport 53 -j MARK --set-mark 1
# 针对所有被设定了 mark 的包, 代理到 1080(redir来处理) 来处理.
$ipt -I PREROUTING 1 -p udp --dport 53 -j TPROXY --on-port 1080 --on-ip 192.168.50.1 --tproxy-mark 0x01/0x01
# 应用 SHADOWSOCKS_MARK 到 OUTPUT
$ipt -A OUTPUT -p udp -j SHADOWSOCKS_MARK
@baggiogogo , 不知道我上面的理解对不对.
我已经配置 dnsmasq 默认 server 配置为 '8.8.8.8#53', 但是还有个问题,
我可以 dig @8.8.8.8 www.google.de 得到期望的结果, 但是 dig www.google.de 卡死了,
应该是形成了死锁 ...
zw963
on 6 Sep 2017
@icymind , 有时间吗? 一起来把这个有关 set-mark 的问题搞明白吧, 我感觉自己就差最后一步了 ...
zw963
on 6 Sep 2017
我在我的环境测试了，把PREROUTING和OUTPUT分别都加上内网地址，OUTPUT多加一条服务器地址，一切即可工作正常，把SHADOWSOCKS_MARK看作单独处理dns的规则就行了（或者以后路由本身要用到udp下载之类再添加其他相应的规则），游戏及其他规则不需要用到OUTPUT的，加到SHADOWSOCKS规则就行了。
或许还有更简便更优化的方法，等其他大神答疑解惑吧。
我个人因为不玩游戏之类不需要做udp转发，所以是把dns之类的全部处理成tcp，最后用kcptun一起加速。
baggiogogo
on 6 Sep 2017
OUTPUT多加一条服务器地址，
这是啥意思?
有没有写好的 rule ... 看抓图看不懂. :smile:
zw963
on 6 Sep 2017
@baggiogogo , 你那个图里面, 10800 端口是什么, 1080 又是什么?
两条 rule 感觉好像, 是不是有一条是多余的?
zw963
on 6 Sep 2017
不用管10800，那是我个人的规则，没删。
iptables -t mangle -N SHADOWSOCKS
iptables -t mangle -N SHADOWSOCKS_MARK
ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100
iptables -t mangle -A SHADOWSOCKS -d 0.0.0.0/8 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 10.0.0.0/8 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 127.0.0.0/8 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 169.254.0.0/16 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 172.16.0.0/12 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 192.168.0.0/16 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 224.0.0.0/4 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 240.0.0.0/4 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 8.8.8.8 -p udp --dport 53 -j TPROXY --on-port 1080 --tproxy-mark 0x01/0x01
iptables -t mangle -A SHADOWSOCKS_MARK -d (服务器地址） -j RETURN
iptables -t mangle -A SHADOWSOCKS_MARK -d 0.0.0.0/8 -j RETURN
iptables -t mangle -A SHADOWSOCKS_MARK -d 10.0.0.0/8 -j RETURN
iptables -t mangle -A SHADOWSOCKS_MARK -d 127.0.0.0/8 -j RETURN
iptables -t mangle -A SHADOWSOCKS_MARK -d 169.254.0.0/16 -j RETURN
iptables -t mangle -A SHADOWSOCKS_MARK -d 172.16.0.0/12 -j RETURN
iptables -t mangle -A SHADOWSOCKS_MARK -d 192.168.0.0/16 -j RETURN
iptables -t mangle -A SHADOWSOCKS_MARK -d 224.0.0.0/4 -j RETURN
iptables -t mangle -A SHADOWSOCKS_MARK -d 240.0.0.0/4 -j RETURN
iptables -t mangle -A SHADOWSOCKS_MARK -d 8.8.8.8 -p udp --dport 53 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -p udp -j SHADOWSOCKS
iptables -t mangle -A OUTPUT -p udp -j SHADOWSOCKS_MARK
基本的，其他的自由发挥吧，不多余，OUTPUT不能用于tproxy链上。
baggiogogo
on 6 Sep 2017
@baggiogogo , 感觉是不是少了一条?
Chain SHADOWSOCKS (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/8
0 0 RETURN all -- * * 0.0.0.0/0 10.0.0.0/8
0 0 RETURN all -- * * 0.0.0.0/0 100.64.0.0/10
2270 521K RETURN all -- * * 0.0.0.0/0 127.0.0.0/8
0 0 RETURN all -- * * 0.0.0.0/0 169.254.0.0/16
0 0 RETURN all -- * * 0.0.0.0/0 172.16.0.0/12
0 0 RETURN all -- * * 0.0.0.0/0 192.0.0.0/24
0 0 RETURN all -- * * 0.0.0.0/0 192.0.2.0/24
0 0 RETURN all -- * * 0.0.0.0/0 192.31.196.0/24
0 0 RETURN all -- * * 0.0.0.0/0 192.52.193.0/24
0 0 RETURN all -- * * 0.0.0.0/0 192.88.99.0/24
223 20072 RETURN all -- * * 0.0.0.0/0 192.168.0.0/16
0 0 RETURN all -- * * 0.0.0.0/0 192.175.48.0/24
0 0 RETURN all -- * * 0.0.0.0/0 198.18.0.0/15
0 0 RETURN all -- * * 0.0.0.0/0 198.51.100.0/24
0 0 RETURN all -- * * 0.0.0.0/0 203.0.113.0/24
412 150K RETURN all -- * * 0.0.0.0/0 224.0.0.0/4
0 0 RETURN all -- * * 0.0.0.0/0 240.0.0.0/4
0 0 RETURN all -- * * 0.0.0.0/0 255.255.255.255
0 0 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0 match-set FREEWEB dst
0 0 TPROXY udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 TPROXY redirect 192.168.50.1:1080 mark 0x1/0x1
Chain SHADOWSOCKS_MARK (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/8
0 0 RETURN all -- * * 0.0.0.0/0 10.0.0.0/8
0 0 RETURN all -- * * 0.0.0.0/0 100.64.0.0/10
2270 521K RETURN all -- * * 0.0.0.0/0 127.0.0.0/8
0 0 RETURN all -- * * 0.0.0.0/0 169.254.0.0/16
0 0 RETURN all -- * * 0.0.0.0/0 172.16.0.0/12
0 0 RETURN all -- * * 0.0.0.0/0 192.0.0.0/24
0 0 RETURN all -- * * 0.0.0.0/0 192.0.2.0/24
0 0 RETURN all -- * * 0.0.0.0/0 192.31.196.0/24
0 0 RETURN all -- * * 0.0.0.0/0 192.52.193.0/24
0 0 RETURN all -- * * 0.0.0.0/0 192.88.99.0/24
223 20072 RETURN all -- * * 0.0.0.0/0 192.168.0.0/16
0 0 RETURN all -- * * 0.0.0.0/0 192.175.48.0/24
0 0 RETURN all -- * * 0.0.0.0/0 198.18.0.0/15
0 0 RETURN all -- * * 0.0.0.0/0 198.51.100.0/24
0 0 RETURN all -- * * 0.0.0.0/0 203.0.113.0/24
412 150K RETURN all -- * * 0.0.0.0/0 224.0.0.0/4
0 0 RETURN all -- * * 0.0.0.0/0 240.0.0.0/4
0 0 RETURN all -- * * 0.0.0.0/0 255.255.255.255
0 0 MARK udp -- * * 0.0.0.0/0 8.8.8.8 udp dpt:53 MARK set 0x1
下面是我修改后的 rule:
ip rule add fwmark 0x01/0x01 table 100
ip route add local 0.0.0.0/0 dev lo table 100
ipt="$iptables -t mangle"
$ipt -N SHADOWSOCKS
$ipt -N SHADOWSOCKS_MARK
# 本地回环 ip 集合, 不需要添加 mark.
for i in $localips; do
$ipt -A SHADOWSOCKS_MARK -d "$i" -j RETURN
$ipt -A SHADOWSOCKS -d "$i" -j RETURN
done
# 所有发往 8.8.8.8 端口 53 的数据包都设定 mark (这个是 SHADOWSOCKS_MARK 最后那一条 rule)
$ipt -A SHADOWSOCKS_MARK -d 8.8.8.8 -p udp --dport 53 -j MARK --set-mark 1
# 如果匹配 FREEWEB, 也不需要添加 mark (这是 SHADOWSOCKS 最后的那两条)
$ipt -A SHADOWSOCKS -p udp -m set --match-set FREEWEB dst -j RETURN
# 针对所有被设定了 mark 的包, 代理到 1080(redir来处理) 来处理.
$ipt -A SHADOWSOCKS -p udp --dport 53 -j TPROXY --on-port 1080 --on-ip 192.168.50.1 --tproxy-mark 0x01/0x01
# 应用 SHADOWSOCKS_MARK 到 OUTPUT
$ipt -I PREROUTING 1 -p udp -j SHADOWSOCKS
$ipt -I PREROUTING 1 -p udp -j SHADOWSOCKS_MARK
我是不是还少什么?
zw963
on 6 Sep 2017
@baggiogogo ,
下面是参考你的, 能否解释下这两行的意思? 那个是设定 mark, 那个是使用 mark ?
iptables -t mangle -A SHADOWSOCKS -d 8.8.8.8 -p udp --dport 53 -j TPROXY --on-port 1080 --tproxy-mark 0x01/0x01
iptables -t mangle -A SHADOWSOCKS_MARK -d 8.8.8.8 -p udp --dport 53 -j MARK --set-mark 1
抱歉啦，这我真没这本事说清楚，只是略有点routerOS的基础，所以流程上能理解个一二，等科班大神来具体解释吧。
baggiogogo
on 6 Sep 2017
@baggiogogo , 参照你的完整输出, 貌似一模一样的, 但不工作啊!
无论路由器还是主机, dig www.google.com 均卡死.
admin@RT-AC5300-5E70:/tmp/mnt/sda1/entware/etc# iptables -t mangle -n -vL
Chain PREROUTING (policy ACCEPT 288 packets, 67873 bytes)
pkts bytes target prot opt in out source destination
193 43162 SHADOWSOCKS udp -- * * 0.0.0.0/0 0.0.0.0/0
Chain INPUT (policy ACCEPT 264 packets, 59093 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 MARK all -- * br0 192.168.50.0/24 192.168.50.0/24 MARK xset 0x1/0x7
Chain OUTPUT (policy ACCEPT 287 packets, 69773 bytes)
pkts bytes target prot opt in out source destination
185 44381 SHADOWSOCKS_MARK udp -- * * 0.0.0.0/0 0.0.0.0/0
Chain POSTROUTING (policy ACCEPT 287 packets, 69773 bytes)
pkts bytes target prot opt in out source destination
Chain SHADOWSOCKS (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/8
0 0 RETURN all -- * * 0.0.0.0/0 10.0.0.0/8
0 0 RETURN all -- * * 0.0.0.0/0 100.64.0.0/10
152 33298 RETURN all -- * * 0.0.0.0/0 127.0.0.0/8
0 0 RETURN all -- * * 0.0.0.0/0 169.254.0.0/16
0 0 RETURN all -- * * 0.0.0.0/0 172.16.0.0/12
0 0 RETURN all -- * * 0.0.0.0/0 192.0.0.0/24
0 0 RETURN all -- * * 0.0.0.0/0 192.0.2.0/24
0 0 RETURN all -- * * 0.0.0.0/0 192.31.196.0/24
0 0 RETURN all -- * * 0.0.0.0/0 192.52.193.0/24
0 0 RETURN all -- * * 0.0.0.0/0 192.88.99.0/24
6 387 RETURN all -- * * 0.0.0.0/0 192.168.0.0/16
0 0 RETURN all -- * * 0.0.0.0/0 192.175.48.0/24
0 0 RETURN all -- * * 0.0.0.0/0 198.18.0.0/15
0 0 RETURN all -- * * 0.0.0.0/0 198.51.100.0/24
0 0 RETURN all -- * * 0.0.0.0/0 203.0.113.0/24
24 8780 RETURN all -- * * 0.0.0.0/0 224.0.0.0/4
0 0 RETURN all -- * * 0.0.0.0/0 240.0.0.0/4
0 0 RETURN all -- * * 0.0.0.0/0 255.255.255.255
11 697 TPROXY udp -- * * 0.0.0.0/0 8.8.8.8 udp dpt:53 TPROXY redirect 0.0.0.0:1080 mark 0x1/0x1
Chain SHADOWSOCKS_MARK (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/8
0 0 RETURN all -- * * 0.0.0.0/0 10.0.0.0/8
0 0 RETURN all -- * * 0.0.0.0/0 100.64.0.0/10
152 33298 RETURN all -- * * 0.0.0.0/0 127.0.0.0/8
0 0 RETURN all -- * * 0.0.0.0/0 169.254.0.0/16
0 0 RETURN all -- * * 0.0.0.0/0 172.16.0.0/12
0 0 RETURN all -- * * 0.0.0.0/0 192.0.0.0/24
0 0 RETURN all -- * * 0.0.0.0/0 192.0.2.0/24
0 0 RETURN all -- * * 0.0.0.0/0 192.31.196.0/24
0 0 RETURN all -- * * 0.0.0.0/0 192.52.193.0/24
0 0 RETURN all -- * * 0.0.0.0/0 192.88.99.0/24
0 0 RETURN all -- * * 0.0.0.0/0 192.168.0.0/16
0 0 RETURN all -- * * 0.0.0.0/0 192.175.48.0/24
0 0 RETURN all -- * * 0.0.0.0/0 198.18.0.0/15
0 0 RETURN all -- * * 0.0.0.0/0 198.51.100.0/24
0 0 RETURN all -- * * 0.0.0.0/0 203.0.113.0/24
22 10386 RETURN all -- * * 0.0.0.0/0 224.0.0.0/4
0 0 RETURN all -- * * 0.0.0.0/0 240.0.0.0/4
0 0 RETURN all -- * * 0.0.0.0/0 255.255.255.255
0 0 RETURN all -- * * 0.0.0.0/0 这里是我的 ss-server ip 地址?
11 697 MARK udp -- * * 0.0.0.0/0 8.8.8.8 udp dpt:53 MARK set 0x1
@baggiogogo , ss-redir 在 1080 监听.
admin@RT-AC5300-5E70:/tmp/mnt/sda1/entware/etc# netstat -an |grep 1080
tcp 0 0 192.168.50.1:1080 0.0.0.0:* LISTEN
udp 0 0 192.168.50.1:1080 0.0.0.0:*
好吧, 是监听地址 0.0.0.0 和 192.168.50.1 不符的问题, 😃
zw963
on 6 Sep 2017
那就是我们两的环境不一样了，问题肯定在dnsmasq上，检查下，或者根据实际情况调整下吧。
我dnsmasq是传统的设定，监听53端口，上游dns服务器是chinadns端口，由chinadns负责分辨。
ok,能工作了吧，能工作就行，剩下精益求精需要真大神来指导操作，俺也挺期待。
baggiogogo
on 6 Sep 2017
@baggiogogo , 能工作啦, 但是还有 这里面 介绍的第二个问题, 也就是所有的域名都走 ss-redir 了. 😸
Chain SHADOWSOCKS (1 references)
pkts bytes target prot opt in out source destination
....
0 0 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0 match-set FREEWEB dst
0 0 TPROXY udp -- * * 0.0.0.0/0 8.8.8.8 udp dpt:53 TPROXY redirect 0.0.0.0:1080 mark 0x1/0x1
Chain SHADOWSOCKS_MARK (1 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 0.0.0.0/0 我的服务器 ip 地址
0 0 RETURN udp -- * * 0.0.0.0/0 0.0.0.0/0 match-set FREEWEB dst
0 0 MARK udp -- * * 0.0.0.0/0 8.8.8.8 udp dpt:53 MARK set 0x1
而我期望的是:
如果 dig 的这个域名在 FREEWEB 白名单中, 就 return, 我想的就是, 不走 redir, 走默认 DNS, 但是不生效?
zw963
on 6 Sep 2017
我的 dnsmasq 配置是这样的. (如果你没看那个链接的话)
# ipset=/0-6.com/FREEWEB
# ipset=/0-gold.net/FREEWEB
# ipset=/00.net/FREEWEB
# ipset=/0000738.com/FREEWEB
# ipset=/0001688.com/FREEWEB
# ipset=/000219.com/FREEWEB
# ipset=/0007.net/FREEWEB
# ipset=/000dn.com/FREEWEB
# ... 总共有八千条左右.
# ipset=/zzz4.com/FREEWEB
# ipset=/zzzj.com/FREEWEB
# ipset=/zzzmode.com/FREEWEB
# ipset=/zzzyb.com/FREEWEB
# ipset=/zzzyit.com/FREEWEB
# ipset=/zzyjs.com/FREEWEB
# ipset=/zzyzphoto.com/FREEWEB
# ipset=/zzz4.com/FREEWEB
# ipset=/zzzj.com/FREEWEB
# ipset=/zzzmode.com/FREE
# server=/#/8.8.8.8#53
我期望的是, 符合这些 ipset, 就不要用 8.8.8.8#53 来解析了.
我之前的做法是, 将所有的 ipset 全部替换为: server=/zzzmode.com/114.114.114.114,
生成一份新的 config, 让 dnsmasq 载入.
但是, 我觉得这样很笨, 对吧? 我们不需要两份同样的 list (一份 7000 条, 两份 14000 了)
我们可以直接通过 iptables 来做这个事情?
zw963
on 6 Sep 2017
大概看了下，通过ipset应该是可以完成这个任务的，分别用名单里的地址和不在名单的地址，看看dig返回的时间，我刚刚只是象征性的加了条chinaroute，是可以分流的。
我明白了，这样直接用dnsmasq处理，应该是有问题的，大概应该在dnsmaq上游添加一个服务器来干这事，比如chinadns或者overture来处理，无论用白名单模式还是黑名单模式。
baggiogogo
on 6 Sep 2017
@baggiogogo
我明白了，这样直接用dnsmasq处理，应该是有问题的，大概应该在dnsmaq上游添加一个服务器来干这事，比如chinadns或者overture来处理，无论用白名单模式还是黑名单模式。
但是 tcp ipset rule 可以的. 参见这些代码:
# 如果访问 VPS 地址, 直接返回.
$ipt -A SHADOWSOCKS -d SS_SERVER_IP -j RETURN
# 如果访问的域名在 FREEWEB 中, 直接返回.
$ipt -A SHADOWSOCKS -p tcp -m set --match-set FREEWEB dst -j RETURN
# 如果没有在之前的 rule 中 RETURN, 将执行下面的 rule.
# 这个 rule 将转发所有的 tcp 请求到 ss-redir 的本地端口.
$ipt -A SHADOWSOCKS -p tcp -j REDIRECT --to-ports SS_LOCAL_PORT
# 在 NAT 的初期阶段 (prerouting 阶段) 应用 SHADOWSOCKS chain 中的 tcp 规则.
$ipt -I PREROUTING 1 -p tcp -j SHADOWSOCKS
@baggiogogo , 经过再三实验, 已经确定, 当 w3m www.google.com 时, udp/tcp 均走的 ss-redir, 但是当
w3m www.baidu.com 时, 只有 dns 走的 redir.
完整的结论就是:
- dnsmasq 中, ipset 指定如下:
# ipset=/0-6.com/FREEWEB
# ipset=/0-gold.net/FREEWEB
# ipset=/00.net/FREEWEB
# ipset=/0000738.com/FREEWEB
# ipset=/0001688.com/FREEWEB
# ipset=/000219.com/FREEWEB
# ipset=/0007.net/FREEWEB
# ipset=/000dn.com/FREEWEB
# ... 总共有八千条左右.
# ipset=/zzz4.com/FREEWEB
# ipset=/zzzj.com/FREEWEB
# ipset=/zzzmode.com/FREEWEB
# ipset=/zzzyb.com/FREEWEB
# ipset=/zzzyit.com/FREEWEB
# ipset=/zzyjs.com/FREEWEB
# ipset=/zzyzphoto.com/FREEWEB
# ipset=/zzz4.com/FREEWEB
# ipset=/zzzj.com/FREEWEB
# ipset=/zzzmode.com/FREE
# server=/#/8.8.8.8#53
- FREEWEB 是一个 ipset,
ipset -N FREEWEB iphash, 这里iphash类型是否有错? iptables -t nat -A SHADOWSOCKS -p tcp -m set --match-set FREEWEB dst -j RETURN生效.
所有国内域名 tcp 数据均直连, 国外域名走代理.iptables -t mangle -A SHADOWSOCKS -p udp -m set --match-set FREEWEB dst -j RETURN没有生效, 国内域名也走代理.
zw963
on 7 Sep 2017
All cooperator for this issue, help resolve this. thanks.
@madeye , @chenhw2 , @icymind , @odkrys, @baggiogogo.
I add a working new example here, which is worked now, only one issue, w3m www.baidu.com, use ss-redir
udp relay to resolve DNS, but what we expect is, use direct connection.
zw963
on 7 Sep 2017
Try remove this line
iptables -t mangle -A OUTPUT -p udp -j SHADOWSOCKS_MARK
your udp rules only relay dns packet.
--on-ip 192.168.50.1
This option will be needed when you try to relay normal udp packet.
Specifically youtube application.
There's no way to turn off quic packet on smartphone.
odkrys
on 7 Sep 2017
Try remove this line
iptables -t mangle -A OUTPUT -p udp -j SHADOWSOCKS_MARK
不行, 注释了这一样, 所有外网都访问不了了.
zw963
on 7 Sep 2017
@odkrys, Following is what you means?
iptables -t mangle -A SHADOWSOCKS -p udp --dport 53 -j TPROXY -d 8.8.8.8 --on-port 1080 --on-ip 192.168.50.1 --tproxy-mark 0x01/0x01
this option seem like optional for my rule, use it or not use it, not affect my router to work?
zw963
on 7 Sep 2017
It isn't need for dns packet.
Does your youtube app work properly now?
As far as I know, only google use QUIC packet (udp/443).
I'm not chinese so I can't test in gfw environment.
Anyway, in my case, QUIC packets didn't relay to VPS without that optional rule.
So, youtube app was loaded but video didn't play.
Edit. I forgot this info.. If you was using ss-redir on 0.0.0.0:port, your port was opened to world!
http://www.yougetsignal.com/tools/open-ports/
So, I changed it to 192.168.1.1.
127.0.0.1 didn't work to me to relay QUIC packet.
odkrys
on 7 Sep 2017
@zw963
抱歉啦，无法复制你的环境，我再次确认了下，我这里无论dns还是网页，都是分流成功的。
我用的是chinadns+dnsmasq的方案
如果只用dnsmasq我能想到使你正常分流dns的办法，也只有你所说的笨办法了。
baggiogogo
on 7 Sep 2017
首先感谢@madeye 更新了指导
@zw963 现在完整的按照这个指导操作看看，我测试一切正常，不用OUTPUT
iptables -t mangle -N SHADOWSOCKS
ip route add local default dev lo table 100
ip rule add fwmark 1 lookup 100
iptables -t mangle -A SHADOWSOCKS -d 0.0.0.0/8 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 10.0.0.0/8 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 127.0.0.0/8 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 169.254.0.0/16 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 172.16.0.0/12 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 192.168.0.0/16 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 224.0.0.0/4 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 240.0.0.0/4 -j RETURN
iptables -t mangle -A SHADOWSOCKS -p udp --dport 53 -j TPROXY --on-port 1080 --tproxy-mark 0x01/0x01
iptables -t mangle -A PREROUTING -j SHADOWSOCKS
baggiogogo
on 7 Sep 2017
Edit. I forgot this info.. If you was using ss-redir on 0.0.0.0:port, your port was opened to world!
Yes, I change it yesterday ... maybe I should revert that commit.
Does your youtube app work properly now?
As far as I know, only google use QUIC packet (udp/443).
I test my Youtube app several hours ... (with --on-ip 192.168.50.1), seem like worked fine.
I will test the effect if not add this option later.
zw963
on 7 Sep 2017
@zw963 现在完整的按照这个指导操作看看，我测试一切正常，不用OUTPUT
iptables -t mangle -N SHADOWSOCKSip route add local default dev lo table 100
ip rule add fwmark 1 lookup 100.....
嘿, @baggiogogo , 你用这个竟然工作正常? 太奇怪了.
我想确认下, 你是不是在你的路由器里应用的这些 rule ?? 难道只是 Linux 当前主机
执行这些 rule, 然后本机上网?
@madeye , 我刚刚也看了你的新 guide, 也测试了, 还是上不了外网.
我发现, 应该是使用你的 guide, 没有 任何数据包被成功转发给 ss-redir(1080) ...
zw963
on 7 Sep 2017
@zw963
我用的树莓派，作用等同于路由，不是本机上网。
事实上你遇到的，还有隔壁安卓那个关于udp转发不工作的问题，以前我也遇到过，必须加OUTPUT才能工作，但我不依赖于udp转发，所以我没太在意。
但是今天我又尝试了楼上不用OUTPUT的iptables，它确实可以工作正常，因为期间我换过树莓派操作系统（目前是ubuntu-server），以前的环境不存在了，无法复现问题，所以还是觉得以@madeye的指导为准，可能这是个特殊不知名的原因，不是普遍现象，以免误导。
baggiogogo
on 7 Sep 2017
@baggiogogo , 好吧, 算了, 好歹有一个能用的就行了, 这个 issue 的主要目的
是将 ss-tunnel 移除. 顺便问下, ss-redir + iptables 单个怎么也应该比 ss-redir+ ss-tunnel
好点? 每次查询, 后者会多请求一次连接? (我指的, ss-tunnel 单独发送一次连接, 查询 DNS
, 但是 ss-redir, 一个连接就可以了), 不知道理解对不对?
zw963
on 7 Sep 2017
@zw963
普通使用层面我觉得不会有什么差别，哪个顺手使哪个。
baggiogogo
on 7 Sep 2017
@madeye , @chenhw2 , @icymind , @odkrys, @baggiogogo
这个问题算是解决了, 不过有关 UDP 的 rule 原理仍旧没搞清楚, 一头雾水, 总是不爽.
所以想继续借这块宝地, 争取把那几条跟 udp relay 有关的 rule 也搞清楚.
下面是我的分析, 欢迎指正错误!
第一条 rule 以及分析
iptables -t mangle -A SHADOWSOCKS_UDP -p udp --dport 53 -j TPROXY --on-port 1080 --on-ip 192.168.50.1 --tproxy-mark 0x01/0x01
# 几个需要澄清的地方:
# 1. --dport 53 -d 8.8.8.8 这些是相对于宿主机来说的, 即: client.
# 2. TPROXY only works in iptables PREROUTING-chain, 即: 在数据包进入路由器时, 使用 tproxy 进行代理.
# 猜测:
# 1. 这条规则, 在数据包进入路由器时被应用.
# 2. --dport 53, 表示进入的包, 目标端口是 53, 也就是 DNS 包.
# 3. --on-ip 192.168.50.1, 表示进入的包, 目标 ip 就是路由器的地址, 即: 192.168.50.1
# 4. --on-port 是 tproxy 模块要代理到的目标, 这里是 1080, 没错了, 它和 --tproxy-mark 0x01/0x01
# 一起配合工作, 表示, 如果有数据包被 mark 为 0x01/0x01, 就转发到 1080 端口
# 这一步, 只是完成了 tproxy 代理的策略, 并没有任何 set mark 操作发生.
第二条 rule 以及分析:
iptables -t mangle -A SHADOWSOCKS_MARK -p udp -d 8.8.8.8 --dport 53 -j MARK --set-mark 1
# 猜测:
# 1. dnsmasq 收到 DNS 包之后, 转发给 8.8.8.8#53 来查询, 此时走的是路由器的 OUTPUT chain.
# 2. 所有发往地址 8.8.8.8, 端口 53 的数据包, 设定 mark 1 (也就是 0x01/0x01 等价)
# 3. 因为上一条 rule, 这些数据包转发到了本机 1080 端口, 生效!
第三条 rule
ip rule add fwmark 1 lookup 100
ip route add local default dev lo table 100
这个我没有分析, 但是之前 @icymind 已经有 解释, 我猜测, 就是为了让我上面的推测生效, 所做的一些固定操作?
找到一段英文解释是:
we can force them to be delivered locally via the loopback interface via a policy routing table.
貌似只要 wmark 1 里面的这个 1 和 iptables 里面指定的 mark 一致就可以了.
我参考的资料: (放狗搜的结果真心不多)
https://wiki.squid-cache.org/Features/Tproxy4
http://people.apache.org/~amc/tiphares/router-inline.html
欢迎指正!
zw963
on 7 Sep 2017
看样子大家真的都很忙 ...... 先关贴吧.
Thanks for all helps.
zw963
on 8 Sep 2017
老哥好心思 我也没udp转发成功的路过
swshan
on 9 Sep 2017
did anyone try the script I posted on https://github.com/shadowsocks/shadowsocks-libev/issues/1108#issuecomment-275397280?
rogers0
on 9 Sep 2017
@rogers0 , 你那个是 tcp 的 rule, 那个没问题的.
zw963
on 10 Sep 2017
@zw963 我试图实施本机的UDP透明代理，不是作为路由器的。
但是tproxy的方案不适用于本机。请问还有其他可能的方式吗？
shellus
on 15 Mar 2018
首先感谢@madeye 更新了指导
@zw963 现在完整的按照这个指导操作看看，我测试一切正常，不用OUTPUT
iptables -t mangle -N SHADOWSOCKSip route add local default dev lo table 100
ip rule add fwmark 1 lookup 100iptables -t mangle -A SHADOWSOCKS -d 0.0.0.0/8 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 10.0.0.0/8 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 127.0.0.0/8 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 169.254.0.0/16 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 172.16.0.0/12 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 192.168.0.0/16 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 224.0.0.0/4 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 240.0.0.0/4 -j RETURNiptables -t mangle -A SHADOWSOCKS -p udp --dport 53 -j TPROXY --on-port 1080 --tproxy-mark 0x01/0x01
iptables -t mangle -A PREROUTING -j SHADOWSOCKS
想问下这个规则之前你用OUTPUT链的时候提到，游戏不需要output链，而dns需要，想问下原因。
是因为dns还需要请求除VPS之外的其他服务吗？那么游戏udp链接另外一个主机的udp端口这种不算吗？
然后我试验了上述规则不加OUTPUT链，发现在vps上面nc -l -u 开一个udp端口，我本地nc x.x.x.x port 传输信息是不同的，说明udp转发用上面那个链接是失败的。（我转发的时候规则是除了53端口，都走ss的udp转发），加output链我还没试过，不知道是否可行， 另外还想问下tproxy不能用output链的原理是？
xueyichen
on 26 Nov 2018
Related issues
HenryHo2006
·
3Comments
tony1016
·
3Comments
qianguozheng
·
4Comments
msdurex
·
3Comments
yuhaiyang
·
4Comments
Most helpful comment
不用管10800，那是我个人的规则，没删。
iptables -t mangle -N SHADOWSOCKS
iptables -t mangle -N SHADOWSOCKS_MARK
ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100
iptables -t mangle -A SHADOWSOCKS -d 0.0.0.0/8 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 10.0.0.0/8 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 127.0.0.0/8 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 169.254.0.0/16 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 172.16.0.0/12 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 192.168.0.0/16 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 224.0.0.0/4 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 240.0.0.0/4 -j RETURN
iptables -t mangle -A SHADOWSOCKS -d 8.8.8.8 -p udp --dport 53 -j TPROXY --on-port 1080 --tproxy-mark 0x01/0x01
iptables -t mangle -A SHADOWSOCKS_MARK -d (服务器地址） -j RETURN
iptables -t mangle -A SHADOWSOCKS_MARK -d 0.0.0.0/8 -j RETURN
iptables -t mangle -A SHADOWSOCKS_MARK -d 10.0.0.0/8 -j RETURN
iptables -t mangle -A SHADOWSOCKS_MARK -d 127.0.0.0/8 -j RETURN
iptables -t mangle -A SHADOWSOCKS_MARK -d 169.254.0.0/16 -j RETURN
iptables -t mangle -A SHADOWSOCKS_MARK -d 172.16.0.0/12 -j RETURN
iptables -t mangle -A SHADOWSOCKS_MARK -d 192.168.0.0/16 -j RETURN
iptables -t mangle -A SHADOWSOCKS_MARK -d 224.0.0.0/4 -j RETURN
iptables -t mangle -A SHADOWSOCKS_MARK -d 240.0.0.0/4 -j RETURN
iptables -t mangle -A SHADOWSOCKS_MARK -d 8.8.8.8 -p udp --dport 53 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -p udp -j SHADOWSOCKS
iptables -t mangle -A OUTPUT -p udp -j SHADOWSOCKS_MARK
基本的，其他的自由发挥吧，不多余，OUTPUT不能用于tproxy链上。