Open huzheyi opened 2 months ago
今天在虚拟化平台构建了一个简单的测试环境,对这个问题进行专项测试 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配置也相同
又在正式环境里测试了将内网端口映射到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接口抓不到包。
在openclash项目里查到两个issue,应该目前是通过读取openwrt的端口映射配置,然后把相关端口的访问提前在iptables里retune掉了。很不优雅。。 https://github.com/vernesong/OpenClash/issues/146 https://github.com/vernesong/OpenClash/issues/525
这个问题是否与#281也有关? 我在使用tun模式过后 尝试过了所有模式 也尝试了没有使用任何节点的情况 游戏均显示strict nat 设置的udp端口转发也都失效了
这个问题是否与#281也有关? 我在使用tun模式过后 尝试过了所有模式 也尝试了没有使用任何节点的情况 游戏均显示strict nat 设置的udp端口转发也都失效了
我这边测试只要是dnat到wan ip的内网服务,无论tcp/udp,都是我说的这个状态。
开启tun后,端口转发从外部访问失效 MobileNetwork --> a.com:1234 (公网ip) --> 192.168.1.99:4321 ❌ 但如果我从局域网内访问外部端口,却是可以 Wifi --> a.com:1234 (公网ip) --> 192.168.1.99:4321 ✔
开启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
试试 endpoint-independent-nat: true
呢,我这边可以临时解决
试试
endpoint-independent-nat: true
呢,我这边可以临时解决
这个参数什么意思其实不太理解,能否解释一下?
我暂时把docker container改为host了
我暂时把docker container改为host了
我暂时跑了tproxy模式,其实tproxy效率还更好一些。
大佬们咋解决的啊 ,有点看不懂啊 ,docker 部署host模式的外网访问不了nas
大佬们咋解决的啊 ,有点看不懂啊 ,docker 部署host模式的外网访问不了nas
ufw开了吗
我也遇到了。我是truenas,但是之前的truenas版本是没问题的,怀疑之前是因为k8s自动给做了iptables
我也遇到了。我是truenas,但是之前的truenas版本是没问题的,怀疑之前是因为k8s自动给做了iptables
我觉得您这个情况应该和我描述的不太一样。你的truenas应该工作在类似于“旁路由”模式,不会跨三层吧?
我也遇到了。我是truenas,但是之前的truenas版本是没问题的,怀疑之前是因为k8s自动给做了iptables
我觉得您这个情况应该和我描述的不太一样。你的truenas应该工作在类似于“旁路由”模式,不会跨三层吧?
不是的,我是直接用docker host模式在TrueNAS上启动的:
version: "3"
services:
metacubexd:
container_name: metacubexd
image: ghcr.io/metacubex/metacubexd
restart: always
ports:
- 80:80
mihomo:
container_name: mihomo
image: docker.io/metacubex/mihomo:Alpha
restart: always
pid: host
ipc: host
network_mode: host
cap_add:
- ALL
volumes:
- ./mihomo:/root/.config/mihomo
- /dev/net/tun:/dev/net/tun
我也遇到了。我是truenas,但是之前的truenas版本是没问题的,怀疑之前是因为k8s自动给做了iptables
我觉得您这个情况应该和我描述的不太一样。你的truenas应该工作在类似于“旁路由”模式,不会跨三层吧?
不是的,我是直接用docker host模式在TrueNAS上启动的:
version: "3" services: metacubexd: container_name: metacubexd image: ghcr.io/metacubex/metacubexd restart: always ports: - 80:80 mihomo: container_name: mihomo image: docker.io/metacubex/mihomo:Alpha restart: always pid: host ipc: host network_mode: host cap_add: - ALL volumes: - ./mihomo:/root/.config/mihomo - /dev/net/tun:/dev/net/tun
我的mihomo是运行在路由器上,路由器出接口是pppoe,下游设备接入vswitch,路由器需要做SNAT。你这个情况应该truenas只有一个网络接口,比如都是eth0接入到网络中吧。
我的mihomo是运行在路由器上,路由器出接口是pppoe,下游设备接入vswitch,路由器需要做SNAT。你这个情况应该truenas只有一个网络接口,比如都是eth0接入到网络中吧。
是的,我是单网口。但是,我之前用的TrueNAS Bluefish版本没有这个问题,而且在windows上,也没有这个问题
我的mihomo是运行在路由器上,路由器出接口是pppoe,下游设备接入vswitch,路由器需要做SNAT。你这个情况应该truenas只有一个网络接口,比如都是eth0接入到网络中吧。
是的,我是单网口。但是,我之前用的TrueNAS Bluefish版本没有这个问题,而且在windows上,也没有这个问题
嗯,所以应该不是一个问题。你是用truenas自带的k3s跑的吧?可以看看k3s中关于pod的ingress/egress网络策略配置。
我的mihomo是运行在路由器上,路由器出接口是pppoe,下游设备接入vswitch,路由器需要做SNAT。你这个情况应该truenas只有一个网络接口,比如都是eth0接入到网络中吧。
是的,我是单网口。但是,我之前用的TrueNAS Bluefish版本没有这个问题,而且在windows上,也没有这个问题
嗯,所以应该不是一个问题。你是用truenas自带的k3s跑的吧?可以看看k3s中关于pod的ingress/egress网络策略配置。
倒不是用自带的k3s跑的,是通过portainer跑的,portainer用的k3s启动的。现在已经看不到策略啦,,因为升级后已经没有k3s了,TrueNAS抛弃了k3s。。。
我用mihomo做透明网关也遇到这个问题了,只要打开tun模式,外网就无法访问内网的服务,关闭tun就可以,但是关闭tun模式代理又失效,有没有什么办法可以解决?
我暂时把docker container改为host了
我暂时跑了tproxy模式,其实tproxy效率还更好一些。
mihomo怎么配置tproxy模式?
Verify steps
Operating System
Linux
System Version
vyos 1.5
Mihomo Version
Mihomo Meta alpha-43f21c0 linux amd64 with go1.23.0 Mon Sep 2 08:24:57 UTC 2024 Use tags: with_gvisor
Configuration File
Description
我是在vyos上通过container host模式运行的mihomo 1.18.8
我的情况是vyos上配置了dnat映射,经过抓包发现 当从外部网络访问我映射的服务时
4.之后这个数据包就进入了Meta接口,从Meta接口抓包可以看到
当我关闭mihomo时相关数据包可以在pppoe0和br0上被正常捕获,我确认这与我vyos的防火墙无关,因为关闭防火墙全通策略下也是这样的表现。
我不知道到4这一步时,正常的表现应该是:
但无论如何,确实外部网络的主机无法收到任何回包。
内网主机正常访问外网表现为完全正常。
Reproduction Steps
vyos dnat配置
vyos mihomo容器配置
在mihomo alpha、v1.18.8、v1.18.5版本测试表现相同
Logs