关于 TUN mode 的问题以及几个建议

ForestL18 commented 2 months ago

TUN mode

设置 tun mode 之后，在代理路由器本机流量的时候，对于同一个域名，会出现mihomo第一次请求的是域名，连接的是域名，但之后的连接都是mihomo连接这个域名的IP。经过排查发现，是由于chain router_dns_hijack只重定向了127.0.0.1，但实际上路由器本机发起DNS请求时同时也会向Interface LAN IP（如192.168.89.2）发起DNS请求。这种情况会导致路由器向上游DNS请求并返回了IP，于是mihomo就直接对IP发起了连接，从而导致分流不准。 example

解决方法有两种：1.劫持Interface LAN IP。2.修改dnsmasq：设置option noresolv '1'，拒绝路由器本机向上游DNS发起请求。

同时应当给dnsmasq设置option dns_redirect '0'，以immortalWRT为例，dnsmasq_redirect优先级高于mihomo dns_hijack，（如下所示）会导致入站DNS流量无法被mihomo劫持。

table inet dnsmasq {
        chain prerouting {
                type nat hook prerouting priority dstnat - 5; policy accept;
                meta nfproto { ipv4, ipv6 } udp dport 53 counter packets 0 bytes 0 redirect to :53 comment "DNSMASQ HIJACK"
        }
}

table ip mihomo {
        chain dstnat {
                type nat hook prerouting priority dstnat + 1; policy accept;
                jump dns_hijack
        }
}

建议把使用hosts改为覆盖hosts

一般使用hosts的话在配置文件里面可能都设置了不少的hosts规则，如果完全重头填写过于麻烦，可以直接复用配置文件中的hosts规则。如果需要覆盖的话可以通过识别hosts字段，一个输入框来输入所有Domain-IP对，而不是通过多个输入框一个个填写Domain-IP对。如下图所示：

覆盖 DNS 服务器，覆盖 Fallback 过滤列表，覆盖 DNS 服务器查询策略同理。

混入文件内容存在bug

输入框存在输入内容后保存没问题，但是把输入框中内容全部删除，再点保存不生效，内容还是存在在输入框中，同时也存在在mixin.yml文件中，只能手动清除mixin.yml文件内容。

GeoX配置中可以考虑添加 ASN下载地址

ForestL18 commented 2 months ago

还有一点就是建议添加一个单独订阅配置文件的按钮，方便手动更新配置文件

morytyann commented 2 months ago

但实际上路由器本机发起DNS请求时同时也会向Interface LAN IP发起DNS请求

贴一下你的/tmp/resolv.conf看看，我这里只有127.0.0.1和::1，应该不会直接对LAN的IP发起DNS请求才对

同时应当给dnsmasq设置option dns_redirect '0'

不会采用这种直接修改其他插件配置的方法，另外，这个选项是ImmortalWRT独有的吧，我看了好像还是默认开启的……

建议把使用hosts改为覆盖hosts

这个小标题我看懂了，但是下面的内容我没能理解，不过我确实有想法修改这个地方，改成可选择不混入/覆盖/追加三种选项，这样更加灵活

混入文件内容存在bug

这个似乎是LuCI的问题？如果可以的话会修复

GeoX配置中可以考虑添加 ASN下载地址

会添加

添加一个更新订阅配置文件的按钮，方便手动更新配置文件

没什么必要吧，真的需要手动触发更新的情况太少了，大多数都是等定时重启的时候自动更新就好啊如果再有一个人来提我再加一个重启按钮吧……

H2295 commented 2 months ago

还有一点就是建议添加一个单独订阅配置文件的按钮，方便手动更新配置文件

网页面板里就能更新订阅配置了 17226106752504948181770886514964

ForestL18 commented 2 months ago

贴一下你的/tmp/resolv.conf看看，我这里只有127.0.0.1和::1，应该不会直接对LAN的IP发起DNS请求才对
root@ImmortalWrt:~# cat /tmp/resolv.conf
search lan
nameserver 127.0.0.1
nameserver ::1
我实际测试了在开启 mihomo TUN 的情况下，nslookp LAN IP 是会请求回真实IP的（图中是我关了上游文件解析），关了上游解析才能消除我上述的影响。

不会采用这种直接修改其他插件配置的方法，另外，这个选项是ImmortalWRT独有的吧，我看了好像还是默认开启的……

immortalwrt 独有的吗？这我倒不是很清楚，我的意思就是如果有类似选项启动mihomo的时候给关了就行，以免干扰到mihomo的劫持

这个小标题我看懂了，但是下面的内容我没能理解，不过我确实有想法修改这个地方，改成可选择不混入/覆盖/追加三种选项，这样更加灵活

可以参考我上述图片中的示例，是从openclash设置界面截的图。举例来说，假如配置文件中关键词 nameserver-policy 的一个 key-value 的 key 是 "rule-set:googlefcm,apple,microsoft,epicgames,direct,private,cn"。

那么在覆盖nameserver-policy时：

如果覆盖输入框的key和配置文件中相同时，就保持key不变，把配置文件中的value改为覆盖输入框中设置的新value并写入混合后配置文件；
如果覆盖输入框的key和配置文件中不同时，就把新的key-value附加到混合后配置文件中。

这个似乎是LuCI的问题？如果可以的话会修复

有可能，感觉是前端的修改没传到后端

没什么必要吧，真的需要手动触发更新的情况太少了，大多数都是等定时重启的时候自动更新就好啊

使用订阅链接的时候，每次重启插件就会去更新订阅链接是吧。

还有个问题就是使用订阅链接的时候，编辑器是没法编辑配置文件的，希望也能改下。

morytyann commented 2 months ago

直接向Lan IP发起DNS请求确实不会被劫持，但是这样并不会影响插件正常工作，因为默认DNS服务器是127.0.0.1，可能你说的问题原因不在这里，我明天看看能不能复现

dns劫持选项在官方OpenWrt里并没有的，而且还是那个原则，不会采用直接修改其他插件配置的方法

混入这个我会尽可能将选项改为可选是否混入，针对列表，还可以选择追加或覆盖

修改来自订阅链接的配置文件，不会添加这个功能，可以下载下来上传到插件，或者自行编写配置文件，使用proxy_provider引用订阅链接，这样还可以直接在面板更新proxy_provider

ForestL18 commented 2 months ago

修改来自订阅链接的配置文件

我前面的表述有问题，应该是可以查看订阅链接的配置文件，不是非要修改。

直接向Lan IP发起DNS请求确实不会被劫持，但是这样并不会影响插件正常工作

如果只是发往Lan IP的DNS请求不被劫持其实没事，但是他会请求上游DNS直接给mihomo返回一个IP，这就会影响分流了

morytyann commented 2 months ago

呃，谁请求了上游DNS？DNSMASQ？

ForestL18 commented 2 months ago

呃，谁请求了上游DNS？DNSMASQ？

是的，具体来说请求的是/tmp/resolv.conf.d/resolv.conf.auto

因为我设置的旁路由，上游DNS只有这个

morytyann commented 2 months ago

那谁请求了DNSMASQ并且没被劫持到核心呢？我想应该没有吧？毕竟DNS服务器是127.0.0.1和::1

morytyann commented 2 months ago

可能是旁路由拓扑的事？明天再说吧

ForestL18 commented 2 months ago

那谁请求了DNSMASQ并且没被劫持到核心呢？

我测试了路由器本机的 opkg update 和 ntp 更新，这两者都会请求到dnsmasq

morytyann commented 2 months ago

不能复现，日志如下

root@OpenWrt:~# uci show system.ntp
system.ntp=timeserver
system.ntp.enabled='1'
system.ntp.enable_server='0'
system.ntp.server='0.openwrt.pool.ntp.org' '1.openwrt.pool.ntp.org' '2.openwrt.pool.ntp.org' '3.openwrt.pool.ntp.org'

root@OpenWrt:~# service sysntpd restart

root@OpenWrt:~# grep :123 /etc/mihomo/run/core.log 
time="2024-08-03T09:51:12.77325745+08:00" level=info msg="[UDP] WAN_IP:55134 --> 1.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:51:17.23154364+08:00" level=info msg="[UDP] WAN_IP:54459 --> 2.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:51:21.715653929+08:00" level=info msg="[UDP] WAN_IP:42780 --> 0.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:51:44.293715701+08:00" level=info msg="[UDP] WAN_IP:33750 --> 3.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:52:20.530905096+08:00" level=info msg="[UDP] WAN_IP:38164 --> 1.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:52:23.766889717+08:00" level=info msg="[UDP] WAN_IP:44947 --> 2.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:52:28.970089107+08:00" level=info msg="[UDP] WAN_IP:60585 --> 0.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:52:52.263440523+08:00" level=info msg="[UDP] WAN_IP:42967 --> 3.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:23.225218025+08:00" level=info msg="[UDP] WAN_IP:54868 --> 2.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:23.226338648+08:00" level=info msg="[UDP] WAN_IP:54729 --> 1.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:23.226967931+08:00" level=info msg="[UDP] WAN_IP:51391 --> 3.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:23.228934833+08:00" level=info msg="[UDP] WAN_IP:42852 --> 0.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:24.4772511+08:00" level=info msg="[UDP] WAN_IP:46879 --> 1.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:24.477269343+08:00" level=info msg="[UDP] WAN_IP:43042 --> 2.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:25.703822621+08:00" level=info msg="[UDP] WAN_IP:34704 --> 0.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:25.703940449+08:00" level=info msg="[UDP] WAN_IP:39372 --> 1.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:25.703882652+08:00" level=info msg="[UDP] WAN_IP:47241 --> 3.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:27.005962075+08:00" level=info msg="[UDP] WAN_IP:50227 --> 2.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:27.006037055+08:00" level=info msg="[UDP] WAN_IP:41125 --> 1.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:27.006028116+08:00" level=info msg="[UDP] WAN_IP:60895 --> 3.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:28.278831974+08:00" level=info msg="[UDP] WAN_IP:51868 --> 3.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:28.27889448+08:00" level=info msg="[UDP] WAN_IP:36505 --> 0.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:29.498947067+08:00" level=info msg="[UDP] WAN_IP:40863 --> 2.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:29.499015186+08:00" level=info msg="[UDP] WAN_IP:40395 --> 3.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:30.750669691+08:00" level=info msg="[UDP] WAN_IP:47885 --> 0.openwrt.pool.ntp.org:123 match GeoSite(geolocation-!cn) using PROXY[S2]"

root@OpenWrt:~# opkg update
Downloading https://downloads.openwrt.org/releases/23.05.4/targets/TARGET/SUB_TARGET/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_core
Downloading https://downloads.openwrt.org/releases/23.05.4/targets/TARGET/SUB_TARGET/packages/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/releases/23.05.4/packages/ARCHITECTURE/base/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_base
Downloading https://downloads.openwrt.org/releases/23.05.4/packages/ARCHITECTURE/base/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/releases/23.05.4/packages/ARCHITECTURE/luci/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_luci
Downloading https://downloads.openwrt.org/releases/23.05.4/packages/ARCHITECTURE/luci/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/releases/23.05.4/packages/ARCHITECTURE/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_packages
Downloading https://downloads.openwrt.org/releases/23.05.4/packages/ARCHITECTURE/packages/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/releases/23.05.4/packages/ARCHITECTURE/routing/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_routing
Downloading https://downloads.openwrt.org/releases/23.05.4/packages/ARCHITECTURE/routing/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/releases/23.05.4/packages/ARCHITECTURE/telephony/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_telephony
Downloading https://downloads.openwrt.org/releases/23.05.4/packages/ARCHITECTURE/telephony/Packages.sig
Signature check passed.

root@OpenWrt:~# grep downloads.openwrt.org /etc/mihomo/run/core.log 
time="2024-08-03T09:53:47.071017559+08:00" level=info msg="[TCP] WAN_IP:46456 --> downloads.openwrt.org:443 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:48.444233291+08:00" level=info msg="[TCP] WAN_IP:46472 --> downloads.openwrt.org:443 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:49.306602609+08:00" level=info msg="[TCP] WAN_IP:46480 --> downloads.openwrt.org:443 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:50.501861783+08:00" level=info msg="[TCP] WAN_IP:46486 --> downloads.openwrt.org:443 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:51.390064626+08:00" level=info msg="[TCP] WAN_IP:46490 --> downloads.openwrt.org:443 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:53.051296064+08:00" level=info msg="[TCP] WAN_IP:53930 --> downloads.openwrt.org:443 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:54.132584092+08:00" level=info msg="[TCP] WAN_IP:53938 --> downloads.openwrt.org:443 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:55.897495033+08:00" level=info msg="[TCP] WAN_IP:53940 --> downloads.openwrt.org:443 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:56.80863912+08:00" level=info msg="[TCP] WAN_IP:53942 --> downloads.openwrt.org:443 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:57.73271956+08:00" level=info msg="[TCP] WAN_IP:53950 --> downloads.openwrt.org:443 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:53:58.689638669+08:00" level=info msg="[TCP] WAN_IP:53962 --> downloads.openwrt.org:443 match GeoSite(geolocation-!cn) using PROXY[S2]"
time="2024-08-03T09:54:00.038815251+08:00" level=info msg="[TCP] WAN_IP:53970 --> downloads.openwrt.org:443 match GeoSite(geolocation-!cn) using PROXY[S2]"

morytyann commented 2 months ago

我想说的其实就一个事，除非应用配置了自己的DNS（例如Chrome浏览器配置DoH），否则都会使用系统默认的DNS，使用默认DNS，默认DNS是127.0.0.1和::1，那就一定会被劫持到核心，你说的问题不是这个原因导致的

ForestL18 commented 2 months ago

我之前确实判断失误了，不是向lan ip发起请求，而是向::1发起了请求，而脚本里只劫持了127.0.0.1，从tcpdump日志中也可以看出😥

root@ImmortalWrt:~# nslookup www.baidu.com ::1
Server:         ::1
Address:        [::1]:53

Non-authoritative answer:
www.baidu.com   canonical name = www.a.shifen.com
Name:   www.a.shifen.com
Address: 180.101.50.188
Name:   www.a.shifen.com
Address: 180.101.50.242

Non-authoritative answer:
www.baidu.com   canonical name = www.a.shifen.com
Name:   www.a.shifen.com
Address: 240e:ff:e020:966:0:ff:b042:f296
Name:   www.a.shifen.com
Address: 240e:ff:e020:9ae:0:ff:b014:8e8b

    127.0.0.1.53 > 127.0.0.1.34442: 326* 1/0/0 mirrors.vsean.net. A 198.18.0.14 (51)
11:00:09.944223 lo    In  IP (tos 0x0, ttl 64, id 24396, offset 0, flags [DF], proto UDP (17), length 63)
    127.0.0.1.53 > 127.0.0.1.34442: 618* 0/0/0 (35)
11:00:09.944309 lo    In  IP6 (flowlabel 0x022e5, hlim 64, next-header UDP (17) payload length: 88) ::1.53 > ::1.34442: [bad udp cksum 0x006b -> 0xf7b7!] 326 2/0/0 mirrors.vsean.net. CNAME ctyun.vsean.net., ctyun.vsean.net. A 1.82.221.105 (80)
11:00:09.944997 lo    In  IP6 (flowlabel 0x022e5, hlim 64, next-header UDP (17) payload length: 72) ::1.53 > ::1.34442: [bad udp cksum 0x005b -> 0x86c3!] 618 1/0/0 mirrors.vsean.net. CNAME ctyun.vsean.net. (64)
11:00:10.744610 lo    In  IP6 (flowlabel 0x7fba5, hlim 64, next-header UDP (17) payload length: 43) ::1.41976 > ::1.53: [bad udp cksum 0x003e -> 0xc992!] 62950+ A? mirrors.vsean.net. (35)
11:00:10.744653 lo    In  IP6 (flowlabel 0x7fba5, hlim 64, next-header UDP (17) payload length: 43) ::1.41976 > ::1.53: [bad udp cksum 0x003e -> 0xad6e!] 63242+ AAAA? mirrors.vsean.net. (35)
11:00:10.745079 lo    In  IP (tos 0x0, ttl 64, id 24595, offset 0, flags [DF], proto UDP (17), length 79)

morytyann commented 2 months ago

你开启IPv6代理了吗？

ForestL18 commented 2 months ago

你开启IPv6代理了吗？

没有，但是路由器本机默认会去向::1发起本地查询，应该和/tmp/resolv.conf设置有关

morytyann commented 2 months ago

明白了，你觉得应该都劫持而不是在开启IPv4/IPv6代理时劫持对应的DNS

ForestL18 commented 2 months ago

明白了，你觉得应该都劫持而不是在开启IPv4/IPv6代理时劫持对应的DNS

是的，一劳永逸。大部分情况下，其实你不开ipv6代理，openwrt也会默认向::1发起请求。

morytyann commented 2 months ago

不合理，假设改成劫持双栈DNS请求，仅开启IPv4代理，DNS模式为Fake-IP，这时某个客户端发起了IPv6的DNS请求，会被劫持到核心，返回了Fake-IP，对Fake-IP的请求会进入核心（因为它是IPv4地址），但这个域名本来是有IPv6地址的（极端情况甚至只有IPv6地址），访问IPv6地址不应该进入核心，这将是一个预期外的行为

morytyann commented 2 months ago

Host那个，你的意思是，像OpenClash一样直接用输入框编写，其实现在就可以，直接在混入文件内容编写即可，不需要再加新的单独的框了

ForestL18 commented 2 months ago

不合理，假设改成劫持双栈DNS请求，仅开启IPv4代理，DNS模式为Fake-IP，这时某个客户端发起了IPv6的DNS请求，会被劫持到核心，返回了Fake-IP，对Fake-IP的请求会进入核心（因为它是IPv4地址），但这个域名本来是有IPv6地址的（极端情况甚至只有IPv6地址），访问IPv6地址不应该进入核心，这将是一个预期外的行为

在仅开启ipv4代理的情况下：

对于纯ipv6网站：仅开启ipv4代理，向双栈dns发起请求时，127.0.0.1被劫持，::1不被劫持，mihomo查询不到ipv4地址无法连接，路由器本机通过::1查询到ipv6地址成功连接。

对于ipv4/ipv6双栈网站：仅开启ipv4代理，向双栈dns发起请求时，127.0.0.1被劫持，::1不被劫持，mihomo查询到ipv4地址成功连接，路由器本机通过::1查询到ipv4/ipv6，这个时候如果优先连接了ipv6，则和纯ipv6情况相同；如果优先连接了ipv4，就会导致mihmo连接到解析过的IP，造成分流错误。

对于纯ipv4网站：仅开启ipv4代理，向双栈dns发起请求时，127.0.0.1被劫持，::1不被劫持，mihomo查询到ipv4地址成功连接，路由器本机通过::1查询到ipv4地址，导致mihmo连接到解析过的IP，造成分流错误。

由此可见，在仅开启ipv4的情况下，不劫持::1，只有纯ipv6网站和优先连接ipv6网站能按预期连接，但是这两种情况相较ipv4来说，所占网络流量还是比较少的。

所以在仅开启ipv4代理的情况下，如果不想劫持::1，那就只能通过修改dnsmasq配置或者完全禁用ipv6。

同时我认为仅开启ipv4代理相当于默认代理流量和直连流量都只有ipv4，毕竟mihomo接管了所有流量。

ForestL18 commented 2 months ago

Host那个，你的意思是，像OpenClash一样直接用输入框编写，其实现在就可以，直接在混入文件内容编写即可，不需要再加新的单独的框了

关键是现在混入文件那个框有bug

morytyann commented 2 months ago

你是觉得Mihomo会请求DNSMASQ？还是说认为DNS请求会直接走::1而不是按/tmp/resolv.conf的顺序？

ForestL18 commented 2 months ago

你是觉得Mihomo会请求DNSMASQ？还是说认为DNS请求会直接走::1而不是按/tmp/resolv.conf的顺序？

mihomo不会请求dnsmasq，但路由器本机的程序发起dns请求时确实是同时向127.0.0.1和::1发起请求。

比如opkg update，luci界面更新和命令行更新应该都会触发

ForestL18 commented 2 months ago

如果不做任何劫持和处理，确实无法解决我上面提到的分流错误的问题🫠

morytyann commented 2 months ago

resolv.conf queries them in the order listed will wait for a response from a remote name server before retrying the query via a different name server

ForestL18 commented 2 months ago

resolv.conf queries them in the order listed will wait for a response from a remote name server before retrying the query via a different name server

他这个说的不是remote nameserver吗？而且根据我上面的tcpdump日志，对于本地127和::1确实是同时发起请求的啊

morytyann commented 2 months ago

他这个说的不是remote nameserver吗？

remote这个单词，通篇只出现了一次，那我请问是在哪里配置的remote nameserver呢？难道不是nameserver这一项吗……

而且根据我上面的tcpdump日志，对于本地127和::1确实是同时发起请求的啊

那只能是ImmortalWrt和官方的区别导致的了

morytyann commented 2 months ago

知道了，确实是会并发，OpenWrt使用的是musl libc而不是glibc，在这里有说到，musl’s resolver queries them all in parallel and accepts whichever response arrives first.，我这里不能复现可能是因为127.0.0.1总是最快的……

ForestL18 commented 2 months ago

知道了，确实是会并发，OpenWrt使用的是musl libc而不是glibc，在这里有说到，musl’s resolver queries them all in parallel and accepts whichever response arrives first.，我这里不能复现可能是因为127.0.0.1总是最快的……

啊这，我没看文档来着，但是测试上看确实是并发，所以我还是建议要么劫持双栈dns，由mihomo来refuse ipv6 result；要么就禁用上游解析，由dnsmasq来refuse ipv6 result。

ForestL18 commented 2 months ago

还有就是希望可以考虑我上面说的那个功能，使用编辑器这个页面来显示混合后的配置文件，以方便check在luci界面上的操作有没有生效

morytyann commented 2 months ago

已经PUSH到#50分支了，正在Build

已处理的：

DNS双栈劫持
添加覆盖Hosts开关
修复文件编辑不能清空文件的问题
添加GeoIP(ASN) 下载地址选项
查看用于启动的配置文件

不会处理的：

关闭DNSMASQ的DNS 重定向

首先此选项为ImmoralWrt独有，其次我不会采用直接修改其他插件配置的方式

更新订阅

每次启动时都会下载最新的文件，请使用重启来更新订阅

混入配置中的列表的输入框

请使用混入文件内容

ForestL18 commented 2 months ago

感谢作者，已经下载测试，没有问题。功能已经全部正常了。🤩

同时有几个小细节我想说一下，大佬可以酌情修改，并不影响基础功能：

插件更新后必须要手动清除缓存才能让新的设置在luci界面生效，后续可以优化下
DNS配置中的使用hosts和覆盖hosts可以做成上下级菜单的样式，只有勾选使用hosts才会出现覆盖hosts，结构看上去更清晰
编辑器中的混入后配置文件可以不给写权限，只要能读就行了，毕竟即使做了修改还是会在保存其他修改时被覆盖

还有一点就是三个安装包必须依次安装，可否考虑封装到一个包中方便安装👍

morytyann commented 2 months ago

1和2没啥太大影响，不改了，关于3其实有一个用法，可以直接修改用于启动的配置文件，再到面板中进行重载配置，可以方便便直接调试一些配置关于打包这个，有两点，一是我希望与官方的方式保持一致，二是可以做到不依赖LuCI管理就可以启动（即只安装mihomo.ipk，手动配置和启动服务）

ForestL18 commented 2 months ago

还有个小问题就是内核日志里会出现 level=error msg="[GEO] Get GEO database update time error: stat /etc/mihomo/run/geoip.metadb: no such file or directory"

我记得我没配置过geoip.metadb，是什么默认设置吗？

morytyann commented 2 months ago

看源码应该是这里打印的日志，错误来自这里，最根本的原因是这里，如果找不到Country.mmdb、geoip.db、geoip.metadb这三个文件，就默认返回geoip.metadb，你应该选择了GeoIP使用mmdb格式，文件不存在的原因就不清楚了

ForestL18 commented 2 months ago

看源码应该是这里打印的日志，错误来自这里，最根本的原因是这里，如果找不到Country.mmdb、geoip.db、geoip.metadb这三个文件，就默认返回geoip.metadb，你应该选择了GeoIP使用mmdb格式，文件不存在的原因就不清楚了

感谢提示。🤗我看了下我的内核workdir，只有asn.mmdb，原因是我只是用了asn规则，所以其他数据集就都没下载。

morytyann / OpenWrt-mihomo

关于 TUN mode 的问题以及几个建议 #50