luci-app-xray
luci-app-xray copied to clipboard
yichya
iptables规则屏蔽掉了 WAN 侧入站连接
先前的issue已有讨论。 https://github.com/yichya/luci-app-xray/issues/20#issuecomment-842441190
对比 kuoruan/luci-app-v2ray 的 iptables 规则，主要区别在于，本项目将所有路由规则写在 mangles 链下，相比之下，v2ray 、OpenClash （印象里 shadowsocks 项目也是）等大部分类似的项目都将 TCP 的转发规则放到了 nat 链下面，我认为这个可能是问题所在。 ~~但是原理我还是不懂~~
参考：
- Linux netfilter Hacking HOWTO: Netfilter Architecture
- linux - iptables REDIRECT works only for first packet - Server Fault
This table (NAT) is slightly different from the `filter' table, in that only the first packet of a new connection will traverse the table: the result of this traversal is then applied to all future packets in the same connection.
update: 不光是链不同，原理也不一样。其他项目用的是 REDIRECT ，本项目用的是 TPROXY。这东西文档和用例太少了……
#51 修复了一部分，但是通过 DNAT 实现的端口映射还是没有正确处理。具体表现为， SYN 包可以正常转发到达目标设备，但 SYN ACK 被 mangle 链中的规则拦截转发给 xray，然后估计被当成无效包丢弃了。
刚刚测试最新版的master分支编译，依然存在这个问题
我openwrt上运行了个vpn服务器，一启动xray，从wan入站的vpn连接就断了
但是我发现在bypass上添加wan端的ip后，那个ip过来的包就可以正常入站了，感觉是因为入站流量被重定向了？
不太熟iptables，特别是tproxy，完全不知道怎么整... 看了半天防火墙规则，没看懂，加了bypass之后好像是在ipset里面加了个对应的ip，然后iptables匹配上之后直接return了。难道是wan进来的流量也被重定向到xray去处理了？
卧槽我才发现这个pr没有合并进来🤣 晚点我把这个pr拿下来再编译一个试试（
刚刚测试最新版的master分支编译，依然存在这个问题
确实，还没修
我openwrt上运行了个vpn服务器，一启动xray，从wan入站的vpn连接就断了
但是我发现在bypass上添加wan端的ip后，那个ip过来的包就可以正常入站了，感觉是因为入站流量被重定向了？
这么做确实能绕过这个问题，但其实比较建议写一个匹配设备和端口的规则 return，或者 cherry-pick 一下 #51
不太熟iptables，特别是tproxy，完全不知道怎么整... 看了半天防火墙规则，没看懂，加了bypass之后好像是在ipset里面加了个对应的ip，然后iptables匹配上之后直接return了。难道是wan进来的流量也被重定向到xray去处理了？
tproxy 用的是 mangle 表，mangle 确实是这样的，原理其实我也不是完全理解（
一些有用的参考资料：
Transparent proxy - shadowsocks-libev/README.md at master · shadowsocks/shadowsocks-libev
For anyone still affected by this issue, you can checkout my fork (https://github.com/ttimasdf/luci-app-xray/releases) which completely rewrites the firewall generation code for clarity and also addresses this bug.