mihomo
mihomo copied to clipboard
MetaCubeX
启动后tun模式下udp转发行为异常
首先抱歉，个人很难用很短的文本总结这个问题，标题可能有点没说清楚问题，我先详细描述一下现象
基本的配置是开启了TUN模式，对于tcp流量使用redir的方式进入clash, udp流量通过tun进入，clash配置的rule中对某些白名单ip设置了全局走proxy，proxy可选上游是 vless (tcp/xtls) / hysteria (udp) 上游服务器的防火墙配置了 udp 1024-65535 端口放行
如此配置后tcp的流量一切正常，但是udp的行为会有些问题，两个clash.meta的版本表现也不一样
clash.meta v1.13.2
启动clash后，如果把上游选择到vless，使用nintendo switch（在白名单内，会全局走proxy）的网络测试功能测得 公网ip=上游ip， NAT类型=F （无法通讯），上传下载正常（TCP流量）；如果把上游选择到 hysteria ， 可以测得 公网ip=上游ip， NAT类型=B （Restricted Cone），上传下载正常（TCP流量）
无论测试执行多少次都是一样的结果（不存在首次失败之后成功的情况）
此时如果通过api接口PUT /configs 重新读取一下配置（配置文件本身不做任何变更），再执行同样的测试，无论上游选择 vless 或者 hysteria ，都可以测得 NAT类型=A (Full Cone)
clash.meta v1.14.1
启动后的现象与之前一致，差异是重新读取配置也不能修复这个问题，始终保持使用 vless 时 NAT Type F , 使用 hysteria 时 NAT Type B
tun模式我也没发现什么办法可以恢复fullcone NAT的。增强模式关udp测出来的是类型A 也就是fullcone。 开tun模式switch降到nat B。电脑上也是端口限制形了。 使用cfw同样的配置不管代理或者直连tun模式都可以实现fullcone
此问题的诊断过程、产生原因和解决方案我写了一篇博客 Clash TUN模式下的UDP服务异常诊断与解决 Deal with the network issue of UDP services with Clash TUN mode enabled
TL; DR 由于目前ClashX的TUN模式的sourceport重映射设计，无法达到 Fullcone NAT
