Conversation
|
|
|
这个 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， |
|
|
@LjhAUMEM 这个 PR 先别搞 auto-redirect 了吧，先搞好 auto-route，既然能自己填路由范围那也基本够用了 我觉得这个 PR 主要差 auto-interface，以及能不能把 TUN 的 IPv4/v6 默认固定下来，并开放用户自定义，方便手动改路由表 |
|
@LjhAUMEM rebase 一下然后实现 #5887 (comment) 吧 写系统路由表和写 Xray 路由，UDP 可能有区别，比如 A 先给 B 再给 C 发包，Xray 路由只会跟着 B，而系统路由表会分流？ |
|
auto-interface 我得看看，还不确定有哪些地方没走 outbound，可能还得注册个 interface 变化的 callback |
|
除了用户手动指定 IP，方不方便弄个默认 IP，类似于 #5811 |
|
刚刚加了，不过只是 win 的 |
|
|
|
指定了就固定，不指定就生成 |
CreateIpForwardEntry2 和系统路由表没区别吧，不过不操作注册表的话不知道 win 上的那个 智能多宿主解析 问题是不是还在 |
|
系统路由表应该是只看每个包的去向的，Xray 的路由是对于相同的“来源二元组”只看第一个包的去向 这两种处理各有优劣，前者可能把你国内 IP 给泄露了，后者可能把你代理 IP 给泄露了
|
|
|
4 participants
关于 default interface，看了下 outbound 感觉哪里都不合适，
决定先不碰，话说为什么 app/proxyman 出站的 uot 也有 sing 包的身影{ "log": { "loglevel": "debug" }, "inbounds": [ { "protocol": "tun", "settings": { "address": [ // "10.0.0.1/16", // "fc00::1/64" ], "route": [ "0.0.0.0/0", "::/0" ], "dns": [ // "1.1.1.1", // "2606:4700:4700::1111", // "8.8.8.8", // "2001:4860:4860::8888" ] } } ], "outbounds": [ { "protocol": "freedom", "streamSettings": { "sockopt": { "interface": "以太网 2" } } } ] }