sing-box模式下dns配置似乎支持不完整

[wtfr-dot]

我在UI界面的sing-box DNS设置里使用logical类型的配置，v2rayN生成的配置似乎不完整，比如在UI界面输入下面一段：
{
"type": "logical",
"mode": "and",
"rules": [
{
"rule_set": "geosite-geolocation-!cn",
"invert": true
},
{
"rule_set": "geoip-cn"
}
],
"server": "remote",
"client_subnet": "223.5.5.5"
},
config文件里生成的段是这样的：

看起来没完全识别配置文件，v2rayN启动也没有报错，请问这个正常吗

[2dust]

把完整dns发出来

[wtfr-dot]

我昨天远程操作时没过滤log仔细看，今天重新试了一下，发现有错误提示：

UI的配置文件：
{
"servers": [
{
"tag": "remote",
"address": "8.8.8.8",
"detour": "proxy"
},
{
"tag": "local",
"address": "223.5.5.5",
"detour": "direct"
},
{
"tag": "block",
"address": "rcode://success"
}
],
"strategy": "ipv4_only",
"rules": [
{
"rule_set": [
"geosite-category-ads-all"
],
"server": "block"
},
{
"type": "logical",
"mode": "and",
"rules": [
{
"rule_set": "geosite-geolocation-!cn",
"invert": true
},
{
"rule_set": "geoip-cn"
}
],
"server": "remote",
"client_subnet": "223.5.5.5"
},
{
"rule_set": [
"geosite-cn",
"geosite-geolocation-cn"
],
"server": "local"
}
],
"final": "remote",
"independent_cache": true
}
config中生成的dns配置：
"dns": {
"servers": [
{
"tag": "remote",
"address": "8.8.8.8",
"detour": "proxy"
},
{
"tag": "local",
"address": "223.5.5.5",
"detour": "direct"
},
{
"tag": "block",
"address": "rcode://success"
},
{
"tag": "local_local",
"address": "223.5.5.5",
"detour": "direct"
}
],
"rules": [
{
"server": "block",
"rule_set": [
"geosite-category-ads-all"
]
},
{
"server": "remote",
"type": "logical",
"mode": "and"
},
{
"server": "local",
"rule_set": [
"geosite-cn",
"geosite-geolocation-cn"
]
},
{
"server": "local_local",
"domain": [
"VPS域名"
]
}
],
"final": "remote",
"strategy": "ipv4_only",
"independent_cache": true
},

[2dust]

https://github.com/2dust/v2rayN/releases/tag/6.47
升级到这个版本，然后你的dns需要修改下，rule_set是数组

{
    "servers": [
        {
            "tag": "remote",
            "address": "8.8.8.8",
            "detour": "proxy"
        },
        {
            "tag": "local",
            "address": "223.5.5.5",
            "detour": "direct"
        },
        {
            "tag": "block",
            "address": "rcode://success"
        }
    ],
    "strategy": "ipv4_only",
    "rules": [
        {
            "rule_set": [
                "geosite-category-ads-all"
            ],
            "server": "block"
        },
        {
            "type": "logical",
            "mode": "and",
            "rules": [
                {
                    "rule_set": ["geosite-geolocation-!cn"],
                    "invert": true
                },
                {
                    "rule_set": ["geoip-cn"]
                }
            ],
            "server": "remote",
            "client_subnet": "223.5.5.5"
        },
        {
            "rule_set": [
                "geosite-cn",
                "geosite-geolocation-cn"
            ],
            "server": "local"
        }
    ],
    "final": "remote",
    "independent_cache": true
}

[wtfr-dot]

2024/06/24 17:45:00 Using default config: F:\v2rayN\guiConfigs\config.json
FATAL[0000] decode config at configPre.json: dns.rules[1].client_subnet: json: unknown field "client_subnet"
FATAL[0000] decode config at configPre.json: dns.rules[1].client_subnet: json: unknown field "client_subnet"

[2dust]

升级sing-box 到1.9以上

[wtfr-dot]

已经是1.9.3

[2dust]

把产生配置发出来

[wtfr-dot]

升级到1.10版好像没有报错了，不过tun模式网络好像不正常，我先排查一下

[wtfr-dot]

找到问题了，应该是生成的dns配置文件里缺少了VPS域名解析这一项，log提示我的VPS没有这个host，没完成VPS的ip地址解析，我在UI的dns配置里加上这一项，log不报错了，tun网络也恢复了正常，但是系统生成的配置里没有我加的这一项，需要您检查一下代码

[2dust]

代码和测试都是会增加dns server local_local，用来解析vps域名
你检查config中是否有生成 local_local

[wtfr-dot]

那就很奇怪了，我检查了config配置文件是http和socks模式的dns配置，configpre这个配置是tun模式的，两个都没有local_local这个server，config的配置文件如下：
"dns": {
"servers": [
{
"address": "8.8.8.8",
"domains": [
"geosite:geolocation-!cn"
],
"skipFallback": true
},
{
"address": "223.5.5.5",
"domains": [
"geosite:cn",
"geosite:geolocation-cn"
],
"expectIPs": [
"geoip:cn"
],
"skipFallback": true
},
"1.1.1.1",
"8.8.4.4",
"149.112.112.112"
],
"disableFallbackIfMatch": true,
"queryStrategy": "UseIPv4"
},
configpre配置文件如下
"dns": {
"servers": [
{
"tag": "remote",
"address": "8.8.8.8",
"detour": "proxy"
},
{
"tag": "local",
"address": "223.5.5.5",
"detour": "direct"
},
{
"tag": "block",
"address": "rcode://success"
}
],
"rules": [
{
"server": "block",
"rule_set": [
"geosite-category-ads-all"
]
},
{ //这一个是我自己加的，而且必须在下一个logical类型的前面
"server": "local",
"domain": [
"VPS域名"
]
},
{
"server": "remote",
"type": "logical",
"mode": "and",
"client_subnet": "223.5.5.5",
"rules": [
{
"invert": true,
"rule_set": [
"geosite-geolocation-!cn"
]
},
{
"rule_set": [
"geoip-cn"
]
}
]
},
{
"server": "local",
"rule_set": [
"geosite-cn",
"geosite-geolocation-cn"
]
}
],
"final": "remote",
"strategy": "ipv4_only",
"independent_cache": true
},
目前tun模式右下角的图标有时显示地球符号，也显示singbox_tun没联网，但网络访问正常

[2dust]

看了你的这个配置，应该是用sing-box 转发到xray，这样是不会在sing-box的配置中产生vps域名解析的配置的。
如果直接使用sing-box一个core，是会产生local_local 用来解析域名

[2dust]

能否把你的配置分享出来，发到 captainIronng@protonmail.com

[wtfr-dot]

那就对了，目前除了网络图标是地球符号而且显示singbox_tun没联网外，其它倒是没问题，看log也确实通过了tun的，好像是logical这个对象引起的，去掉后图标恢复正常，你是要guiconfigs里面的三个配置文件吗

[2dust]

你能用就行了，不用发来了

[wtfr-dot]

新版tun功能优化后，core类型不选singbox就是转发模式，这刚好是我需要的，更像是链式代理，这样xray协议能更完整使用，兼容性更好，gRPC的mutimode也生效了，不过这种选择有个问题可能需要优化：转发模式的VPS域名没有直连解析规则，这样规则顺序如果不对的话会容易造成无法解析VPS域名造成连接失败，自建节点还好，把域名写进rules就可以，但订阅用户可能就有问题

[2dust]

域名解析是在xray那边进行的，xray进程会直连，然后域名也会被正确解析

[wtfr-dot]

我实际使用的时候好像是configpre里面的dns和路由起作用，tun模式启用singbox内核后经过它的dns和路由后再通过socks转发到config的xray里，这时如果是AsIs策略dns不会解析，而且解析也没有用，因为VPS域名解析在singbox那里就开始了，logical类型规则如果在直连前的话，由于VPS域名基本上都是国外的，就会走远程，这样就没有办法解析域名了，最开始我使用的时候log也看得出来提示找不到主机，而且也看到把我的VPS域名发给了远程处理，自然解析不了ip，所以单独给VPS域名加一个规则很有必要，目前的版本如果不用tun模式singbox的http和socks的dns配置没被采纳，直接使用的是v2ray的dns配置，这跟我core类型没选singbox有关，但我确实喜欢这种处理逻辑，顺序处理，兼容性最好

[2dust]

v2rayN_x64_net8.zip

给xray的config加上了域名的解析，你试一试不在singbox加，是否这个版本正常？

[wtfr-dot]

加入VPS域名解析规则后就正常了：
+0800 2024-06-26 17:27:20 DEBUG [795882405 0ms] router: sniffed packet protocol: dns
+0800 2024-06-26 17:27:20 INFO [795882405 1ms] router: found process path: C:\Windows\System32\svchost.exe
+0800 2024-06-26 17:27:20 DEBUG [795882405 1ms] router: match[0] protocol=dns => dns_out
+0800 2024-06-26 17:27:20 DEBUG dns: exchange VPS域名. IN A
+0800 2024-06-26 17:27:20 DEBUG dns: match[1] domain=[VPS域名 ] => local
+0800 2024-06-26 17:27:20 DEBUG dns: exchanged VPS域名 NOERROR 1
+0800 2024-06-26 17:27:20 INFO dns: exchanged VPS域名 A VPS域名. 1 IN A VPS的IP
+0800 2024-06-26 17:27:20 INFO dns: exchanged VPS域名 A VPS域名. 1 IN A VPS的IP
+0800 2024-06-26 17:27:20 INFO [2159053083 0ms] inbound/tun[tun-in]: inbound connection from 172.19.0.1:11776
+0800 2024-06-26 17:27:20 INFO [2159053083 0ms] inbound/tun[tun-in]: inbound connection to VPS的IP:443
+0800 2024-06-26 17:27:20 DEBUG [2159053083 1ms] router: sniffed protocol: tls, domain: VPS域名
+0800 2024-06-26 17:27:20 INFO [2159053083 1ms] router: found process path: F:\v2rayN\bin\Xray\xray.exe

[wtfr-dot]

由于VPS域名都需要本地dns进行解析，建议不管使用哪种模式都加上VPS域名解析规则并优先放在第一条规则上

[2dust]

发布的测试版本在开发机器上是没有问题的
从原理上流量流向是：比如浏览器->tun->socks5(sing-box)->socks5(xray)->出口；
出口时因为是域名，xray需要知道ip，这时候发生域名解析在xray中，xray 走国内的dns解析，此时和sing-box无关
你看看有问题没有？

[wtfr-dot]

你说的流量流向我觉得应该没错，但有一个主要问题，就是dns解析流程：采用tun模式时singbox会劫持所有入站dns请求并返回fakeip，所以在整个流程中这一步是迈不开singbox的，singbox响应fakeip后会发出真实ip的dns查询，由于singbox没有详细的dns解析流程，这一块我的理解是它向外进行dns查询时通过tag为"dns_out"_的outbound里的process进行查询，而process也位于“direct”的outbound里，因此流量直接流出来到xray，如果查询的dns是需要代理的，这时会通过tag为“proxy”的xray的outbound发出，如果outbound的地址是域名的话，xray需要先解析dns，不管它的route走向如何，在这里，由于singbox劫持了所有的dns查询流量，所以dns查询流量回到了singbox，由于这里没有单独对VPS域名设直连规则，所以singbox判断它要走代理（如果域名在singbox规则文件的白名单里就不会了），因此它会向tag为remote的server发出连接，在设置里是8.8.8.8，但是这个域名需要走代理，而xray那里向外发出连接的主机地址还需要8.8.8.8来解析出ip呢，这样就形成了循环，因此xray发出找不到主机的错误。
我之前如果能正常使用的话，如果再删掉VPS域名规则偶尔会成功，不过我觉得应该是dns缓存起了作用（还有我把tun模式dns里local提到了remote之前，VPS域名也列入到直连路由规则里了，可能也有作用，但不是很肯定，不过这样设置也觉得复杂了），另外，singbox启动后会更新srs规则文件，而这个需要代理，如果是全新系统没有规则文件存在的话很容易出问题，因此把VPS域名提前通过本地解析出来最好，可以应对所有情况，singbox和xray对dns解析和路由逻辑不同，这也让人头大，所以我建议在每一个配置文件里都加上这个规则。

[2dust]

ok
等加上后发给你测试

[2dust]

v2rayN_x64_net8.zip

反馈下

[wtfr-dot]

ok，可以了，感谢！