楼主的软路由是裸的 Ubuntu Server ,然后从鸟哥的网站拷贝了一个脚本做防火墙。
这个防火墙脚本 (iptables.sh) 的符号链接放在了 /etc/ppp/ip-up.d 里,这样系统拨号成功后就会自动执行。
这个脚本里有一行:
iptables -t nat -I OUTPUT -d 1.1.1.1 -p tcp --dport 53 -j REDIRECT --to-ports 7001
给 tcp 的 dns 流量启用了代理。但是今天装完 tailscale 发现它居然不工作了 (组网本身倒是好的)。
说起来 tailscale 在系统中建立了若干的策略路由,在 mangle 表中也加了一些东西。经过半个多小时的排查,现在终于可以 100% 确定问题在 filter 表的 INPUT 链中。
装完 tailscale 的 INPUT 链是长这样的:
$ iptables -t filter -L -n -v
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
23508 8898K ts-input all -- * * 0.0.0.0/0 0.0.0.0/0
29947 11M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
31570 10M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
1289 133K ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0
tailscale 在最前面插了一个 ts-input 进来,是长这样的:
Chain ts-input (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo * 100.100.0.2 0.0.0.0/0
0 0 RETURN all -- !tailscale0 * 100.115.92.0/23 0.0.0.0/0
15 900 DROP all -- !tailscale0 * 100.64.0.0/10 0.0.0.0/0
736 93792 ACCEPT all -- tailscale0 * 0.0.0.0/0 0.0.0.0/0
897 70910 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:50000
而为了解决问题,只需要执行这样一行脚本:
iptables -t filter -I INPUT -i lo -p tcp --dport 7001 -j ACCEPT
修复后的 INPUT 链是长这样的:
$ iptables -t filter -L -n -v
Chain INPUT (policy DROP 1 packets, 44 bytes)
pkts bytes target prot opt in out source destination
378 23020 ACCEPT tcp -- lo * 0.0.0.0/0 0.0.0.0/0 tcp dpt:7001
30180 11M ts-input all -- * * 0.0.0.0/0 0.0.0.0/0
31973 12M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
35339 12M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
1618 165K ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0
也就是说,原本 tcp 的 dns 查询,经过 REDIRECT 规则,来到了 filter 表的 INPUT 链,但是被 ts-input 给过滤掉了 (楼主 100% 确定)。
说实话,楼主对着 ts-input 又看了两分钟,还是没发现问题在哪里。所以这个帖子就权当记录了。但是另外一方面,tailscale 各种场景下,对于主机 iptables 的调整逻辑,显然仍有优化的空间。
1
beyondstars 321 天前
iptables 属于关键系统设置,为了保护宿主机的环境,其实也可以让一些需要修改 iptables 的程序隔离起来运行(创建单独的 netns ,用 Docker container 运行,用 VM 运行)。
|