Closed yukeiyang closed 1 year ago
反复测试后,发现这两个 issues 皆因启用 doh (dns over https) 所导致,DNS 填入 ip 地址时,这两个 issues 就会消失。但 dns 使用 IP 会被探测并封锁,使用 doh 似乎已成为刚需。
反复测试后,发现 3 个 issues:
实测近年来使用 ip dns 方式,因为明文发送的原因,The Wall 已能应对, 故近年来严重封堵网络环境中会高度依赖 DoH。
Fast DNS | Secure DNS | Default DNS 三者皆使用 dns over https 地址时,才能有效正常科学上网, 但需能定义 hosts 以解决 DoH 域名的自身解析问题。
当然使用 https://8.8.8.8/dns-query 等等的 ip ssl 会无 resolve itself 的问题,但 8.8.8.8 此类 ip 往往被封堵了。
现在大家一般采用自配 DoH server 来解决这个问题,问题是 SSL 证书一般都针对 domain 发放,针对 ip 地址的 ssl 证书是极其难于获取的。
也就是说,最佳的方式就是,所有 Fast DNS | Secure DNS | Default DNS 查询都交给 DoH 处理,但需要 xray 能设置 hosts 以解决 resolve itself 的问题。
虽然我觉得你的用法并不是最佳的(之前有提过,比较推荐的做法是 Fast DNS 写一个 114.114.114.114 这种国内的,Secure 和 Default 写 8.8.8.8 这种海外的,然后海外 DNS 请求实际都会被 Xray 转发出去,也就不存在明文发送被 GFW 抢答的问题)。。。
如果只是想改 Hosts 的话,自己改一下 dnsmasq 的配置
但对这个 luci 来说其实也是有必要做的,方法大概会是启动的时候顺便改一下 dnsmasq 的配置,最近太忙了,后面搞搞看
@yichya 感谢回复。
我的最终解决方案是,自配 DNS Server 来替换 114.114.114.114。 目前自配的 DNS 采用 Adguard Home 搭建,截止今天运作正常。看看未来何如。
不过, Fast DNS 现在目测填入 DoH 地址,就无法连接 internet。 所以我另外自配的这台 DNS Server 没开启 DoH,而是采用 UDP IP 模式。
不知 Fast DNS 现在不能使用 DoH 是不是一个 bug.
回报,openwrt 修改 dnsmaq hostnames 的方法经测试,仍然不能解决 [Error] app/dns: DOH//dns.dns-over-https.top tries to resolve itself! Use IP or set "hosts" instead. 问题。
- 重度科学上网环境下,114.114.114.114 会稳定运行一段时间,然后这个 DNS 就废了。
你说的「废了」是指什么现象?
不过, Fast DNS 现在目测填入 DoH 地址,就无法连接 internet。 所以我另外自配的这台 DNS Server 没开启 DoH,而是采用 UDP IP 模式。
之前直接合了的那个 #69 还是有些问题的,因为 Fast DNS 和 Default DNS 涉及到 Xray 之外的配置(比如 Fast DNS 会拿去给 dnsmasq 用),目前就是没有办法填 DoH 的,只能写 IP,这个暂时改回去了。
也就是说,使用 114.114.114.114 较长一段时间后,Fast DNS 使用这个 IP 会被 block, 而无法上网。119.29.29.29 也有这个问题,不过程度没这么严重。
我猜测有部分漏网的 GFW 封堵列表中的 domains, 总会有持续向 114.114.114.114 请求解析的情形,累计到一定次数后,墙内的 DNS 譬如 114.114.114.114 抑或腾讯 DNS 阿里 DNS 会屏蔽其它请求。
目测现在唯一稳定的方法是,自配一个 IP 类的 DNS Server,供 Fast DNS 使用。
不过真心说,你开发的这个 luci-app-xray 真的很赞。
深圳移动宽带,500M带宽,我采用软路由,目前可以跑到 580M的带宽。
关键是,luci-app-xray 加持的科学上网,连接 Youtube 可以达到 220M 的平均带宽。
Apple TV 上播放 4K 视频那叫一个流畅。
也就是说,使用 114.114.114.114 较长一段时间后,Fast DNS 使用这个 IP 会被 block, 而无法上网。119.29.29.29 也有这个问题,不过程度没这么严重。
具体一点呢,这个 block 是说解析完全没结果,还是被污染了?
我猜测有部分漏网的 GFW 封堵列表中的 domains, 总会有持续向 114.114.114.114 请求解析的情形,累计到一定次数后,墙内的 DNS 譬如 114.114.114.114 抑或腾讯 DNS 阿里 DNS 会屏蔽其它请求。
实话说你说的这个事情我从来没遇到过。。。我就平平无奇联通用户,宽带或者 4g 都没见过这种情况
家里的 notebook 使用 windows, 没安装 dnslookup 调试工具,没进一步测试到底是 block 还是被污染了。
高概率预估是DNS 服务商污染了,因为换个其它 DNS 就好了。
家里的 notebook 使用 windows, 没安装 dnslookup 调试工具,没进一步测试到底是 block 还是被污染了。
高概率预估是DNS 服务商污染了,因为换个其它 DNS 就好了。
最好还是能确认一下,因为这个现象完全是预期外的,明确一点比较好彻底解决
我好像知道了。。。你看一下你的 dnsmasq 的版本是不是 2.86,这个版本似乎有点行为上的变化,我这边今天突然发现这里开始不对了
我的 dnsmasq 版本是 2.85
辛苦帮看一下这两个地方
Strict Order
和 All Servers
Okay, I will now
我的默认设置如图。
这个果然变了。。。又要头疼了
你可以试试钩上上面的 Strict Order,然后 Fast DNS 还是正常写 114.114.114.114,Default DNS 还是写比如 8.8.8.8 或者 4.2.2.1 这种海外的,然后跑几天看看还有没有那种被 block 的情况
Okay, I will try now.
勾选 Strict Order, 然后 114.114.114.114 填 Fast DNS, 网络不通。
114.114.114.114 应该是 block 了。
119.29.29.29 部分残了,我倒是可以填 119.28.28.28 测试几天看看。
勾选 Strict Order, 然后 114.114.114.114 填 Fast DNS, 网络不通。
这个不通的表现是啥?
我看看能不能安装下 dnslookup 组件到 Windows, 然后查下。
C:\Windows\system32>dnslookup cloudbreakthrough.tk 114.114.114.114 dnslookup v1.4.9 2021/09/19 14:31:45 Cannot make the DNS request: read udp 192.168.100.172:65280->114.114.114.114:53: i/o timeout
1.1.1.1 则正常。如下:
C:\Windows\system32>dnslookup cloudbreakthrough.tk 1.1.1.1 dnslookup v1.4.9 dnslookup result: ;; opcode: QUERY, status: NOERROR, id: 19598 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION: ;cloudbreakthrough.tk. IN A
;; ANSWER SECTION: cloudbreakthrough.tk. 300 IN A 103.135.250.136
测试是在 Fast DNS 填写其它 dns ip 非 114.114.114.114 时进行的。
显然 114.114.114.114 端 block 了我的查询。
C:\Windows\system32>dnslookup cloudbreakthrough.tk 114.114.114.114 dnslookup v1.4.9 2021/09/19 14:31:45 Cannot make the DNS request: read udp 192.168.100.172:65280->114.114.114.114:53: i/o timeout
啊这。。。。。。。。。。。。。
这样,你看一下这个文件,直接用你的宽带运营商给的 DNS 或者上级路由发下来的 DNS 填进 Fast DNS 试试看
Okay
root@OpenWrt:/tmp/resolv.conf.d# cat resolv.conf.auto
nameserver 192.168.1.1
nameserver fe80::1%eth0
那就在 Fast DNS 上写 192.168.1.1
填写 192.168.1.1 可正常上网及出墙。 但 dnslookup 使用 114.114.114.114 仍然不通。
C:\Windows\system32>dnslookup cloudbreakthrough.tk 114.114.114.114
dnslookup v1.4.9
2021/09/19 14:45:32 Cannot make the DNS request: read udp 192.168.100.172:61961->114.114.114.114:53: i/o timeout
C:\Windows\system32>dnslookup cloudbreakthrough.tk 192.168.1.1
dnslookup v1.4.9
dnslookup result:
;; opcode: QUERY, status: NOERROR, id: 62124
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;cloudbreakthrough.tk. IN A
;; ANSWER SECTION:
cloudbreakthrough.tk. 519 IN A 103.135.250.136
填写 192.168.1.1 可正常上网及出墙。 但 dnslookup 使用 114.114.114.114 仍然不通。
那可能真的是你的网络环境比较神奇。。。
你可以就用着 192.168.1.1,这个其实是最推荐的,因为最快(没有自动做的原因是搞起来很麻烦)
需要勾选 Strict Order ?
需要勾选 Strict Order ?
2.85 不知道需不需要勾,2.86 不勾大概是有问题了。你可以都试试看
@yichya 我重新编译后的 ipk 文件,请问在已安装过 luci-app-xray 的机器上reinstall 的标准做法是怎样的?
因为我注意到你最近 20 天做了不少的 commit 更新。
@yichya 我重新编译后的 ipk 文件,请问在已安装过 luci-app-xray 的机器上reinstall 的标准做法是怎样的?
我一般都是直接重新整个编译一遍 openwrt 的。这个正常就该怎么装就怎么装就是了。。。应该没啥特别的
@yichya I see, Thank you.
我想可能的方法:
opkg remove luci-app-xray 然后 opkg install luci-app-xray
@yichya 再次回报。
FastDNS 使用 192.168.1.1 已接近半个月,与填写 114.114.114.114 相似的 issue 再次出现。
毕竟 192.168.1.1 最终使用的 DNS 仍然是接入商的 DNS, 使用久了还是会出现问题。
最保险的做法看来还是使用自建 DNS Server 来做 FastDNS。
切换回我自建的 DNS 后, 一切网页可恢复到秒开的状态。
可能国内 DNS - 包括 114.114.114.114 以及腾讯-阿里等,都按照指示,使用了特殊机制来侦测重度科学上网用户,并进行封堵。
不过自建 DNS Server 的确用起来非常流畅。
1. 出现以下 issue,可能需要设置 hosts,哪里可以设置呢?
[Error] app/dns: DOH//dns.dns-over-https.top tries to resolve itself! Use IP or set "hosts" instead.
2. 以下 warning 是否是由 ipv6 引起,我尝试将 ipv6 关闭后,仍然有此提示,请问可以怎么消除?
Thu Sep 9 08:14:12 2021 daemon.info xray[5253]: 2021/09/09 00:14:12 [Warning] proxy/dns: failed to dial outbound connection > address https://dns.dns-over-https.top/dns-query:53: too many colons in address