search

xiaorouji / openwrt-passwall

7.18k stars 2.64k forks source link

[Bug]: 将smartdns第二DNS服务器作为上游服务器似乎不work #2162

Closed moetayuko closed 1 year ago

moetayuko commented 2 years ago

描述您遇到的bug

按照https://github.com/luckyyyyy/blog/issues/57 配置的大致效果为：

因此从7913解析时会先经过第二DNS服务器，再从真·上游服务器解析。而从53解析时流程如下：

  1. 待解析域名匹配到domain-rules，group被设为passwall_proxy
  2. 向同为passwall_proxy的伪·上游服务器请求结果
  3. 请求转发到7913的第二DNS服务器
  4. 向同为passwall的真·上游服务器请求结果

以上流程看似没有问题，但我这里nslookup twitter.com 127.0.0.1:7913是work的，nslookup twitter.com 127.0.0.1:53会报错SERVFAIL，smartdns的日志也显示解析错误。如果再添加一个group为passwall_proxy的上游服务器并指向1.1.1.1就能在53也正常解析，因此怀疑上述2->3这步不通，并有如下问题：

  1. smartdns本身是否支持这种“自己是自己上游”的套娃操作？
  2. 为什么要走7913绕一圈，而不是直接让用户添加group为passwall_proxy的上游？

复现此Bug的步骤

n/a

您想要实现的目的

让53端口正常解析代理域名

日志信息

n/a

截图

No response

系统相关信息

其他信息

https://github.com/xiaorouji/openwrt-passwall/issues/2111#issuecomment-1288007683

本来是通过调用第二dns服务器的组成员，但是现在不起作用

可能有点关联

ololllolo commented 2 years ago

这个问题我早早遇到了，困扰了我很久，经过了各种测试，大概理解是这样的： /var/etc/smartdns/passwall.conf 文件是passwall生成的，在选择DNS分流模式为smartdns的时候就生成这个文件，这个文件很奇怪的把生成的域名表指向到了passwall_proxy这个组。这个时候，smartdns是无法生效的，我一直没能理解为何不能生效，可能是因为不存在这个组？

所以我找到了2个方法

  1. smartdns 在36.1之前是没有这个问题的，我拉取了几乎所有的smartdns最近几个月的版本来测试，从36.1以后的版本都存在这个问题。只要passwall的dns分流设置为smartdns，那么默认第二服务器都是无法正常工作的，如果直接从smartdns第二服务器端口测试却发现smartdns是可以正常解析的。所以我现在的固件都是用的36.1这个版本。

  2. 将dns分流模式改为dnsmasq，这时候passwall不会生成/var/etc/smartdns/passwall.conf这个文件了，在passwall的日志也能看到，已经分流为两个端口分别对应smartdns的两个服务器。这个时候是可以正常工作的，但这个时候的解析一定是有一些问题的，比如经过dns泄露测试，可以看到即便是过了代理加密的dns，都被识别出来了。如果运行的是smartdns 36.1，dns泄露只能查询到国内的分组。我大量的查阅smartdns的debug日志，但是由于水平有限，仍然无法理解为何会出现这个问题。

这个问题困扰了我很久，这是一个典型的，在passwall上提问，感觉好像是smartdns的问题，在smartdns上提问，又好像是passwall的问题，加上水平有限，不确定到底是哪里出现问题，直到看到楼主也遇到了同样的问题。

moetayuko commented 2 years ago

我目前的方案是passwall的dns分流设置为smartdns但远程dns选1.1.1.1，并且不开第二dns服务器（开了也用不上），这样生成的/var/etc/smartdns/passwall.conf第一行为server 1.1.1.1 -group passwall_proxy -exclude-default-group，相当于在passwall_proxy组里直接加了一个上游服务器

这个问题困扰了我很久，这是一个典型的，在passwall上提问，感觉好像是smartdns的问题，在smartdns上提问，又好像是passwall的问题，加上水平有限，不确定到底是哪里出现问题，直到看到楼主也遇到了同样的问题。

这个确实，因为“smartdns自己是自己上游”这种套娃操作很奇怪，支不支持都说得过去

SakuraFallingMad commented 2 years ago

那个issue只是提供了思路，在passwall里的处理考虑的是smartdns替代dnsmasq作为分流器的作用，给那些比如我的使用环境设置等，这是我的理解，看看哈。比方我的使用环境，就是不用smartdns的第二服务器，本地用dnscrypt-proxy，那么passwall这样设置并无问题。

wtfr-dot commented 2 years ago

我目前的方案是passwall的dns分流设置为smartdns但远程dns选1.1.1.1，并且不开第二dns服务器（开了也用不上），这样生成的/var/etc/smartdns/passwall.conf第一行为server 1.1.1.1 -group passwall_proxy -exclude-default-group，相当于在passwall_proxy组里直接加了一个上游服务器

这个问题困扰了我很久，这是一个典型的，在passwall上提问，感觉好像是smartdns的问题，在smartdns上提问，又好像是passwall的问题，加上水平有限，不确定到底是哪里出现问题，直到看到楼主也遇到了同样的问题。

这个确实，因为“smartdns自己是自己上游”这种套娃操作很奇怪，支不支持都说得过去 要让smartdns的第二组生效，可以将第一行注释掉，并且将smartdns第二组的组名以及组成员所属组全部改为passwall_proxy，这样工作流程就正常了，缺点是清空passwall的ipset后会恢复回来，但也会正常工作，只是smartdns会绕一下。 我如果在passwall里远程选1.1.1.1doh模式的话，在smartdns的passwall.conf里第一行变成了127.0.0.1:15353，实际上是指向passwall内部dns，smartdns的第二组当然是不起作用了，但为何你的跟我不一样。

moetayuko commented 2 years ago

要让smartdns的第二组生效，可以将第一行注释掉，并且将smartdns第二组的组名以及组成员所属组全部改为passwall_proxy，这样工作流程就正常了，缺点是清空passwall的ipset后会恢复回来，但也会正常工作，只是smartdns会绕一下。

第二组组名叫啥或有没有都无所谓了，因为不会有流量从7913走。组成员所属组全部改为passwall_proxy后会绕过第二dns直接走他们查询。

此外第一行是https://github.com/xiaorouji/openwrt-passwall/blob/53c703afeb8badba22982da0dea3e6e4bb0e64c3/luci-app-passwall/root/usr/share/passwall/helper_smartdns_add.lua#L179 生成的，注释掉这玩意就不会恢复回来

我如果在passwall里远程选1.1.1.1doh模式的话，在smartdns的passwall.conf里第一行变成了127.0.0.1:15353，实际上是指向passwall内部dns，smartdns的第二组当然是不起作用了，但为何你的跟我不一样。

我选的是udp，这样是由smartdns直接发起查询的。选doh会从smartdns转到v2ray/xray内置的dns客户端，将第一行注释后直接在smartdns里加passwall_proxy的doh上游可能更好一些。

ololllolo commented 2 years ago

我总结一下我的理解。 1.分流选择smartdns，生成/tmp/etc/smartdn/passwall.conf 文件。

  1. passwall.conf文件中第一行增加一个dns服务器，指向自己 127.0.0.1:7913 组名passwall_porxy，即前楼主所说的套娃。
  2. 浏览器发出请求，请求一个外网地址，passwall 收到后，扔给smartdns，smartdns根据passwall.conf里面的域名表，选择把请求发给passwall_porxy组，这个组指向自己，然后自己再从第二组服务器得到请求来解析。

根据这个理解，和我测试的情况，应该是这样的，passwall的逻辑并没有变，这个操作在smartdns 36.1之前都是有效的，也可以正常解析，也就是我自己当前的配置。在smartdns 36.1以后的版本，这个调用本身的套娃操作不再工作了，这就是为什么第二服务器失效了。如果分流设置这里的 “远程dns” 设置为一个上游服务器，例如1.1.1.1，那么生成的文件中为smartdns添加一个上游服务器，这时候就可以正常工作了，但是等于第二服务器并未生效，只是将解析指向了一个固定的dns（即1.1.1.1）来解析，也就失去了smartdns可以多dns服务器优化查询的意义。

wtfr-dot commented 2 years ago

我总结一下我的理解。 1.分流选择smartdns，生成/tmp/etc/smartdn/passwall.conf 文件。 2. passwall.conf文件中第一行增加一个dns服务器，指向自己 127.0.0.1:7913 组名passwall_porxy，即前楼主所说的套娃。 3. 浏览器发出请求，请求一个外网地址，passwall 收到后，扔给smartdns，smartdns根据passwall.conf里面的域名表，选择把请求发给passwall_porxy组，这个组指向自己，然后自己再从第二组服务器得到请求来解析。

根据这个理解，和我测试的情况，应该是这样的，passwall的逻辑并没有变，这个操作在smartdns 36.1之前都是有效的，也可以正常解析，也就是我自己当前的配置。在smartdns 36.1以后的版本，这个调用本身的套娃操作不再工作了，这就是为什么第二服务器失效了。如果分流设置这里的 “远程dns” 设置为一个上游服务器，例如1.1.1.1，那么生成的文件中为smartdns添加一个上游服务器，这时候就可以正常工作了，但是等于第二服务器并未生效，只是将解析指向了一个固定的dns（即1.1.1.1）来解析，也就失去了smartdns可以多dns服务器优化查询的意义。

你的理解是对的，目前可以解决的方案是将smartdns的第二服务器组名和第二服务器组成员里的上游服务器所属组都改为passwall_proxy，smartdns和passwall都可以正常工作，如果第二服务器组名不改，也可以正常工作，但第二服务器设置的功能就没有用了

wtfr-dot commented 2 years ago

要让smartdns的第二组生效，可以将第一行注释掉，并且将smartdns第二组的组名以及组成员所属组全部改为passwall_proxy，这样工作流程就正常了，缺点是清空passwall的ipset后会恢复回来，但也会正常工作，只是smartdns会绕一下。

第二组组名叫啥或有没有都无所谓了，因为不会有流量从7913走。组成员所属组全部改为passwall_proxy后会绕过第二dns直接走他们查询。

此外第一行是

https://github.com/xiaorouji/openwrt-passwall/blob/53c703afeb8badba22982da0dea3e6e4bb0e64c3/luci-app-passwall/root/usr/share/passwall/helper_smartdns_add.lua#L179

生成的，注释掉这玩意就不会恢复回来

我如果在passwall里远程选1.1.1.1doh模式的话，在smartdns的passwall.conf里第一行变成了127.0.0.1:15353，实际上是指向passwall内部dns，smartdns的第二组当然是不起作用了，但为何你的跟我不一样。

我选的是udp，这样是由smartdns直接发起查询的。选doh会从smartdns转到v2ray/xray内置的dns客户端，将第一行注释后直接在smartdns里加passwall_proxy的doh上游可能更好一些。

你是源码里把这一行注释掉了？我是在生成的配置文件里去注释掉的，这样清空ipset就会恢复原状，如果不需要恢复原状，不用注释源码整行，只需这样改 179 sys.call(string.format('echo "# server %s -group %s -exclude-default-group" >> %s', TUN_DNS, REMOTE_GROUP, CACHE_DNS_FILE)) ，生成的配置文件自动就把第一行注释掉了，然后smartdns里全部改为passwall_proxy就完美运行了，smartdns加载的上游服务器里就没有127.0.0.1了。

moetayuko commented 2 years ago

你是源码里把这一行注释掉了？我是在生成的配置文件里去注释掉的，这样清空ipset就会恢复原状

我没动源码，只是说可以通过这种方式让他不生成第一行

github-actions[bot] commented 2 years ago

Stale Issue

moetayuko commented 2 years ago

bump

github-actions[bot] commented 1 year ago

Stale Issue

moetayuko commented 1 year ago

bump

github-actions[bot] commented 1 year ago

Stale Issue