TUN inbound: Add gateway, dns, autoSystemRoutingTable, autoOutboundsInterface for Windows#5887
TUN inbound: Add gateway, dns, autoSystemRoutingTable, autoOutboundsInterface for Windows#5887
gateway, dns, autoSystemRoutingTable, autoOutboundsInterface for Windows#5887Conversation
|
|
|
这个 auto-route 要加的话，mac 和 linux 肯定也会适配的，不用起名 winRoute 还要实现自动给出站没填 interface 的加上 interface，不过有同时插网线、连 wifi 的情况，先判断哪个是默认的？ |
这种东西肯定得加的，因为内核里 DoH 等自动请求也得绑个 interface 来绕过 tun 不然回环了， |
|
auto-route 是作为 bool？我认为也要有一个类似 route 的可以指定 ip cidr interface 当初想的是不手动指定就取第一个非 tun index 的传到 ctx 里 |
|
直接用 RegisterDialerController 注入一个sockopt绑定接口就是了 doh什么的全走的这个接口 很久之前就考虑过这个问题了 |
|
也可以，反正 setsocketint 各大 os 都有，不用分 os |
|
Xray 启动时探测一下默认接口吧，auto-route 可以保留现在的配置格式，这样挺好的， |
|
@Fangliding echForceQuery 配置项还有必要留着吗，开个 PR 删了吧 |
|
之前有一个给伊朗无服务器用的莫名其妙的half 也毙了吗 |
|
话说隔壁两家的 TUN 实现的 auto-redirect 是不是拿 /0 减掉 auto-redirect 来算路由表 |
|
|
|
那东西我也觉得没用 用处太边缘而且他自己好像也不更了 好像他扔出来的模板都没那功能 纯ex人 |
|
ECH any outer sni 这个前几天在群里讨论过，是不是现在的 uTLS 实现不了来着？ |
|
|
可以 主要是CF不支持 做了也没用 自建ECH的情况下outer完全可以自己填 |
那就先加个自定义 outer sni 的功能吧，感觉 echConfigList 塞不下了，按之前说的把 sni 改成 outer.com+inner.com 吧 主要是正好也能把旧的客户端给 break 掉，这在以后全面普及 any outer sni 后会有帮助 |
|
random outer 哪怕是IETF最后做出来也是另一套逻辑 我稍微看了一下那个ppt 和现在做一个土制的的盖过去肯定是不一样的 还是那句话这东西八字没一撇 |
|
还有我说的自建ECH可以自己填意思是生成 ECH Config 的时候 outer 可以自己写 然后就原生apply进去了 不需要任何新功能 |
|
有点难以想象“另一套逻辑”是啥逻辑，服务端定义可选 SNI 范围？ |
|
可能就是因为这些乱七八糟的原因才如此缓慢吧 我第一次看到这东西好像得是两年前24年那会了 |
|
想了一下有可能比如加了个额外的签名验证尝试以实现同 IP 区分多服务端？虽然 outer sni 一样， |
|
那先不管了，@Fangliding 他这个 auto-route 的话得把 REALITY 仓库 record_detect.go 和 VLESS fallbacks 改一下，你看看 |
|
这都要算吗 反正tun也就客户端用用应该无所谓吧 singbox clash那些带tun的都没见管 |
|
|
|
|
先不管这个，先实现个 Xray 启动时自动探测出默认 interface 并应用到核心发出的连接吧， 还有你看下隔壁两家的 auto-redirect 是不是拿 /0 减掉、自动计算路由表，如果是的话那它和 auto-route 的优先级？
对了还需要实现个指定 TUN 的 IPv4 & IPv6，TUN 这块就差不多了 |
Although the internet is still down and only DNS or IP-Spoofing based methods work in Iran, they opened some Cloudflare IPs for some White SNIs for a few hours (They've done this a few times in the last month and closed it again.), and it is clear that they are implementing a new system. "cloudflare-ech.com" was not in their whitelist, also fragments method didn't work, they simply close the connection when they can't read the sni. but i tested some ip/tcp-header-manipulation methods and it can bypass this restriction: method 1 (simplest one): send a white-sni-client-hello-packet with low ip-ttl before main-clienthello-packet: because GFW sees this packet and interprets it as a white-sni-clienthello-packet , so allow other packets without checking, but this packet does not reach to the cloudflare servers, so you can send your main-blocked-sni-clienthello-packet later !!! Apart from method 1, I successfully tested 2 other methods (related to tcp-header) and with all of them I was able to successfully connect to cloudflare cdn. /// It's time to prioritize raw-sockets-outbounds. |
|
auto-redirect 是什么需求，我还在看 linux go 里怎么实现路由，
|
|
update，更新几点信息
func main8() {
var builder netipx.IPSetBuilder
builder.AddPrefix(netip.MustParsePrefix("0.0.0.0/0"))
builder.RemovePrefix(netip.MustParsePrefix("192.168.1.1/32"))
result, _ := builder.IPSet()
for _, p := range result.Prefixes() {
fmt.Println(p)
}
}关于这个 pr，将会侧重在 windows 上的 autoRedirect 以及 tun 的 defaultInterface， |
autoRoutingTable 改名 autoSystemRoutingTable， mtu、autoOutboundsInterface 应该是任何系统都生效吧？gateway、dns、autoSystemRoutingTable 目前只支持 Windows？
|
默认就是禁用的，应该问题不大，要杜绝的话就是之前说的 wfp 驱动层拦截，
mtu 其他 os 和之前一样，autoOutboundsInterface 理论所有 os 都生效， gateway、dns、autoSystemRoutingTable 这个 pr 只有 windows |
|
“mtu 其他 os 和之前一样” 是啥意思，
|
就是没动过，不过应该支持吧，我记得是有分 unix.AF_INET 和 unix.AF_INET6
多了个在后台监测网卡变动的 callback（不过应该也没什么用），初始化都一样 |
gateway, dns, autoSystemRoutingTable, autoOutboundsInterface for Windows
|
#5887 (comment) 这里说了一个可能回环的情况 他们那 UI 的配置还要搞分流有点复杂，但如果说换成 sockopt.interface 就不回环了那是不应该的，autoOutboundsInterface 应该完美覆盖了 sockopt.interface 的情况，还多了个 localdns 描述里的 freedom 启动后唯一占 cpu 的只有浏览器，需要最简可复现配置 |
|
能不能麻烦开发者看一下这个问题： |
|
还真有个双栈问题，在 #5891 一起改了，默认 ipv6 就是按 dual stack 设置，应该没什么问题，darwin 和 windows 默认也是双栈的 |
|
@LjhAUMEM 应该解决了 2dust/v2rayN#9063 (comment) 吧？ |
|
@LjhAUMEM #5887 (comment) 这个也解决了吗 |
只能说 autoOutboundsInterface 现在和 sockopt.interface 没区别了，而且覆盖情况更多
这个可以通过 sockopt.domainStrategy 解决，要改就是改成用 localdns 解析，但是应该不止这一处，单改这一处没什么意义感觉 |
|
And reverts "refactor `mtu` to support setting IPv4/v6 separately" #5891 (comment) And fixes `autoOutboundsInterface` on Windows #5887 (comment) --------- Co-authored-by: LjhAUMEM <llnu14702@gmail.com>
理论上是会，比如这个 outbound，这里的 www.example.com 就是走的 net.ResolveUDPAddr 也就是系统解析，理论上系统解析是会进入系统路由，然后又回到这个 outbound 不过也只是 udp 类的 addr，net.dialer 绑定了网卡所以没问题 感觉改下也可以， |
ResolveUDPAddr 就是 net.ParseIP + net.Resolver，搞个自定义 net.Resolver 就可以绑定到网卡了
理论上一切回环都可以通过内部路由解决，只要有任一出站是有效的 |
|
感觉越来越dirty了 |
|
|
Xray-core 的文档的话建议加 "/self" 吧， |
我的需求是先按进程名称分流一次，一部分进程走Direct，一部分进程的流量按域名和IP再分流一次。 |
|
@mclovin-2k 试试 loopback 出站？ |
明天试试。 |
{ "log": { "loglevel": "debug" }, "inbounds": [ { "protocol": "tun", "settings": { "name": "xray0", "mtu": [ 1500, 1280 ], "gateway": [ "10.0.0.1/16", "fc00::1/64" ], "dns": [ "1.1.1.1", "8.8.8.8" // "2606:4700:4700::1111", // "2001:4860:4860::8888" ], "userLevel": 0, "autoSystemRoutingTable": [ "0.0.0.0/0", "::/0" ] // ,"autoOutboundsInterface": "auto" } } ], "outbounds": [ { "protocol": "freedom" } ] }