luci: add dns redirection and optimization

[lwb1978]

1.添加DNS重定向设置（dns劫持）；
2.顺手优化了“清空 ipset”按钮显示，根据所使用的防火墙工具，该按钮显示为：“清空 NFTSET” 或者 “清空 IPSET” 。

[yk271]

👍

[nftbty]

其实我感觉这个DNS劫持的功能不适合passwall来做，passwall只做好和代理相关的工作就好了。
DNS 劫持是网关更基础的通用的功能，应该是在 “网络”一级菜单下面的防火墙或者DNS设置里面，或者写一个独立的 LuciApp 放在 网络 下面。

更合适的做法应该是不去影响系统全局网络底层的设置。系统网络设置是否劫持DNS应不受任何其它服务影响。
而且大多国内op系统都集成了DNS劫持功能（防火墙自定义规则也算，不知道有没有修改系统DNS设置页或防火墙设置页来实现，或者专门做个luci app控制的），passwall再做一个，等于一个功能有了多个开关。

[sss9091]

其实我感觉这个DNS劫持的功能不适合passwall来做，passwall只做好和代理相关的工作就好了。 DNS 劫持是网关更基础的通用的功能，应该是在 “网络”一级菜单下面的防火墙或者DNS设置里面，或者写一个独立的 LuciApp 放在 网络 下面。

更合适的做法应该是不去影响系统全局网络底层的设置。系统网络设置是否劫持DNS应不受任何其它服务影响。 而且大多国内op系统都集成了DNS劫持功能（防火墙自定义规则也算，不知道有没有修改系统DNS设置页或防火墙设置页来实现，或者专门做个luci app控制的），passwall再做一个，等于一个功能有了多个开关。

“系统网络设置是否劫持DNS应不受任何其它服务影响”这是正确的，但是Passwall之前的改动影响了DNS劫持（无论是lean源码加入自定义规则，还是immortalwrt开启DNS重定向，都出现问题了），具体一点的话是因为xiaorouji去掉这两条规则导致的，不知道是出于什么目的，在这之后确实导致了DNS劫持失效。

$ipt_m -A PSW -p udp --dport 53 -j RETURN	
$ip6t_m -A PSW -p udp --dport 53 -j RETURN

[nftbty]

但是Passwall之前的改动影响了DNS劫持

一点的话是因为xiaorouji去掉这两条规则导致的，不知道是出于什么目的，在这之后确实导致了DNS劫持失效。

所以要做的其实只是解决这个问题，让passeall不影响系统设置就行了，不需要额外的什么。

说来奇怪，因为之前去掉2条规则引起的劫持失败，但是我测试确实可以成功劫持，并没有受到影响。你issue下面也有一人测试劫持没问题，估计还有其他什么因素。

[lwb1978]

其实当时我提交这个功能时也是纠结了一会，因为可以用防火墙自定义规则实现，让PW做是否合适。但是考虑到大多数使用者是不懂“技术”只会简单的使用。fw3没有带dns重定向功能，加了这个开关，普通用户也不用去找ipt命令添加到自定义规则里；而且openclash也是带有dns重定向的功能的，所以就斗胆提交了这个代码。

我的出发点是方便大多数小白用户使用，如果大佬们觉得这个提交实在画蛇添足的话就请revert它吧。😊

[sss9091]

其实当时我提交这个功能时也是纠结了一会，因为可以用防火墙自定义规则实现，让PW做是否合适。但是考虑到大多数使用者是不懂“技术”只会简单的使用。fw3没有带dns重定向功能，加了这个开关，普通用户也不用去找ipt命令添加到自定义规则里；而且openclash也是带有dns重定向的功能的，所以就斗胆提交了这个代码。

我的出发点是方便大多数小白用户使用，如果大佬们觉得这个提交实在画蛇添足的话就请revert它吧。😊

我认为加入这个功能没什么问题。
不过，我还是想确认一下，DNS劫持失效是否是因为作者删除了那两条规则导致的？有人说可以劫持，也有人说不能劫持，有点看不懂了。

[BGzEroll]

其实当时我提交这个功能时也是纠结了一会，因为可以用防火墙自定义规则实现，让PW做是否合适。但是考虑到大多数使用者是不懂“技术”只会简单的使用。fw3没有带dns重定向功能，加了这个开关，普通用户也不用去找ipt命令添加到自定义规则里；而且openclash也是带有dns重定向的功能的，所以就斗胆提交了这个代码。
我的出发点是方便大多数小白用户使用，如果大佬们觉得这个提交实在画蛇添足的话就请revert它吧。😊

我认为加入这个功能没什么问题。 不过，我还是想确认一下，DNS劫持失效是否是因为作者删除了那两条规则导致的？有人说可以劫持，也有人说不能劫持，有点看不懂了。

今天我重新在win11上测试了下，确实是缺少
$ipt_m -A PSW -p udp --dport 53 -j RETURN
$ip6t_m -A PSW -p udp --dport 53 -j RETURN

nft "add rule inet fw4 PSW_MANGLE ip protocol udp udp dport 53 counter return
nft "add rule inet fw4 PSW_MANGLE_V6 meta l4proto udp udp dport 53 counter return
这几条规则的问题。

我在我上星期编译的4.77-6上开启passwall，并开启immortalWrt-23.05的dns重定向功能如图：

关闭网卡的ipv6协议，并设置ipv4的dns为114.51.41.91，使用nslookup的结果如下：

其中，在关闭passwall后，DNS请求正常返回ip；开启passwall后，DNS请求超时，所有网页都因查询不到dns而打不开。

开启网卡的ipv6协议，并设置ipv4的dns为114.51.41.91，ipv6dns为1234::1234，使用nslookup的结果如下：

其中，在关闭passwall后，DNS请求正常返回ip；开启passwall后，DNS请求超时，所有网页都因查询不到dns而打不开。

意味着immortalWRT-23.05中的dns重定向功能正常，passwall影响了该功能。

我用scp打开nftables.sh，将
nft "add rule inet fw4 PSW_MANGLE ip protocol udp udp dport 53 counter return
nft "add rule inet fw4 PSW_MANGLE_V6 meta l4proto udp udp dport 53 counter return
写回原位后（位置如图）：

开启passwall，immortalWrt-23.05的dns重定向默认打开，nslookup返回结果如图：

dns重定向功能恢复了正常。，也就是说只需将之前被删掉的这两行代码加回去，就能和lede、immortalWrt等自带的dns重定向功能一起正常工作了。

另外该代码会在防火墙中添加如下规则：

还有就是我没将上述代码加回原位前，openwrt上的dig测试也还是正常的，这个我也不知道为什么

[BGzEroll]

另外，tcp 53端口的劫持依然是有问题的，因为

$ipt_m -A PSW -p udp --dport 53 -j RETURN
$ip6t_m -A PSW -p udp --dport 53 -j RETURN

nft "add rule inet fw4 PSW_MANGLE ip protocol udp udp dport 53 counter return
nft "add rule inet fw4 PSW_MANGLE_V6 meta l4proto udp udp dport 53 counter return

这几行代码只return了udp的53端口。

对tcp 53的测试具体如图：

set vc为设置查询使用tcp，在我添加回上述代码，并在nslookup指定了使用114.51.41.91后，dns查询依旧报错。

此外，或许tcp的53端口并不需要劫持，若udp返回tc标识让客户端重新用tcp查询时，客户端会使用udp查询时的地址；对于手动指定了某些场景走tcp 53查询的用户或许也会更友好
@nftbty @lwb1978

[sss9091]

另外，tcp 53端口的劫持依然是有问题的，因为

$ipt_m -A PSW -p udp --dport 53 -j RETURN $ip6t_m -A PSW -p udp --dport 53 -j RETURN

nft "add rule inet fw4 PSW_MANGLE ip protocol udp udp dport 53 counter return nft "add rule inet fw4 PSW_MANGLE_V6 meta l4proto udp udp dport 53 counter return

这几行代码只return了udp的53端口。

对tcp 53的测试具体如图：

set vc为设置查询使用tcp，在我添加回上述代码，并在nslookup指定了使用114.51.41.91后，dns查询依旧报错。

此外，或许tcp的53端口并不需要劫持，若udp返回tc标识让客户端重新用tcp查询时，客户端会使用udp查询时的地址；对于手动指定了某些场景走tcp 53查询的用户或许也会更友好 @nftbty @lwb1978

最新源码我试了下tcp查询似乎没有问题，不过我是iptables，有可能是nftables的规则有点问题

[dusty-97]

大佬可以尝试下加入这个功能吗 #3242 noip-as-chnip 或者 no-ipv6

[BGzEroll]

另外，tcp 53端口的劫持依然是有问题的，因为
$ipt_m -A PSW -p udp --dport 53 -j RETURN $ip6t_m -A PSW -p udp --dport 53 -j RETURN
nft "add rule inet fw4 PSW_MANGLE ip protocol udp udp dport 53 counter return nft "add rule inet fw4 PSW_MANGLE_V6 meta l4proto udp udp dport 53 counter return
这几行代码只return了udp的53端口。
对tcp 53的测试具体如图：
set vc为设置查询使用tcp，在我添加回上述代码，并在nslookup指定了使用114.51.41.91后，dns查询依旧报错。
此外，或许tcp的53端口并不需要劫持，若udp返回tc标识让客户端重新用tcp查询时，客户端会使用udp查询时的地址；对于手动指定了某些场景走tcp 53查询的用户或许也会更友好 @nftbty @lwb1978

最新源码我试了下tcp查询似乎没有问题，不过我是iptables，有可能是nftables的规则有点问题

看来应该是规则优先级的问题，imm的规则位于passwall之后，所以我这边tcp劫持会出问题。

[nftbty]

@BGzEroll 他说的最新源码应该是passwall添加了 DNS重定向 开关，在passwall里开启重定向才是正常的吧，passwall里不开，用系统自带的还是有问题的。

[BGzEroll]

@BGzEroll 他说的最新源码应该是passwall添加了 DNS重定向 开关，在passwall里开启重定向才是正常的吧，passwall里不开，用系统自带的还是有问题的。

是的，我说的就是这个意思，可能没表达清楚😂

[lwb1978]

我两台路由一台是lede一台是imm，两台都是使用passwall-smartdns版+smartdns，在没有加回那两行代码前都是可以正常劫持dns到路由的，其实我对防火墙也不熟悉，现在加个dns重定向开关也只是解一下部分用户的燃眉之急，还得大佬们分析一下那两行代码的加入和去除到底是哪个环节影响了部分用户的dns劫持，最终在根源上解决。

[sss9091]

来自AI的回复😂

iptables -t mangle -w -A PSW -p udp --dport 53 -j RETURN

这条iptables命令是用来配置防火墙规则的，它工作在Linux系统中，用于对网络数据包进行过滤或修改。下面是对这个命令各部分含义的详细解释：

• iptables: 这是Linux系统中用来管理、控制网络数据包处理规则的命令行工具。

• -t mangle: 指定了要操作的iptables表为"mangle"。Iptables有多个内置表，分别用于不同目的（如filter表用于一般的过滤操作，nat表用于网络地址转换，而mangle表则用于修改数据包的元数据，比如TTL、Mark等）。这里选择mangle表，可能是因为规则涉及对数据包的特殊标记或修改。

• -w: 这个选项在较新版本的iptables中已经被废弃，它曾经表示“等待锁”，即如果iptables.lock文件被其他进程锁定，该命令会等待锁释放后再执行。但现在建议直接使用-w之外的命令来处理并发操作，例如通过iptables-restore命令批量加载规则时自然带有锁机制。

• -A PSW: -A表示追加一条规则到指定的链（chain）末尾。在这里，"PSW"是一个用户自定义的链名，意味着该规则将被添加到名为"PSW"的链的最后。如果"PSW"链不存在于mangle表中，这将导致错误。

• -p udp: 指定此规则只应用于使用UDP协议的数据包。

• --dport 53: 表示目标端口为53的数据包。DNS（域名解析服务）默认使用的就是UDP端口53，因此这条规则针对性地作用于所有目的端口为53的UDP流量。

• -j RETURN: -j后面跟着的是动作（jump target），这里是RETURN，意味着如果数据包匹配了这条规则，就立即返回到调用当前链的那个规则之后的下一个规则继续处理。换句话说，如果数据包符合前面的条件（UDP协议且目标端口为53），则不执行"PSW"链中此规则之后的任何规则，而是直接回到调用"PSW"链的地方，继续按照那里的规则流程执行。

综上所述，这条iptables命令的作用是：在mangle表的"PSW"链的末尾添加一条规则，该规则检查所有进入的数据包，如果数据包是UDP协议且目标端口为53（即DNS查询），则不对其进行任何特殊处理（如修改标记等），而是直接返回到调用"PSW"链的点，继续按照常规流程处理这些DNS查询包。这样的规则可能用于确保DNS查询流量不受特定mangle规则的干扰或特别标记。

只能等待@xiaorouji 大佬解答了😂

[BGzEroll]

来自AI的回复😂

iptables -t mangle -w -A PSW -p udp --dport 53 -j RETURN

这条iptables命令是用来配置防火墙规则的，它工作在Linux系统中，用于对网络数据包进行过滤或修改。下面是对这个命令各部分含义的详细解释：

• iptables: 这是Linux系统中用来管理、控制网络数据包处理规则的命令行工具。
• -t mangle: 指定了要操作的iptables表为"mangle"。Iptables有多个内置表，分别用于不同目的（如filter表用于一般的过滤操作，nat表用于网络地址转换，而mangle表则用于修改数据包的元数据，比如TTL、Mark等）。这里选择mangle表，可能是因为规则涉及对数据包的特殊标记或修改。
• -w: 这个选项在较新版本的iptables中已经被废弃，它曾经表示“等待锁”，即如果iptables.lock文件被其他进程锁定，该命令会等待锁释放后再执行。但现在建议直接使用-w之外的命令来处理并发操作，例如通过iptables-restore命令批量加载规则时自然带有锁机制。
• -A PSW: -A表示追加一条规则到指定的链（chain）末尾。在这里，"PSW"是一个用户自定义的链名，意味着该规则将被添加到名为"PSW"的链的最后。如果"PSW"链不存在于mangle表中，这将导致错误。
• -p udp: 指定此规则只应用于使用UDP协议的数据包。
• --dport 53: 表示目标端口为53的数据包。DNS（域名解析服务）默认使用的就是UDP端口53，因此这条规则针对性地作用于所有目的端口为53的UDP流量。
• -j RETURN: -j后面跟着的是动作（jump target），这里是RETURN，意味着如果数据包匹配了这条规则，就立即返回到调用当前链的那个规则之后的下一个规则继续处理。换句话说，如果数据包符合前面的条件（UDP协议且目标端口为53），则不执行"PSW"链中此规则之后的任何规则，而是直接回到调用"PSW"链的地方，继续按照那里的规则流程执行。

综上所述，这条iptables命令的作用是：在mangle表的"PSW"链的末尾添加一条规则，该规则检查所有进入的数据包，如果数据包是UDP协议且目标端口为53（即DNS查询），则不对其进行任何特殊处理（如修改标记等），而是直接返回到调用"PSW"链的点，继续按照常规流程处理这些DNS查询包。这样的规则可能用于确保DNS查询流量不受特定mangle规则的干扰或特别标记。

只能等待@xiaorouji 大佬解答了😂

根据该规则的位置，如果没有该规则，设置一个不在大陆ip表内的ip作为dns服务器，不出意外的话你应该能在udp代理日志中找到这个ip...的吧？

[Leung808]

@lwb1978 我觉得有必要在日志输出一下是否启用了 DNS 劫持，很多奇怪的情况其实就是没开劫持导致的，这样方便分析问题。