--add-tagchn-ip 选项可否设置黑名单

[puteulanus]

之前在 passwall 运行的 ChinaDNS-NG 上遇到了奇怪的污染问题（参考 xiaorouji/openwrt-passwall#3089 ），排查之后发现是国内 DNS 上游因为开了广告过滤对 chnlist 的域名返回了 0.0.0.0，导致 0.0.0.0 进入了 ipset，从而影响到了其他国内污染为 0.0.0.0 的域名的选择。

但是当时发现 ipset 里还有个 127.0.0.1，排查之后发现是百度的游帮帮加速器域名（pc.gt.baidu.com）返回的，应该是因为命中了百度所以被加进了 ipset 里，而且不能屏蔽它的解析，不然游帮帮加速会报错。

今天看到帖子 https://www.v2ex.com/t/1032883 有感，这样如果遇到国内 DNS 污染为 127.0.0.1 的域名，应该又会遇到上面那个 issue 的问题。我在文档里只找到了“接受 china 上游返回的 IP为保留地址 的解析记录”，但是似乎没有找到方法“阻止保留 IP 进入 chnroute”（除了整个关闭 --add-tagchn-ip）。

是否有必要为 --add-tagchn-ip 功能再设置一个黑名单，来阻止 0.0.0.0、127.0.0.1 这类或者特定的 IP 进入国内 IP 段的 ipset 来避免污染呢？

[zfl9]

黑名单应该不至于，我觉得可以在 add-tagxxx-ip 之前加个判断，过滤这几个特殊ip：

• 0.0.0.0/8、::
• 127.0.0.0/8、::1

应该就能避免类似问题。

[puteulanus]

也行，目前看到国内污染的好像就这两种，其它如果污染到国内 IP 的各地运营商行为不同也很难去收集

[zfl9]

一般就这两种ip。

如果确实有其他ip，不如换个思路，将这些受污染的国内域名划到一个单独的自定义group，其上游同--china-dns，但不配置ipset。

[cattyhouse]

--add-tagchn-ip 如果不设置参数, 那么会把 ip 加入 '--ipset-name4/6' 的 setname, 也就是 chnroute/chnroute6, 而这个是用于 ip test for tag:none 的, 那么就会出现一楼说的从而影响到了其他国内污染为 0.0.0.0 的域名的选择

其实解决方法很简单: 给 --add-tagchn-ip 设置一个单独的 setname, 就不会影响 ip test for tag:none, 不知道我理解的对不对?

[zfl9]

--add-tagchn-ip 如果不设置参数, 那么会把 ip 加入 '--ipset-name4/6' 的 setname, 也就是 chnroute/chnroute6, 而这个是用于 ip test for tag:none 的, 那么就会出现一楼说的从而影响到了其他国内污染为 0.0.0.0 的域名的选择

其实解决方法很简单: 给 --add-tagchn-ip 设置一个单独的 setname, 就不会影响 ip test for tag:none, 不知道我理解的对不对?

这也是一种方法

[cattyhouse]

我的操作就是: chnroute/chnroute6 固定不变, 然后新建 2个ipset: direct,direct6, 并设置其为 --add-tagchn-ip 的参数, iptables里面做和 chnroute 做一样的 RETURN 处理. 这样就各自不影响了.

[cattyhouse]

--add-tagchn-ip 如果不设置参数, 那么会把 ip 加入 '--ipset-name4/6' 的 setname, 也就是 chnroute/chnroute6, 而这个是用于 ip test for tag:none 的, 那么就会出现一楼说的从而影响到了其他国内污染为 0.0.0.0 的域名的选择
其实解决方法很简单: 给 --add-tagchn-ip 设置一个单独的 setname, 就不会影响 ip test for tag:none, 不知道我理解的对不对?

这也是一种方法

这也就是我之前建议你 ss-tproxy 那边不要吧 chnroute 弄到 sstp_white 里面的用 sstp_white 做 -4 的参数的原因了 :

https://github.com/zfl9/ss-tproxy/blob/87ec9477d94e53990d173fe0a166df17254db150/ss-tproxy#L618

https://github.com/zfl9/ss-tproxy/blob/87ec9477d94e53990d173fe0a166df17254db150/ss-tproxy#L495 主要是这个

[cattyhouse]

参考这个 issue 我当初提的建议的原因: #127 (comment)

[zfl9]

确实分开是最好的（从根本上避免该问题）。

不过有时候人就是喜欢偷懒。。。所以这里加个防御措施（127.0.0.1和0.0.0.0这两类ip就不add ip了）

[cattyhouse]

今天 127.0.0.1和0.0.0.0这两类ip就不add ip了 , 不能防御今后别的域名解析为 127.0.0.0/8 里面的任何一个ip 防不胜防.

[zfl9]

今天 127.0.0.1和0.0.0.0这两类ip就不add ip了 , 不能防御今后别的域名解析为 127.0.0.0/8 里面的任何一个ip 防不胜防.

严谨。

我修改下：

过滤以下ip：

• 127.0.0.0/8、::1
• 0.0.0.0/8、::

v4 的 loopback 地址是一个网段，127.0.0.0/8，只是习惯上大家都用 127.0.0.1。
v6 的 loopback 地址只有 ::1 一个

[cattyhouse]

这些都有可能被奇葩的域名当作解析结果, 你有的排除了...

private_ips=(
# https://en.wikipedia.org/wiki/Reserved_IP_addresses
0.0.0.0/8
10.0.0.0/8
100.64.0.0/10
127.0.0.0/8
169.254.0.0/16
172.16.0.0/12
192.0.0.0/24
192.0.2.0/24
192.88.99.0/24
192.168.0.0/16
198.18.0.0/15
198.51.100.0/24
203.0.113.0/24
224.0.0.0/4
233.252.0.0/24
240.0.0.0/4
255.255.255.255/32
)

[zfl9]

这些不排除，因为非常罕见。就算非常不幸遇到了这类情况，那就把这些“受污染域名”划到单独的group，用不会污染的dns去解析它们（要不要add ipset/nftset看情况，可配置）。

排除多了会“略微”损耗 add ip 的性能（因为每次 add 之前都要判断下），但如果只是 127、0，就非常简单，忽略不计。
这也是我不想引入“add ip”黑名单的原因之一（没必要，有其他更好的解决方法，如自定义组、或者你提到的单独集合）。

[Smallthing]

tailscale的100.64.0.0还是蛮常见

[zfl9]

最新dev已修改

黑名单是内置的，默认启用。

使用 --no-ipset-blacklist 选项可禁用此行为（也即：改回旧版行为）

[zfl9]

tailscale的100.64.0.0还是蛮常见

这个暂不考虑，如有需要，用其他方式规避吧（iptables/ipset、或者单独group）。
毕竟过滤 全0地址、loopback地址 只是出于防御目的，而且这两类ip也确实很常见。。

[puteulanus]

感谢 🙏