TUN & WireGuard inbounds: Ignore b.UDP's domain when receiving it from outbound

[LjhAUMEM]

到底什么情况会用域名返回啊，懒得看了，先用原始目标返回，继续去看我的wg，有更好的修复可以提出

#6279

[Fangliding]

因为几个带udp src的协议包括xray自己的 b.UDP 结构来回payload基本是对称的 从socks5开始就这样 去能带domain回也能带 能通过整个 b.UDP 传递 协议层面没有阻拦对端能发 可能是哪里不小心还原的 只是在tun这种三转四的节点会造成奇怪的反应

[LjhAUMEM]

想了想判断一下也好，不然恶意构造也可以让 tun 崩溃

理想情况是去可以带域名，回来不应该有，仅对 udp

[RPRX]

前几天刚聊过这个问题，WG 出站的话更好的修复是参考 freedom 那一套“map 还原” #6163 (comment) ，虽然还没 map

你这 PR 是顺便禁止 TUN 入站和 WG 入站产生 UDP domain 流量了？正常确实不该产生，QUIC sniffer 似乎是之后的？

[LjhAUMEM]

sniff 是在之后，这两个入站不会有 domain，是在写回的时候产生的 domain，具体链路还没时间跑一遍，还不知道是在哪里产生的

[RPRX]

@LjhAUMEM 就是我看到每个文件你改了两个地方，它们分别对应哪一刻？懒得看代码上下文了

[LjhAUMEM]

ReadMultiBuffer 对应 tun -> proxy (这个是无关紧要的修改)
WriteMultiBuffer 对应 proxy -> tun (这个才是修复)

[RPRX]

ReadMultiBuffer 对应 tun -> proxy (这个是无关紧要的修改)

我的意思是既然是纯粹的三转四（sniffer 在后面），就不该有 domain address，这里应当不改，以便发现 core 的潜在 bug

sniff 是在之后，这两个入站不会有 domain，是在写回的时候产生的 domain，具体链路还没时间跑一遍，还不知道是在哪里产生的

Core 内部的话我想到有种可能是 QUIC sniffer 或 FakeDNS 搞出了 UDP domain，然后 Freedom 读回数据的时候换掉了 IP

[LjhAUMEM]

ReadMultiBuffer 那里唯一会触发的就是长度大于 8192 的包，感觉打个 error 比断开连接好点

因为断开连接实际第二个包又开新的 socket 继续发，这样就无感了，其实说断开连接也不准确，只是断自己的，对面的没断

[RPRX]

细看了一下那两处与 UDP domain 无关那没事了

其它两处是可以先这么修，不过还是尽快排查一下 Core 内部读回 UDP domain 的情况吧，应该就是我说的那两个情况

[LjhAUMEM]

打算明天看下

[RPRX]

标题不太准确，实际上是连带 port 都被一起忽略了，本来想写“Ignore b.UDP when receiving domain...”但不看代码的话有歧义

算了就这样吧，本质上是 b.UDP 这个名字当初该起成 b.AddrPort 的，这样就不会被误解了，虽然 b.UDP 一看就是仅 UDP 用

[RPRX]

虽然 b.UDP 一看就是仅 UDP 用

确实我想了下 ICMP 也用不到这个，ping 的目标 IP 是固定的，如果说同时 ping 多个 IP 想 mux，大可以直接用 mux

虽然拿这个当 mux、存个子 id 也行，不过似乎更适合拿来存 ping 的序号？不过序号什么的直接放 body 里似乎更好

[RPRX]

不过序号什么的直接放 body 里似乎更好

大概就是 VLESS 把 ICMP 类型、序号、报错、TTL 什么的编码进 body 以实现代理，@LjhAUMEM 你最近比较熟悉，研究一下

#5178 (comment)

[LjhAUMEM]

打算明天看下

奇怪，我用 6279 的客户端配置只修改 hy out 到我自己的配置没有崩溃，那看来是服务端行为了，故意返回了个域名？

不过序号什么的直接放 body 里似乎更好

大概就是 VLESS 把 ICMP 类型、序号、报错、TTL 什么的编码进 body 以实现代理，@LjhAUMEM 你最近比较熟悉，研究一下

#5178 (comment)

有空看看，感觉优先级不是很高，另外如果 vless 要弄的话最好先把原生 udp 提上，不然 ping over tcp 延迟应该会非常感人