iKuai爱快流控路由

 找回密码
 立即注册

QQ登录

只需一步,快速开始

查看: 2091|回复: 27
打印 上一主题 下一主题

[问题反馈] 第三方代理DNS存在问题

[复制链接]
跳转到指定楼层
楼主
发表于 2023-9-18 23:17:41 | 只看该作者 |只看大图 回帖奖励 |正序浏览 |阅读模式
目前版本是3.7.5。
当使用第三方DNS服务器时,将dhcp分配dns设置为路由器的ip,下面设备可以拿到设置的dns也就是网关地址,理想下能够正常的解析。


但是,如果有设备在使用dns时,没有使用dhcp下发下dns地址,就会得到超时的结果(某些小米的物联网设备,他会使用114.114.114.114 UDP 请求dns解析)


历经了好几个月追踪有些物联网设备为什么不能升级的原因得出结果,此时将模式设置成非第三方代理模式,一切就正常了。在我的两台设备上能够复现。


这个问题挺严重的,目前无法使用第三方代理功能了,希望爱快重视下。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏1 支持支持 反对反对
推荐
发表于 2023-9-19 11:52:52 | 只看该作者
weiecn 发表于 2023-9-19 11:23第三方代理下,不可以使用强制。
为什么不用运营商dns?
1.运营商抢答DNS,干扰正常域名解析;

什么年代了,怎么还相信是运营商劫持DNS,没有的事,相信下他们。
27#
发表于 2023-9-27 14:41:43 | 只看该作者
爱快的DNS模块一直以来就是个大诟病。连最基本的缓存模式增加个缓存时间调整而取代smartDNS跟adguard(毕竟想避免大量DNS解析直接被block。事件可以去B看海南弱电小胡的视频)的建议,疫情前提的,3年了到现在都没改善。更不要提第三方DNS这个模式的诟病。大家以为设置第三方DNS,就相当于所有内网除第三方DNS外的DNS数据都会强制发到这个第三方DNS,而第三方DNS作为递归解析服务器承担整个内网的解析工作。结果并不是。有时候连第三方自己的DNS都解析不了。整个内网完全上不了网。寄~
26#
发表于 2023-9-27 14:00:40 | 只看该作者
有些设备自己内定了DNS信息。我的做法是NAT下,目标114.114.114.114端口53,nat到自己要的DNS服务器53上即可
25#
 楼主| 发表于 2023-9-27 10:00:37 | 只看该作者
最东风 发表于 2023-9-26 23:45兄弟,你再仔细看看,你说   你认为爱快要在这里    那段回复的想法是不是问题?如果设置了这种第三方代理 ...

如果你还没有懂我得需求,我可以跟你说一下:

1.内网自建DNS(方便控制IPV4/IPV6解析过滤等特殊需求);
2.内网强制代理(内网所有的明文53UDP的dns必须被强制代理);

如果忽略1,可以直接使用爱快的代理模式(UDP或DOH),设置强制客户端dns代理,然后上游设定外网的dns即可;
如果需要实现1,以前爱快没有第三方代理模式功能时,如果直接将上游dns设置为本地自建dns服务器,并开启强制客户端dns代理.此时内网自建DNS也会被爱快强制代理,导致解析不了.
爱快随后加入了第三方代理功能,也就是说设定第三方代理的地址会放行,不再强制代理使用爱快设定的上游dns地址.这些都没有问题,问题就在于一旦开启这个功能,内网就只能用爱快网关或这个自建DNS.外网的dns全部都是超时,也就是说爱快对其拦截了并没有强制代理.
这样是不合理的,爱快这样直接拦截超时就会导致很多设备出问题,因为不是所有的设备都是使用dhcp中分配的dns,也就是我前面所说的.
24#
 楼主| 发表于 2023-9-27 09:41:48 | 只看该作者
如果设置了这种第三方代理服务器,本意是应该想把内网的所有DNS请求都拦截到自建的DNS服务器去查询

目前爱快设置后白不是拦截到自建的,而是让所有非网关/设置的dns全部超时

你试试就知道了,目前开启这个功能,爱快并没有强制代理,而是超时.

我说的很清楚了,如果开启第三方代理,目前本质上和拦截所有的dns无异(除了设定的第三方代理dns和网关)

另外,普通代理模式下,开启强制代理,内网自建的dns会被爱快强制代理导致出错.
自然要设计一个第三方代理,本质上是普通代理模式下的放行内网某个自建dns服务器的dns 53 udp请求.
但是目前版本来说爱快的确放行了该本地dns服务器的放行,却将所有的非爱快网关地址 及 该本地dns服务器的dns请求全部拦截并超时(注意我说的,目前第三方代理并没有强制代理,而是真正的拦截)

我现在并不是说我需要开启第三方代理并同时关闭强制代理 ,相反我正需要这个功能,相当于是普通代理模式的增强功能.
23#
发表于 2023-9-26 23:45:41 | 只看该作者
兄弟,你再仔细看看,你说   你认为爱快要在这里    那段回复的想法是不是问题?如果设置了这种第三方代理服务器,本意是应该想把内网的所有DNS请求都拦截到自建的DNS服务器去查询,如果这种情况下,你可以通过udp 53端口的公网DNS服务器直接去公网查询,那这样你这个DNS查询不就在链路中被漏掉了吗?这还谈什么安全性?就像你建了一座固若金汤的堡垒,然后还留了一条地道可以从外面直通堡垒内,这还安全?可控?那你建堡垒保护什么,还有啥用?
这个第三方DNS服务器不一定是你自建的本地服务器,也可以填公网DNS服务器,所以你那个   只允许使用本地DNS服务器的说法       也不全面,第三方DNS服务器才算是比较全面。
至于你的功能建议你是说在开启了第三方DNS服务器的情况下,加一个是否强制代理的开关,如果选上就代表转发局域网设备的DNS请求,如果取消就代表不拦截局域网设备的DNS请求。
如果你同时开启第三方代理DNS服务器和强制代理,那就和现在的功能没有任何区别啊,依然会拦截所有局域网内对公网DNS发起的udp 53端口的DNS查询。
如果你开启了第三方DNS服务器,同时又取消了强制代理,这就说明这既想要所有DNS请求通过设置的第三方DNS服务器去查询,然后又让这个网关不拦截局域网内所有的DNS的udp53请求,试问爱快怎么确保把局域网内设备的所有DNS请求传递给设置的第三方DNS服务器去解析,这不自相矛盾么?这原本的功能定义也实现不了呀。


消息来自爱快e云
22#
 楼主| 发表于 2023-9-25 13:53:03 | 只看该作者
最东风 发表于 2023-9-25 13:22这个强制代理也只是针对UDP查询的,DOH就拦截不到,所以这个强制并没有想象中那么大的作用。有点我没搞懂 ...

我都说了,不是我用114dns

是有些设备他就是不按dhcp的dns去解析,而是用它自己认为的dns

爱快这边其实只需要把这个强制拦截超时给放开就好了,就不会出这些奇怪的问题了,否则这个第三方代理,就只能改名为"只允许使用本地dns地址:"
21#
发表于 2023-9-25 13:25:36 | 只看该作者
你再自建DNS服务器,最终也还是要通过网络上的公共DNS服务器去获取IP的,不如直接就用个DOH公网服务器,不一样能防劫持吗?


消息来自爱快e云
20#
发表于 2023-9-25 13:22:14 | 只看该作者
这个强制代理也只是针对UDP查询的,DOH就拦截不到,所以这个强制并没有想象中那么大的作用。有点我没搞懂的是,你说的这种在DHCP的情况下是没问题的,那你为什么会让内网的设备在你开启了第三方代理DNS服务器的情况下,都能手动设置DNS了,还要设置114为DNS服务器呢?或者说哪种网络设备这么沙雕,就只把DNS服务器设置为114了,写死了?即便不能更改,他也会通过dhcp去获取DNS吧。


消息来自爱快e云
19#
发表于 2023-9-25 13:14:37 | 只看该作者
weiecn 发表于2023-09-23 21:58:52

客户端千奇百怪,程序员有时候不会按套路出牌,不会用dhcp下发的dns,而是喜欢自己用一个固定的时候就会出问题。
目前已知出问题的有:小米物联网产品,根据我的抓包,他们喜欢先请求114.114.114.114来获取小米自己的doh,然后用doh来解析自己的mqtt的域名。

如果开启第三方代理,由于这个功能并没有强制用户使用代理dns(也就是没有挟持dns),客户端设备在使用114.114.114.114去解析时,就是超时,导致设备出现奇怪问题。


我认为爱快要在这里仍然要设置一个强制客户端DNS代理的选项功能,开启了,就转发请求的任意dns数据,没有开启就不要去拦截任意dns请求,以免设备出现dns无法解析的问题。
可以开启代理模式UDP  开强制代理,然后把DNS设置的首选备选设置为内网自建DNS  然后内网自建的DNS服务器使用DOH的DNS服务器(如阿里云的)作为自建DNS服务器上游DNS,样内网设备发起查询会先拦截到爱快网关,然后爱快向内网自建DNS服务器查询,内网的自建DNS服务器通过DOH对公共DNS服务器查询就可以了,这样回环查询时就不会再次被爱快的代理模式(UDP拦截),会直接到wan口向公网查询了


消息来自爱快e云
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

QQ|小黑屋|手机版|Archiver|论坛规章制度|iKuai Inc. ( 京ICP备13042604号 )

GMT+8, 2024-9-28 05:23

Powered by Discuz! X3.3

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表