[Bug] TUN模式下，DNAT入站流量无法回包出站的问题 about mihomo HOT 11 OPEN

今天在虚拟化平台构建了一个简单的测试环境，对这个问题进行专项测试
vyos虚拟机
eth0(wan):静态ip,192.168.1.250/24
br0(lan):dhcp-server, 172.20.0.1/24
内网服务器: 172.20.0.107/24

在vyos配置相同的防火墙策略、snat masquerade策略和dnat策略，将内网服务器22端口映射到wan的2222端口
从外部192.168.1.93机器访问 192.168.1.250:2222，在启用mihomo的情况下正常访问

抓包Meta接口看不到任何流量，应该是入站流量和出站流量没有经过mihomo处理。

很匪夷所思

如果说这两个环境有区别，比较大的区别可能在我正式环境的vyos拥有eth0、eth1、eth2、eth3四个端口
eth0上建立pppoe0接口连接互联网
eth1连接了上游路由器的iptv网络、未配置地址、用于接收igmp组播流量
eth1子接口vif3010桥接了上游路由器的voip网络、配置静态地址
eth2和eth3作为br0的成员接口、成为lan网络、下接交换机

我猜测有没有可能mihomo面对比较多的网络接口时出现了什么bug导致流量被错误导入到tun设备？

补充一下我mihomo在vyos设备上创建的ip rule规则和2022路由表

//ip rule 
0:	from all lookup local
9000:	from all to 198.18.0.0/30 lookup 2022
9001:	not from all dport 53 lookup main suppress_prefixlength 0
9001:	from all ipproto icmp goto 9010
9001:	from all iif Meta goto 9010
9002:	not from all iif lo lookup 2022
9002:	from 0.0.0.0 iif lo lookup 2022
9002:	from 198.18.0.0/30 iif lo lookup 2022
9010:	from all nop
32766:	from all lookup main
32767:	from all lookup default

//route table 2022
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
       f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup
       t - trapped, o - offload failure

VRF default table 2022:
K>* 0.0.0.0/0 [0/0] is directly connected, Meta, 1d01h12m

经过比较正式环境与测试环境上述量表内容相同，另，mihomo配置也相同

from mihomo.

又在正式环境里测试了将内网端口映射到eth0上（而非pppoe0）的情况，从连接eth0的上游设备上是可以正常访问的。

现在看来原因逐渐清晰起来，当我映射到pppoe0上时：
入站请求：数据包(from public ip) --> wan --dnat--> br0 --> host，这个过程mihomo没有参与
出站流量：数据包( to public ip ) --> host --> br0 --snat--> tun，这个过程的流量在snat后可能被mihomo视作一个新的连接请求从而劫持

至于这个流量是否真的出站了，目前我无法确定，理论上他应该可以出站，而我在外部服务器上抓不到包也可能是由于数据包的state不对而被云服务器的防火墙当作一个new的连接给drop掉了，这个我要再测试一下

而当我映射到eth0上时，由于eth0上是一个私网地址，所以出站流量不会被mihomo劫持，也自然在Meta接口抓不到包。

from mihomo.

在openclash项目里查到两个issue，应该目前是通过读取openwrt的端口映射配置，然后把相关端口的访问提前在iptables里retune掉了。很不优雅。。
vernesong/OpenClash#146
vernesong/OpenClash#525

from mihomo.

这个问题是否与#281也有关?
我在使用tun模式过后 尝试过了所有模式 也尝试了没有使用任何节点的情况 游戏均显示strict nat 设置的udp端口转发也都失效了

from mihomo.

这个问题是否与#281也有关? 我在使用tun模式过后 尝试过了所有模式 也尝试了没有使用任何节点的情况 游戏均显示strict nat 设置的udp端口转发也都失效了

我这边测试只要是dnat到wan ip的内网服务，无论tcp/udp，都是我说的这个状态。

from mihomo.

开启tun后,端口转发从外部访问失效
MobileNetwork --> a.com:1234 (公网ip) --> 192.168.1.99:4321 ❌
但如果我从局域网内访问外部端口,却是可以
Wifi --> a.com:1234 (公网ip) --> 192.168.1.99:4321 ✔

from mihomo.

开启tun后,端口转发从外部访问失效 MobileNetwork --> a.com:1234 (公网ip) --> 192.168.1.99:4321 ❌ 但如果我从局域网内访问外部端口,却是可以 Wifi --> a.com:1234 (公网ip) --> 192.168.1.99:4321 ✔

是的，因为这种实际上hairpin nat做了一个源地址转换，你访问的a.com实际仍然是192.168.1.99

from mihomo.

试试 endpoint-independent-nat: true 呢，我这边可以临时解决

from mihomo.

试试 endpoint-independent-nat: true 呢，我这边可以临时解决

这个参数什么意思其实不太理解，能否解释一下？

from mihomo.

我暂时把docker container改为host了

from mihomo.

我暂时把docker container改为host了

我暂时跑了tproxy模式，其实tproxy效率还更好一些。

from mihomo.