Replies: 9 comments 5 replies
-
|
由于任何流量最终要发往实际的网络（IP 之间的通信），即使从 freedom 发出域名地址（由系统解析为 IP）的请求，响应也只会是 IP 地址，造成请求与响应的地址不匹配。 |
Beta Was this translation helpful? Give feedback.
-
测试过的确如此
当然如果做成全部 symmetric NAT 也许不是问题（这个是 XUDP 实现前的临时解决方案），不过这样的话就缺失了 XUDP 的可 cone NAT 特性。
这个相当于以前的行为（客户端强制对 UDP 地址进行解析再发送到服务端）的可控制版，但是有一定几率会出现客户端错误配置（这个情况应该很少，比如服务端为单栈服务器但是客户端设置为了相反的情况）导致的代理 UDP 连接问题。（印象中 v2fly 那边引入强行解析域名的
这个的确属于最复杂的，而且会引入和其它代理工具交互的兼容性问题。不过如果不考虑兼容性并且假定客户端和服务端都能很快更新到最新的话能够做到这个特性还是很有吸引力的。 如果这样做的话，不一定是 freedom，任何在到达下一个端点时必须强制解析的情况应该也可以这样做（当然是个设想，可能不太完善）：
|
Beta Was this translation helpful? Give feedback.
-
|
我这里测试也是同样的效果 不使用fakedns则正常 |
Beta Was this translation helpful? Give feedback.
-
这么说的话，freedom 的 redirect、freedom 的 domainStrategy 等，可能一直以来都有此问题。
是否想得太复杂，简单替换一下地址应付一下就算了https://github.com/SagerNet/sing/blob/3f6c423e76f0c33bcb926b0d69168734951db23f/common/bufio/nat.go#L82-L95
只能在客户端上这样做，如果中转、服务端这样做就会造成客户端出现此 issue 所述的问题了。不过这个不应该考虑，也没有人考虑。 |
Beta Was this translation helpful? Give feedback.
-
大部分情况应该没有问题，只要这个映射包含从服务端哪个端口发出去的信息避免回包时映射串台就行。（比如通过代理访问一个开了 HTTP/3 的同时跑多个网站的多个域名指向同一个 IP 的服务器） |
Beta Was this translation helpful? Give feedback.
-
这种一般不会使用同一个本地地址。如果复用本地地址，现在的屎山架构只能根据第一个目标地址进行（#1011 或许可以解决 fake DNS，但对于其他问题没有帮助）。 |
Beta Was this translation helpful? Give feedback.
-
明白了。
同意，要几乎解决 UDP 在代理里面的地址问题真的比较挠头。就先按照简单的做出来看看效果？
|
Beta Was this translation helpful? Give feedback.
-
|
Fake DNS这种侵入性的解决方案(或者难听点叫歪门邪道)不可避免的问题 谷歌上搜这个词 最前面还是两家ray的文档 除了继续堆史山加入一些侵入性更强的特性基本没法解决问题 我觉得这不算核心bug( |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
细想了下，如果会用到域名的情况绝大部分应该是应用访问服务端进行数据交换的时候，P2P 类型应该没怎么用到域名而是直接用的 IP:port，这样代理域名的时候应该不用太担心 Fullcone 的问题（推测，如果有误还请指出）。 这样的话其实会不会简单一些：
|
Beta Was this translation helpful? Give feedback.
-
|
曾经的方案基础上改改？ #1011 |
Beta Was this translation helpful? Give feedback.
-
|
应该可以 |
Beta Was this translation helpful? Give feedback.
-
|
要改 #1011 的话除了 outbound handler 以外 freedom 那里也得单独维护一份逻辑。实际上不使用 fake IP freedom 目标地址也可能是域名，所以还得有对非 fake IP 的处理逻辑。还有的话映射记录不同的域名对应同一个 IP 的话怎么办。 从 sing-box 的和 xray 的实践来看，只对第一个包的目标地址作 域名-IP映射 理论上是会有坑，但是在实际使用中并没有人反馈过 fake IP 被发到远端的问题。outbound handler 已经是这样的处理逻辑，不如再简单处理一下 freedom 即可。 diff --git a/proxy/freedom/freedom.go b/proxy/freedom/freedom.go
index dcb72b0..57cb4d5 100644
--- a/proxy/freedom/freedom.go
+++ b/proxy/freedom/freedom.go
@@ -12,7 +12,6 @@ import (
"github.com/pires/go-proxyproto"
"github.com/xtls/xray-core/common"
"github.com/xtls/xray-core/common/buf"
- "github.com/xtls/xray-core/common/dice"
"github.com/xtls/xray-core/common/errors"
"github.com/xtls/xray-core/common/net"
"github.com/xtls/xray-core/common/platform"
@@ -93,7 +92,7 @@ func (h *Handler) resolveIP(ctx context.Context, domain string, localAddr net.Ad
if len(ips) == 0 {
return nil
}
- return net.IPAddress(ips[dice.Roll(len(ips))])
+ return net.IPAddress(ips[0])
}
func isValidAddress(addr *net.IPOrDomain) bool {
@@ -227,7 +226,7 @@ func (h *Handler) Process(ctx context.Context, link *transport.Link, dialer inte
}
return proxy.CopyRawConnIfExist(ctx, conn, writeConn, link.Writer, timer, inTimer)
}
- reader := NewPacketReader(conn, UDPOverride)
+ reader := NewPacketReader(conn, destination, UDPOverride)
if err := buf.Copy(reader, output, buf.UpdateActivity(timer)); err != nil {
return errors.New("failed to process response").Base(err)
}
@@ -245,7 +244,7 @@ func (h *Handler) Process(ctx context.Context, link *transport.Link, dialer inte
return nil
}
-func NewPacketReader(conn net.Conn, UDPOverride net.Destination) buf.Reader {
+func NewPacketReader(conn net.Conn, destination net.Destination, UDPOverride net.Destination) buf.Reader {
iConn := conn
statConn, ok := iConn.(*stat.CounterConnection)
if ok {
@@ -258,6 +257,7 @@ func NewPacketReader(conn net.Conn, UDPOverride net.Destination) buf.Reader {
if c, ok := iConn.(*internet.PacketConnWrapper); ok && UDPOverride.Address == nil && UDPOverride.Port == 0 {
return &PacketReader{
PacketConnWrapper: c,
+ Destination: destination,
Counter: counter,
}
}
@@ -266,6 +266,7 @@ func NewPacketReader(conn net.Conn, UDPOverride net.Destination) buf.Reader {
type PacketReader struct {
*internet.PacketConnWrapper
+ net.Destination
stats.Counter
}
@@ -283,6 +284,9 @@ func (r *PacketReader) ReadMultiBuffer() (buf.MultiBuffer, error) {
Port: net.Port(d.(*net.UDPAddr).Port),
Network: net.Network_UDP,
}
+ if d.String() == r.PacketConnWrapper.Dest.String() && r.Destination.Address.Family().IsDomain() {
+ b.UDP = &r.Destination
+ }
if r.Counter != nil {
r.Counter.Add(int64(n))
}
|
Beta Was this translation helpful? Give feedback.
-
|
还有就是哪位熟悉的说说 clash fake IP 的 STUN 实际上是个什么问题，为什么都对 STUN 域名跳过 fake IP 了？ |
Beta Was this translation helpful? Give feedback.
-
问题描述
OpenWrt 上 Xray 作为透明代理，当 FakeDNS 生效时，发往域名的 UDP 数据可以正常发出送达，但是回程 UDP 数据没法收到，抓包显示回程包里远程UDP服务器的地址和去程不匹配。
关闭 FakeDNS，或者直接使用 IP 则 UDP 数据可以正常收发。
环境配置
UDP client --> Xray client on OpenWrt --(VLESS+REALITY)-> Xray server --> UDP server
UDP client: macOS 14.4.1 10.0.0.154
Xray client: v1.8.10 x86_64 OpenWrt 23.05.3; Passwall2 1.28-5 10.0.0.1
Xray server: v1.8.10 x86_64 Debian 12; Nginx 1.22.1 x.x.x.x
UDP server: x86_64 Ubuntu 22.04 141.141.141.141
客户端配置(Passwall2 生成，只列出相关部分）
{ "dns": { "disableFallback": true, "queryStrategy": "UseIP", "disableFallbackIfMatch": true, "servers": [ ... { "port": 15354, "_flag": "China", "address": "127.0.0.1", "queryStrategy": "UseIP", "domains": [ "geosite:cn" ] }, { "domains": [ "geosite:geolocation-!cn", ], "_flag": "Proxy", "address": "fakedns" } ], "disableCache": false, "tag": "dns-in1" }, "fakedns": [ { "ipPool": "198.18.0.0\/16", "poolSize": 65535 } ], "outbounds": [ { "_flag_tag": "...", "_flag_proxy": 0, "_flag_proxy_tag": "nil", "settings": { "vnext": [ { "port": 443, "users": [ { "flow": "xtls-rprx-vision", "encryption": "none", "id": "d3d3b1....164a05d", "level": 0 } ], "address": "..." } ] }, "streamSettings": { "network": "tcp", "tcpSettings": { "header": { "type": "none" } }, "sockopt": { "tcpFastOpen": true, "mark": 255, "tcpNoDelay": true }, "realitySettings": { "publicKey": "H...I", "spiderX": "\/", "serverName": "...", "shortId": "d...6", "fingerprint": "chrome" }, "security": "reality" }, "mux": { "enabled": false }, "protocol": "vless", "tag": "..." }, ], ... }服务器端配置
{ ... "inbounds": [ { "listen": "/dev/shm/reality.socket,0666", "protocol": "vless", "settings": { "clients": [ { "id": "d...d", "flow": "xtls-rprx-vision" } ], "decryption": "none", "fallbacks": [ { "dest": 8004, "xver": 1 } ] }, "streamSettings": { "network": "tcp", "tcpSettings": { "acceptProxyProtocol": true }, "security": "reality", "realitySettings": { "show": false, "dest": "/dev/shm/nginx.socket", "xver": 1, "serverNames": [ "vr.tcp.one" ], "privateKey": "6...0", "shortIds": [ "d...6" ] }, "sockopt": { "tcpMptcp": false, "tcpNoDelay": true } }, "sniffing": { "enabled": true, "destOverride": [ "http", "tls" ], "domainsExcluded": [ "courier.push.apple.com" ] } }, ... }重现步骤
nc客户端只能看到自己的 “Send" 消息，看不到 UDP 服务器回应的 "Respond" 消息。
UDP 服务器端能看到完整的消息
Xray server 上日志看到发往域名
OpenWrt 上在 LAN (eth0) 抓包可以看到：
去程是客户端 10.0.0.154 发往 FakeDNS 地址 198.18.134.159
回程是 UDP服务器的真实地址 141.141.141.141 发往 10.0.0.154，并没有经过 FakeDNS 处理。
相关参考
之前有类似症状的 issue #2962，但是环境和用例不同，并不确定是不是同一问题。
Beta Was this translation helpful? Give feedback.
All reactions