DNS：特定环境下fakeIP失效问题

[Meo597]

完整性要求

• 我保证阅读了文档，了解所有我编写的配置文件项的含义，而不是大量堆砌看似有用的选项或默认值。
• 我提供了完整的配置文件和日志，而不是出于自己的判断只给出截取的部分。
• 我搜索了 issues, 没有发现已提出的类似问题。
• 问题在 Release 最新的版本上可以成功复现

描述

细节：
fakeIP原理是Xray污染DNS，给客户端返回特定IP段
若客户端发往xray的IP因各种原因被修改，fakeIP即失效

详见代码

			if err == nil && d.shouldOverride(ctx, result, sniffingRequest, destination) {
				domain := result.Domain()
				errors.LogInfo(ctx, "sniffed domain: ", domain)
				destination.Address = net.ParseAddress(domain)
				protocol := result.Protocol()
				if resComp, ok := result.(SnifferResultComposite); ok {
					protocol = resComp.ProtocolForDomainResult()
				}
                                // fakeIP依赖于客户端发往xray IP`ob.Target.Address`的准确性
				isFakeIP := false
				if fkr0, ok := d.fdns.(dns.FakeDNSEngineRev0); ok && fkr0.IsIPInIPPool(ob.Target.Address) {
					isFakeIP = true
				}
				if sniffingRequest.RouteOnly && protocol != "fakedns" && protocol != "fakedns+others" && !isFakeIP {
					ob.RouteTarget = destination
				} else {
					ob.Target = destination
				}
			}

修复建议
入站时选择不相信客户端带来的ip，强行用xray的dns重解析一次，因为可命中缓存因此无开销
See demo: Meo597@d5b80c7
(此Demo是之前专为realIP修复，若确认fakeIP需要PR，我可再次修改)

重现方式

DNS被污染触发条件：

PC端Chrome系浏览器，电脑网卡配置为知名公共DNS，且他们支持DOH
或 Android系统自动配置了安全DNS
或手机端App接入了天朝特色httpdns SDK

影响到Xray的条件（绕过fakeIP的逻辑）：

透明代理 + fakeIP
routeOnly=true

实际不利影响：
因fakeIP失效，若远端xray节点没有sniff+destOverride+routeOnly=false
则目标网站仍被污染，导致访问失败

PS：透明代理+realIP同理

客户端配置

N/A

服务端配置

N/A

客户端日志

N/A

服务端日志

N/A

[RPRX]

虽然客户端发起的 TCP 不一定就是 TLS 或 plain HTTP，甚至不一定是 TCP 或 QUIC，而是奇形怪状的 UDP

[Fangliding]

什么玩意 浏览器DOH解析出来的不是正常IP？正常IP直接过去了哪来被Xray污染的说法 而且fakedns你不override
不就是想推你那个解析 已经说过问题了

[Meo597]

电脑网卡设阿里，chrome系浏览器默认开doh为阿里的

安卓手机系统设置默认开安全dns

一堆垃圾app有httpdps sdk

都会导致解析错误

@Fangliding 你不懂就不要乱评价

[Fangliding]

哦是GFW污染 你牵头说了个Xray污染搞混了
解决问题很简单就是sniff override就行了
“入站时选择不相信客户端带来的ip，强行用xray的dns重解析一次”
和override就是干的一样的事 只是发出去的是域名还是重解析的ip的区别
你偏要搞这么刁钻的条件把本地把目标地址解析为IP发出去这个东西表达出来 这个前段时间就已经讨论过 dup了

[Meo597]

客户端发往Xray的数据包，IP在特定情况下就可能是错的，要么是CDN不友好，要么是被污染

照你这么说那还搞啥routeOnly直接删了得了，凡是能嗅探出来的，统统换成域名

你没考虑过换成域名需要多一次DNS解析吗

[Fangliding]

首先服务端解析域名开销很小 大概只有十几二十ms而且同样有缓存
对 你这个可以解决这个刁钻情况 我为什么对类似方向的功能意见这么大 因为以前的我折腾这些东西对着几个strategy发呆思考它们的含义是什么组合起来会发生什么很绝望 所以类似作用的参数越少越好 如果要加最好只多一个参数 一次不改好 以后继续加 后人再来看问号更多 拿不好就别动
而且这个功能他们好像讨论可以套一层完成 那个issue被关掉了 你这个也一样 dup就是dup 要reopen也是open之前那个
你这个commit 在shouldoverride的情况下(里面就一堆条件) 然后routeonly启用 再用sniff来的域名 去解析并重置地址 这个条件太细分了 所以我觉得不行

[Meo597]

本地xray解析域名，显然不会让节点xray产生dns缓存

routeOnly=true就是为了防止节点xray产生二次DNS请求

但显然它不完美，它没考虑到客户端(pc/phone)请求的IP或许不可信

[Meo597]

我拿xray充当透明代理用没多久，配下来发现有这样那样的缺陷，显然它不够完美

这些改动不做行不行？不做当然不影响爬墙，总归能保证你打开Google
但性能或者功能上始终有缺陷

就像我提交的这个issues，如果不改，利用现有选项，强制把ip换成域名行不行？
当然没问题
但有人大价钱买的HK CN2GIA，首次访问谷歌延迟可能多了十几浪费在DNS上，体验秒变美西

---

我这几天提交的关于DNS的PR和issue都是为了解决这些历史遗留问题

只需要很小的改动，让它性能上有更好的表现

这些缺陷根源在于当初*ray系设计，出发点只是一个PC端软件
显然没准备好在路由器充当网关

singbox作者 @nekohasekai 以前弄的 routeOnly 也是为了追求极致性能

至于配置选项太多的问题，完全可以更新官方example，针对每个用途给最佳指南

这些情景不是刁钻，是为了追求最佳体验不得不这么干，别人没发现是因为他们菜

[patterniha]

@Meo597

Your problem is similar to my problem, and this problem has been solved.

You want your domains be resolved only with trusted-built-in-dns, and use that IP in server too.

///

Solution 1: (one name-to-ip convertor, but require redirect-socks-in/out)

you should set routeOnly=false for main-inbound but set routeOnly=true for redirect-inbound and then use #4423 (comment), it means:

"inbounds": [
    {
      "tag": "main-socks-in",
      "port": 10808,
      "protocol": "socks",
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"],
        "routeOnly": false
      },
      "settings": {"udp": true}
    },
    {
      "tag": "redirect-socks-in",
      "port": 10909,
      "protocol": "socks",
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"],
        "routeOnly": true
      },
      "settings": {"udp": true}
    }    
],
"outbounds": [    
    {
      "tag": "name-to-ip",
      "protocol": "freedom",      
      "settings": {"domainStrategy": "ForceIP"},
      "streamSettings": {"sockopt": {"dialerProxy": "redirect-socks-out"}}
    },
    { 
      "tag": "redirect-socks-out",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 10909 // connect to redirect-socks-in    
          }
        ]
      }
    },
    {
      "tag": "proxy-1",
      ...
    },
    {
      "tag": "proxy-2",
      ...
    },
    ...
]

///

Solution 2: (no need for redirect-socks-in/out, but require name-to-ip convertor for each proxy)

you can omit redirect-socks-in/out in Solution 1, but you need add name-to-ip convertor for each proxy, it means:

"inbounds": [
    {
      "tag": "main-socks-in",
      "port": 10808,
      "protocol": "socks",
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"],
        "routeOnly": false
      },
      "settings": {"udp": true}
    }        
],
"outbounds": [    
    {
      "tag": "name-to-ip-for-proxy-1",
      "protocol": "freedom",      
      "settings": {"domainStrategy": "ForceIP"},
      "streamSettings": {"sockopt": {"dialerProxy": "proxy-1"}}
    },
    {
      "tag": "proxy-1",
      ...
    },
    {
      "tag": "name-to-ip-for-proxy-2",
      "protocol": "freedom",      
      "settings": {"domainStrategy": "ForceIP"},
      "streamSettings": {"sockopt": {"dialerProxy": "proxy-2"}}
    },
    {
      "tag": "proxy-2",
      ...
    },
    ...    
]

///

I also had another problem other than yours and that was that we have no control over "forceIP" and it can return any IP, so I added "allowUnexpectedIPs" to filter out my desired IPs.

///

I know these are not elegant, but any other solution does not have the comprehensiveness of these solutions.

[Meo597]

不，所有的域都可能被污染，你的配置文件会导致所有的流量绕一圈，而不是某个域

要么尽可能屏蔽所有DOH和httpclient，这显然不可能
要么让本地或Xray把IP替换为域名，这显然会增加延迟

让xray强制把所有域重新解析一次是唯一办法。

[patterniha]

The only way is to let xray force all domains to be re-parsed.

i omit routing section in my solutions, because, you are free to do whatever you want with routing.

I also think you still don't understand how "dialerProxy" works.

if you want to force all domains to be re-parsed just add this rule to the top of routing-rules in solution 1:

"routing": {
    "rules": [                  
      {"outboundTag": "name-to-ip",
       "inboundTag": ["main-socks-in"]
      },
      ...
    ]
}

[Meo597]

不，我并不关心dialerProxy是否能够满足需求

透明代理 + realIp下，我的用例是最佳实践，因为减少了一次DNS解析，它具有最好的性能

因此它应该被重视，所以它应该享有一个独立的开关，直截了当地解决客户端DNS被污染问题

其它人没发现，单纯是因为他们菜

[patterniha]

Transparent proxy + realIp is the best practice for my use case

What does it have to do with transparent proxy?
You can still use transparent proxy + real-IP, just use "main-tproxy-in" instead of "main-socks-in".
also, only one DNS resolution is used, and the performance is the same but it has more flexibility.
"dialerProxy" is just an internal feature in Xray-core. I think the name "dialerProxy" has confused you.

"inbounds": [
    {
      "tag": "main-tproxy-in",
      "port": 12345,
      "protocol": "dokodemo-door",
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"],
        "routeOnly": false
      },
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "streamSettings": {
        "sockopt": {
          "tproxy": "tproxy"
        }
      }
    },
    {
      "tag": "redirect-socks-in",
      "port": 10909,
      "protocol": "socks",
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"],
        "routeOnly": true
      },
      "settings": {"udp": true}
    }    
],
"outbounds": [    
    {
      "tag": "name-to-ip",
      "protocol": "freedom",      
      "settings": {"domainStrategy": "ForceIP"},
      "streamSettings": {"sockopt": {"dialerProxy": "redirect-socks-out"}}
    },
    { 
      "tag": "redirect-socks-out",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 10909 // connect to redirect-socks-in    
          }
        ]
      }
    },
    {
      "tag": "proxy-1",
      ...
    },
    {
      "tag": "proxy-2",
      ...
    },
    ...
],
"routing": {
    "rules": [                  
      {"outboundTag": "name-to-ip",
       "inboundTag": ["main-tproxy-in"]
      },
      ...
    ]
}

[patterniha]

This does exactly what "ignoreClientIp" does in #4423,
but instead of inbound, It does it in outbound and then redirect to another inbound again.
because it convert domains to IP after routing, it has more flexibility, and it allows you to not convert some domains if you want.

also, if you don't like redirect, you can use solution 2, but you need to make some appropriate changes to the routing.