近期我的Openwrt 路由器使用了天灵的Homeproxy进行科学上网。Homeproxy是基于Sing-box的,我这里使用了Smartdns和Homeproxy配合,开机后会出现死机、卡机的情况。不使用其他工具软件配合,只使用Sing-box内置的功能那么使用起来问题不大。
Sing-box内置了dns功能,在Homeproxy中,所有dns的请求都需要经过Singbox的dns服务器,也就是5333端口。Singbox根据设置的DNS规则调用不同的上游dns服务器进行解析。由于Singbox的dns服务不是专业的dns服务程序,很多高级功能没有,比如域名集合别名、IPset和NFTset集合等等,所以我这里还是用的Smartdns作为Singbox DNS的上游DNS服务器。但是从安装以来,一直存在开机后如果电脑访问网页会卡死的问题,需要不操作一段时间或修改一下端口、缓存等等,才能正常工作。
这次新编译了官方openwrt,开机后访问部分网站没问题,部分网站又发生了以上问题。后直接打开Homeproxy的日志,等级调为warning。可以看到,在开机不久,访问网页会出现成千上万条一样的日志,观察htop
,发现cpu直接100%,其中smartdns、Singbox耗用cpu各半。
+0000 2024-08-16 23:25:50 ERROR dns: exchange failed for _7826._https.broadcast.chat.bilibili.com. IN HTTPS: context canceled +0000 2024-08-16 23:25:50 ERROR dns: exchange failed for _7826._https.broadcast.chat.bilibili.com. IN HTTPS: context canceled +0000 2024-08-16 23:25:50 ERROR dns: exchange failed for _7826._https.broadcast.chat.bilibili.com. IN HTTPS: context canceled +0000 2024-08-16 23:25:50 ERROR dns: exchange failed for _7826._https.broadcast.chat.bilibili.com. IN HTTPS: context canceled +0000 2024-08-16 23:25:50 ERROR dns: exchange failed for _7826._https.broadcast.chat.bilibili.com. IN HTTPS: context canceled +0000 2024-08-16 23:25:50 ERROR dns: exchange failed for _7826._https.broadcast.chat.bilibili.com. IN HTTPS: context canceled +0000 2024-08-16 23:25:50 ERROR dns: exchange failed for _7826._https.broadcast.chat.bilibili.com. IN HTTPS: context canceled +0000 2024-08-16 23:25:50 ERROR dns: exchange failed for _7826._https.broadcast.chat.bilibili.com. IN HTTPS: context canceled +0000 2024-08-16 23:25:50 ERROR dns: exchange failed for _7826._https.broadcast.chat.bilibili.com. IN HTTPS: context canceled +0000 2024-08-16 23:25:50 ERROR dns: exchange failed for _7826._https.broadcast.chat.bilibili.com. IN HTTPS: context canceled +0000 2024-08-16 23:25:50 ERROR dns: exchange failed for _7826._https.broadcast.chat.bilibili.com. IN HTTPS: context canceled
关闭网页后,cpu耗用下降,但是内存占用不降低。达到800M之多。将Homeproxy的日志,等级调为info,再次访问任意网站,不出意外,日志又出现成千上万的同样日志,但是内容不一样了。
+0000 2024-08-17 00:25:38 INFO dns: exchanged pcrec.baidu.com HTTPS . 600 IN HTTPS 0 . +0000 2024-08-17 00:25:38 INFO dns: exchanged www.baidu.com HTTPS . 600 IN HTTPS 0 . +0000 2024-08-17 00:25:38 INFO dns: exchanged www.baidu.com HTTPS . 600 IN HTTPS 0 . +0000 2024-08-17 00:25:38 INFO dns: exchanged www.baidu.com HTTPS . 600 IN HTTPS 0 . +0000 2024-08-17 00:25:38 INFO dns: exchanged pcrec.baidu.com HTTPS . 600 IN HTTPS 0 . +0000 2024-08-17 00:25:38 INFO dns: exchanged www.baidu.com HTTPS . 600 IN HTTPS 0 . +0000 2024-08-17 00:25:38 INFO dns: exchanged pcrec.baidu.com HTTPS . 600 IN HTTPS 0 . +0000 2024-08-17 00:25:38 INFO dns: exchanged www.baidu.com HTTPS . 600 IN HTTPS 0 .
可以知道,问题一定出现在HTTPS记录上。
DNS的HTTPS记录 是一种新的DNS资源记录类型,它扩展了传统的DNS功能,以支持HTTPS协议的更高级配置。与A记录(IPv4地址)或CNAME记录(别名)不同,HTTPS记录允许域名直接关联到HTTPS服务的各种参数,例如支持的加密协议、使用的证书等。DNS HTTPS(TYPE65)记录的解析,此功能用于快速DNS查询和解决HTTPS链接相关的问题,目前还是草案,一般这种记录可以用于:
提供快速握手信息,减少TLS连接的延迟。
通知浏览器和其他客户端关于特定服务器配置的详细信息。
在一定程度上,HTTPS记录是ALTSVC(Alternate Service)记录的延续和发展。它可以让客户端知道服务器支持哪些更安全或更优化的连接方式,从而提升安全性和性能。
比如我们查询google.com的https记录:
root@OpenWrt:~# dig -t HTTPS www.google.com @223.5.5.5 +tls ; <<>> DiG 9.18.27 <<>> -t HTTPS www.google.com @223.5.5.5 +tls ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56727 ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; PAD: (87 bytes) ;; QUESTION SECTION: ;www.google.com. IN HTTPS ;; ANSWER SECTION: www.google.com. 1116 IN HTTPS 1 . alpn="h2,h3" ;; Query time: 49 msec ;; SERVER: 223.5.5.5#853(223.5.5.5) (TLS) ;; WHEN: Sat Aug 17 13:43:18 CST 2024 ;; MSG SIZE rcvd: 173 root@OpenWrt:~# dig -t HTTPS pcrec.baidu.com @8.8.8.8 ; <<>> DiG 9.18.27 <<>> -t HTTPS pcrec.baidu.com @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29174 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;pcrec.baidu.com. IN HTTPS ;; ANSWER SECTION: . 30 IN HTTPS 0 . ;; AUTHORITY SECTION: pcrec.baidu.com. 30 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1800 1800 900 604800 86400 ;; Query time: 0 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP) ;; WHEN: Sat Aug 17 13:29:47 CST 2024 ;; MSG SIZE rcvd: 138
可见,查询到了https记录。
” 1 ” 表示优先级(priority)为1,说明是服务模式(ServiceMode)。如果为0 ,说明是域名别名模式(AliasMode),要指定一个别名地址,相当于cname记录。
” . ” 这是 DNS 规范中规定的表示全限定域名(Fully Qualified Domain Name, FQDN)的方式。对于别名模式的 SVCB 记录(HTTPS记录前身),如果目标域名为 “.”,表示没有别名地址,就是该前面的域名,该服务不可用或不存在。这种指示仅供参考,客户端在遇到这种情况时可以选择忽略,并尝试在不使用 SVCB 的情况下进行连接。对于服务模式的 SVCB 记录,如果目标域名为 “.”,表示如果与域名相同,则代表主机;以www.example.com为例,”.”指示主机名(如www)与域名(如example.com)本身相同,没有额外的主机部分,记录是直接应用于www.example.com. 的。
” alpn=”h2,h3″ “由于前面设置了HTTPS记录是服务模式,可以设置该值。指示客户端在与服务器建立TLS连接时,可以通过此字段了解服务器支持的协议。h2 表示 HTTP/2,h3 表示 HTTP/3。这意味着 www.google.com 支持 HTTP/2 和 HTTP/3 协议。
还可以写:
ipv4hint:直接告诉客户端IPv4地址,客户端无需再请求目标域名获取IPv4地址
ipv6hint:直接告诉客户端IPv6地址,客户端无需再请求目标域名获取IPv6地址
pcrec.baidu.com,返回了0 .
,问题就出在0.的记录上,0 .
表示这是别名记录,但没有别名地址,该HTTPS记录不要用。 Singbox似乎对 0 .
这样的HTTPS记录
没有忽略,并尝试在不使用 SVCB 的情况下进行连接,也就不考虑这条HTTPS记录继续连接。Singbox还是继续请求 HTTPS记录 的查询,不断报Context Canceled;也有可能是Smartdns返回给Singbox的值有问题,导致两者不兼容。
可以确定就是因为HTTPS导致了Singbox和smartdns配合出现问题。最后一起将软路由cpu占用到了100%,导致死机。那么解决方法也简单,就是直接禁用smartdns的HTTPS记录解析。不返回给Singbox HTTPS记录,这样Singbox便不再要求smartdns给HTTPS记录。smartdns 自定义设置里面加入:
# 禁止https记录 force-qtype-SOA 65
保存重启一下。果然2者太平无事,软路由又能正常的提供服务了。
技术不断升级,请注意文章时效性。
本站文章,欢迎转发。转载请注明出处:https://www.bandwh.com/net/1796.html
评论列表(2条)
我用的Mosdns 貌似和Homeproxy没有这样的问题
@chris:不清楚mosdns,可能新版singbox解决了这个问题,以前有的。