Xray-core icon indicating copy to clipboard operation
Xray-core copied to clipboard

希望WireGuard入站可以处理ICMP数据

Open g-u-a-n opened this issue 3 months ago • 13 comments

首先感谢Xray项目为我提供的便利,感谢参与项目开源建设大佬们的付出

目前我正在考虑使用WireGuard组网,得益于Xray强大的入站/路由/出站能力,提供了众多丰富的玩法,因此我想使用Xray来提供WireGuard入站,再通过路由策略灵活自由的控制出站策略

目前实践的两种方式是:

方式1:客户端 -> wireguard入站 -> 路由策略 -> 出站

方式2:客户端 -> dokodemo-door入站 -> 路由策略 -> 出站 -> 本地wireguard

以上两种方式均可实现使用WireGuard组网,区别是:

方式1:当处理ICMP数据,Ping目标IP地址,实际上是Ping客户端 <-> Xray,而并非客户端 <-> 目标IP地址,并且即使目标IP地址不合理(不存在)也可以Ping通,因为实际是Ping的Xray端地址

方式2:可以正常处理ICMP数据,但是路由策略受限,因为大部分数据细节(目标IP地址、目标端口等)已经在客户端被加密了

方式1可以完整的使用路由策略,然而美中不足的是无法处理ICMP数据,某些时候想通过Ping来简单判断目标通断状态无法满足

希望有机会能够使得WireGuard入站,可以处理ICMP数据

g-u-a-n avatar Sep 24 '25 02:09 g-u-a-n

核心内部的各种系统都只被设计用于处理tcp和udp数据 这个wg甚至自己都还有点问题

Fangliding avatar Sep 24 '25 02:09 Fangliding

如果要处理 ICMP 则只改一个 WireGuard 入站不够,还要 VLESS 代理协议能处理 ICMP

本来想着用 0 代表 TUN 数据,但是反向代理的下一步设计又想把 0 定义为“无意义”,我再想想吧。。。

RPRX avatar Sep 24 '25 04:09 RPRX

如果要处理 ICMP 则只改一个 WireGuard 入站不够,还要 VLESS 代理协议能处理 ICMP

本来想着用 0 代表 TUN 数据,但是反向代理的下一步设计又想把 0 定义为“无意义”,我再想想吧。。。

感谢大佬的计划支持,这个使用场景有点小众,并且作为一款代理工具来说处理ICMP可能显得有点无意义;

但是对于我来说,Xray已经不仅仅是一款代理工具,它有强大的VLESS协议等支撑,丰富的路由策略,使其用途丰富多样;它可以反向代理、用作DNS服务器、躲避网络审查、组网等等,甚至我有将它应用在企业一些网络请求处理安全策略中;单拿出来一个Xray可能做的有限,可能会有其他替代选择,但是集多种能力为一体就是Xray最大的特色价值;

提到这个issues是想着既然有支持WireGuard入站,还是希望能更完美一点,像WireGuard自身那样可以路由所有流量而无关协议;

当然这个完美的想法背后是需要大佬的辛苦付出实现,再次感谢大佬们的开源贡献;愿Xray更加强大!

g-u-a-n avatar Sep 24 '25 06:09 g-u-a-n

这可不止往协议定义里加一个ip或者icmp payload的事

Fangliding avatar Sep 24 '25 08:09 Fangliding

这可不止往协议定义里加一个ip或者icmp payload的事

其实我在想按端口为 0 的 UDP 来处理也行

RPRX avatar Sep 24 '25 12:09 RPRX

因为都是允许丢包,目前 Xray-core 中 UDP 端口 0 是没有定义的,然后那些特殊域名(Mux 等)应当是端口为 0 的 TCP

RPRX avatar Sep 24 '25 12:09 RPRX

只剩个小问题就是除了 ICMP 是否还有代理其它 IP 包的需求,如果是的话则不应只考虑 ICMP

RPRX avatar Sep 24 '25 12:09 RPRX

比如可以服务端检测一下 UDP 端口为 0 时包内不允许出现 TCP 和 UDP 的代号,其它的都放行

RPRX avatar Sep 24 '25 12:09 RPRX

我指其他地方 处理非udp和tcp通常非常麻烦 首先需要一个入站能收icmp包 tun入站 没有 中间的管道 路由系统 全部只设计了tcp与udp 出站 要能ping通 不是把载荷丢出去就了事了 更没得udp socket用 要能"连接" 得手搓处理回包 很可能再跟踪一下连接 还得考虑ray里的烂架构 回包地址更麻烦 那些恶心的udp origin src dest搞不好重新弄一道 搞完这么多 得到只是在tun入站可以ping了 或者wg可以ping了 如果说的ip包更麻烦了 嘛 反正被reopen然后就没管的feature request也不止一个两个(

Fangliding avatar Sep 24 '25 12:09 Fangliding

TUN 入站肯定是要有的,现在只是只考虑 ICMP 还是同时也考虑其它包的问题,~~感觉考虑其它包的话有点类似于真的组网了~~

~~Reopen 是作为 reminder,不重要所以不一定什么时候实现~~

RPRX avatar Sep 24 '25 12:09 RPRX

公网一般就放行 TCP UDP ICMP 还有传统VPN需要 50 51 47

Meo597 avatar Sep 24 '25 12:09 Meo597

TUN 入站肯定是要有的,现在只是只考虑 ICMP 还是同时也考虑其它包的问题,~感觉考虑其它包的话有点类似于真的组网了~

~Reopen 是作为 reminder,不重要所以不一定什么时候实现~

有条件的话,可以考虑顺便把 inbounds 源 IP 带过去,距离组网更进一步

zhi1ong avatar Oct 15 '25 11:10 zhi1ong

能处理ICMP那observatory probe也能用icmp去探测对端了

majorcheng avatar Dec 10 '25 04:12 majorcheng