Open ttimasdf opened 3 years ago
刚刚测试最新版的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 确实是这样的,原理其实我也不是完全理解(
周末研究下看看,资料好少啊😂
看了一遍 tproxy 和 connmark 的原理,把规则完全重写了一遍。测试了一下,非常稳定,端口转发也不丢包了。
参见:#194
@yichya hi, has this issue been resolved?
@yichya how to fix this? is there any workaround ?
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.
先前的issue已有讨论。 https://github.com/yichya/luci-app-xray/issues/20#issuecomment-842441190
对比 kuoruan/luci-app-v2ray 的 iptables 规则,主要区别在于,本项目将所有路由规则写在 mangles 链下,相比之下,v2ray 、OpenClash (印象里 shadowsocks 项目也是)等大部分类似的项目都将 TCP 的转发规则放到了 nat 链下面,我认为这个可能是问题所在。
但是原理我还是不懂参考:
update: 不光是链不同,原理也不一样。其他项目用的是 REDIRECT ,本项目用的是 TPROXY。这东西文档和用例太少了……