[Bug] tun模式在Ubuntu18上生成的ip rule有误

Gedoy9793 commented 9 months ago

Verify steps

[X] 确保你使用的是本仓库最新的的 mihomo 或 mihomo Alpha 版本 Ensure you are using the latest version of Mihomo or Mihomo Alpha from this repository.
[ ] 如果你可以自己 debug 并解决的话，提交 PR 吧 Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.
[X] 我已经在 Issue Tracker 中找过我要提出的问题 I have searched on the issue tracker for a related issue.
[X] 我已经使用 Alpha 分支版本测试过，问题依旧存在 I have tested using the dev branch, and the issue still exists.
[X] 我已经仔细看过 Documentation 并无法自行解决问题 I have read the documentation and was unable to solve the issue.
[X] 这是 Mihomo 核心的问题，并非我所使用的 Mihomo 衍生版本（如 OpenMihomo、KoolMihomo 等）的特定问题 This is an issue of the Mihomo core per se, not to the derivatives of Mihomo, like OpenMihomo or KoolMihomo.

Mihomo version

Mihomo Meta v1.18.0 linux amd64 with go1.21.5 Tue Jan 2 07:31:30 UTC 2024 Use tags: with_gvisor

What OS are you seeing the problem on?

Linux

Mihomo config

mode: rule
mixed-port: 7897
allow-lan: false
log-level: info
secret: ''
external-controller: 0.0.0.0:9097
dns:
  enable: true
  ipv6: false
  default-nameserver:
  - 223.5.5.5
  - 119.29.29.29
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  use-hosts: true
  nameserver:
  - https://doh.pub/dns-query
  - https://dns.alidns.com/dns-query
  fallback:
  - https://doh.dns.sb/dns-query
  - https://dns.cloudflare.com/dns-query
  - https://dns.twnic.tw/dns-query
  - tls://8.8.4.4:853
  fallback-filter:
    geoip: true
    ipcidr:
    - 240.0.0.0/4
    - 0.0.0.0/32
  fake-ip-filter:
  - dns.msftncsi.com
  - www.msftncsi.com
  - www.msftconnecttest.com
tun:
  enable: true
  stack: gvisor
  dns-hijack:
  - any:53
  auto-route: true
  auto-detect-interface: true
proxies:
...

Mihomo log

INFO[2024-01-15T16:53:40.677057411Z] Start initial configuration in progress
INFO[2024-01-15T16:53:40.678286015Z] Geodata Loader mode: memconservative
INFO[2024-01-15T16:53:40.678303475Z] Geosite Matcher implementation: succinct
INFO[2024-01-15T16:53:40.679259116Z] Initial configuration complete, total time: 2ms
INFO[2024-01-15T16:53:40.680067431Z] RESTful API listening at: [::]:9097
INFO[2024-01-15T16:53:40.695695849Z] Sniffer is closed
INFO[2024-01-15T16:53:40.695839961Z] Mixed(http+socks) proxy listening at: 127.0.0.1:7897
WARN[2024-01-15T16:53:40.69632444Z] [TUN] default interface changed by monitor,  => ens160
INFO[2024-01-15T16:53:40.698569843Z] [TUN] Tun adapter listening at: Meta([198.18.0.1/30],[fdfe:dcba:9876::1/126]), mtu: 9000, auto route: true, ip stack: gVisor
INFO[2024-01-15T16:53:40.710555674Z] Start initial Compatible provider default

Description

配置tun不生效

xishang0128 commented 9 months ago

@Gedoy9793 执行一下ip rule看看,以及是否是root用户启动,如果非root,是否给予了对应权限

Gedoy9793 commented 9 months ago

@Gedoy9793 执行一下ip rule看看,以及是否是root用户启动,如果非root,是否给予了对应权限

ip rule:

0:      from all lookup local
9000:   from all to 198.18.0.0/30 lookup 2022
9001:   from all goto 9010
9002:   not from all lookup main suppress_prefixlength 0
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

是root权限运行，配置成系统服务了

xishang0128 commented 9 months ago

@Gedoy9793 ping 223.5.5.5 -c4 看看是什么结果

Gedoy9793 commented 9 months ago

WARN[2024-01-15T16:53:40.69632444Z] [TUN] default interface changed by monitor,  => ens160

启动时或者使用webui切换tun模式时，会出现这个warning，不知道是不是这个问题，

Gedoy9793 commented 9 months ago

@Gedoy9793 ping 223.5.5.5 -c4 看看是什么结果

PING 223.5.5.5 (223.5.5.5) 56(84) bytes of data.

--- 223.5.5.5 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3071ms

ping不通

xishang0128 commented 9 months ago

WARN[2024-01-15T16:53:40.69632444Z] [TUN] default interface changed by monitor,  => ens160
启动时或者使用webui切换tun模式时，会出现这个warning，不知道是不是这个问题，

这是正常提示,选择出站接口

xishang0128 commented 9 months ago

@Gedoy9793 ping 223.5.5.5 -c4 看看是什么结果

PING 223.5.5.5 (223.5.5.5) 56(84) bytes of data.

--- 223.5.5.5 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3071ms

ping不通

ping 198.18.0.1呢,以及是否安装了iproute2,如果没有,安装再尝试

Gedoy9793 commented 9 months ago

@Gedoy9793 ping 223.5.5.5 -c4 看看是什么结果
PING 223.5.5.5 (223.5.5.5) 56(84) bytes of data.

--- 223.5.5.5 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3071ms
ping不通
ping 198.18.0.1呢,以及是否安装了iproute2,如果没有,安装再尝试

这个可以ping通

iproute2已经安装了，刚刚试试更新了一下再重启核心，问题还在

xishang0128 commented 9 months ago

@Gedoy9793 试试mixed栈

Gedoy9793 commented 9 months ago

@Gedoy9793 试试mixed栈

还是不可以，日志是一样的

xishang0128 commented 9 months ago

@Gedoy9793 那就不要用service启动,直接命令行启动内核常识一下,root用户

Gedoy9793 commented 9 months ago

@Gedoy9793 那就不要用service启动,直接命令行启动内核常识一下,root用户

还是不行，ping 223.5.5.5不通

Gedoy9793 commented 9 months ago

@Gedoy9793 那就不要用service启动,直接命令行启动内核常识一下,root用户

使用tun后路由表应该有变化吗，我看现在的默认网关还是走ens160，就是物理网卡

levihuayuzhang commented 9 months ago

Same, at Alpha HEAD and v1.18 (self compiled), on Ubuntu 2204. Shows the DNS resolve failed. No matter using systemd or start manually in command line with root privilege.

After turn off tun, the dns resolve failed goes away.

But the container image seems works fine with tun.

BTW, Using System stack of TUN.

Gedoy9793 commented 9 months ago

开启tun之后的默认路由规则表

0:      from all lookup local
9000:   from all to 198.18.0.0/30 lookup 2022
9001:   from all goto 9010
9002:   not from all lookup main suppress_prefixlength 0
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

我手动删掉9001那条之后似乎就修好了

@xishang0128

xishang0128 commented 9 months ago

@Gedoy9793 lookup到2022了看起来应该没问题才对

Gedoy9793 commented 9 months ago

@Gedoy9793 lookup到2022了看起来应该没问题才对

不过生成的这个，9001那条就很奇怪，把后面都跳过了，不知道为什么

xishang0128 commented 9 months ago

@Gedoy9793 我也有9001这个,但是能正常使用,确实挺奇怪的

Gedoy9793 commented 9 months ago

刚刚从Ubuntu18升级到20，发现ip rule变了，变成了：

0:      from all lookup local
9000:   from all to 198.18.0.0/30 lookup 2022
9001:   from all ipproto icmp goto 9010
9002:   not from all dport 53 lookup main suppress_prefixlength 0
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

这样就合理了，看起来Ubuntu18不支持9001里这条规则，会变成from all goto 9010，导致路由失效

Gedoy9793 commented 9 months ago

另外在Ubuntu18上，metacubexd也拿不到日志，应该是核心restfulapi的问题，更新后解决了

Bodil-X commented 9 months ago

CentOS 7 中也存在这个问题，按 @Gedoy9793 说的，使用命令 ip rule del pref 9001 后就正常了

vichbb commented 9 months ago

ip rule del pref 9001

不知道为什么我的移除了也不行，请问centos7需要额外配置cat /etc/resolv.conf吗？

Bodil-X commented 9 months ago

ip rule del pref 9001

不知道为什么我的移除了也不行，请问centos7需要额外配置cat /etc/resolv.conf吗？

我有配置，实际上即使删除了9010那条，后续在使用的过程中还发现其它的问题。我把系统内核升级到5.4后，运行了也不用再手动删除了。（但是它还是存在其它问题，如宿主机上运行的docker运行的程序的端口无法被局域网内其它机器访问到，需要手动排除docker0这个网络接口，但是这样又导致docker0内的网络无法使用到clash）

vichbb commented 9 months ago

ip rule del pref 9001

不知道为什么我的移除了也不行，请问centos7需要额外配置cat /etc/resolv.conf吗？

我有配置，实际上即使删除了9010那条，后续在使用的过程中还发现其它的问题。我把系统内核升级到5.4后，运行了也不用再手动删除了。（但是它还是存在其它问题，如宿主机上运行的docker运行的程序的端口无法被局域网内其它机器访问到，需要手动排除docker0这个网络接口，但是这样又导致docker0内的网络无法使用到clash）

额，我就是想docker内的软件走代理，看样子还不行呢，那我先看看老版 clash pre吧，感谢！

MetaCubeX / mihomo