ShellCrash icon indicating copy to clipboard operation
ShellCrash copied to clipboard
verified publisher icon juewuy

[Bug] immortalwrt 23.05 默认配置，开启白名单后路由器本身无法上网，外网也连不进来

Open bsdcpp opened this issue 1 year ago • 31 comments

Verify steps

  • [X] 我已经在 Issue Tracker 中找过我要提出的问题 I have searched on the issue tracker for a related issue.
  • [X] 我已经使用公测版本测试过，问题依旧存在 I have tested using the test mod, and the issue still exists.
  • [X] 我已经仔细看过 常见问题 并无法自行解决问题

Description

全新安装的情况下也能复现，切换黑名单/关闭sc马上恢复。局域网设备好像不受影响，路由器本身国内163,baidu都无法ping通，谢谢。 shellcrash新装默认配置，只改了tproxy：nftables + tproxy + fake

bsdcpp avatar Oct 16 '24 10:10 bsdcpp

@bsdcpp 脚本什么版本，另外是否启用了本机代理，然后提供一下问题状态的8-1-4内容

juewuy avatar Oct 16 '24 10:10 juewuy

版本：1.9.1rc7 这是默认黑名单情况

table inet shellcrash {
	chain input {
		type filter hook input priority -100; policy accept;
		ip daddr 127.0.0.1 accept
		tcp dport 9999 ip saddr { 10.0.8.0/24, 192.168.1.0-192.168.3.255 } accept
		tcp dport 9999 reject
		tcp dport 7890 ip saddr { 10.0.8.0/24, 192.168.1.0-192.168.3.255 } accept
		tcp dport 7890 reject
	}

	chain prerouting_dns {
		type nat hook prerouting priority dstnat; policy accept;
		udp dport != 53 return
		tcp dport != 53 return
		meta mark 0x00001ed6 return
		meta skgid { 453, 7890 } return
		ip saddr != { 10.0.8.0/24, 192.168.1.0-192.168.3.255 } return
		ip6 saddr != { 2408:820c:8211:f179::/64, 2408:820c:8218:7c90::/60, 240e:388:8101:df00::/60, 240e:38f:8105:2038::/64, fd00::/8, fe80::/10 } reject with icmpv6 port-unreachable
		udp dport 53 redirect to :1053
		tcp dport 53 redirect to :1053
	}

	chain prerouting {
		type filter hook prerouting priority mangle; policy accept;
		tcp dport 53 return
		udp dport 53 return
		tcp dport != { 22, 80, 143, 194, 443, 465, 587, 853, 993, 995, 5222, 8080, 8443 } ip daddr != 198.18.0.0/16 return
		meta mark 0x00001ed6 return
		meta skgid 7890 return
		ip daddr { 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.168.0.0/16, 224.0.0.0/3 } return
		ip saddr != { 10.0.8.0/24, 192.168.1.0-192.168.3.255 } return
		ip6 daddr { ::/127, ::ffff:0.0.0.0/96, 64:ff9b::/96, 100::/64, 2001::/32, 2001:20::/28, 2001:db8::/32, 2002::/16, 2408:820c:8211:f179::/64, 2408:820c:8218:7c90::/60, 240e:388:8101:df00::/60, 240e:38f:8105:2038::/64, fc00::/7, fe80::/10, ff00::/8 } return
		ip6 saddr != { 2408:820c:8211:f179::/64, 2408:820c:8218:7c90::/60, 240e:388:8101:df00::/60, 240e:38f:8105:2038::/64, fd00::/8, fe80::/10 } return
		meta l4proto { tcp, udp } meta mark set 0x00001ed4 tproxy to :7893
	}
}

以下是白名单不正常的情况：

table inet shellcrash {
	chain input {
		type filter hook input priority -100; policy accept;
		ip daddr 127.0.0.1 accept
		tcp dport 9999 ip saddr { 10.0.8.0/24, 192.168.1.0-192.168.3.255 } accept
		tcp dport 9999 reject
		tcp dport 7890 ip saddr { 10.0.8.0/24, 192.168.1.0-192.168.3.255 } accept
		tcp dport 7890 reject
	}

	chain prerouting_dns {
		type nat hook prerouting priority dstnat; policy accept;
		udp dport != 53 return
		tcp dport != 53 return
		meta mark 0x00001ed6 return
		meta skgid { 453, 7890 } return
		ip saddr != { 10.0.8.0/24, 192.168.1.0-192.168.3.255 } return
		ip6 saddr != { 2408:820c:8211:f179::/64, 2408:820c:8218:7c90::/60, 240e:388:8101:df00::/60, 240e:38f:8105:2038::/64, fd00::/8, fe80::/10 } reject with icmpv6 port-unreachable
		udp dport 53 redirect to :1053
		tcp dport 53 redirect to :1053
	}

	chain prerouting {
		type filter hook prerouting priority mangle; policy accept;
		tcp dport 53 return
		udp dport 53 return
		tcp dport != { 22, 80, 143, 194, 443, 465, 587, 853, 993, 995, 5222, 8080, 8443 } ip daddr != 198.18.0.0/16 return
		meta mark 0x00001ed6 return
		meta skgid 7890 return
		ip daddr { 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.168.0.0/16, 224.0.0.0/3 } return
		ip6 daddr { ::/127, ::ffff:0.0.0.0/96, 64:ff9b::/96, 100::/64, 2001::/32, 2001:20::/28, 2001:db8::/32, 2002::/16, 2408:820c:8211:f179::/64, 2408:820c:8218:7c90::/60, 240e:388:8101:df00::/60, 240e:38f:8105:2038::/64, fc00::/7, fe80::/10, ff00::/8 } return
		ip6 saddr != { 2408:820c:8211:f179::/64, 2408:820c:8218:7c90::/60, 240e:388:8101:df00::/60, 240e:38f:8105:2038::/64, fd00::/8, fe80::/10 } return
		meta l4proto { tcp, udp } meta mark set 0x00001ed4 tproxy to :7893
	}
}

对比后，差异在 ip saddr != { 10.0.8.0/24, 192.168.1.0-192.168.3.255 } return

bsdcpp avatar Oct 16 '24 10:10 bsdcpp

@bsdcpp 看不出问题，防火墙配置是正常的，理论上也不会影响本机

juewuy avatar Oct 16 '24 10:10 juewuy

@bsdcpp 看不出问题，防火墙配置是正常的，理论上也不会影响本机

我更新了下回复，麻烦再看下。

bsdcpp avatar Oct 16 '24 10:10 bsdcpp

@bsdcpp 这里防火墙配置都是正常的，prerouting链也不会影响本机流量

juewuy avatar Oct 16 '24 10:10 juewuy

@bsdcpp 如果是在docker中测试，需要启用容器/虚拟机代理功能

juewuy avatar Oct 16 '24 10:10 juewuy

我是在真机环境下安装的，之前用iptables是没问题的，我再调试下看看，顺便学习下nft，感谢大佬解答，售后一级棒🎉

bsdcpp avatar Oct 16 '24 11:10 bsdcpp

@juewuy 通过tcpdump观察，开黑名单的时候：

22:07:26.882400 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 96
22:07:26.937646 pppoe-wan Out IP 服务端IP.50000 > 进入IP.32964: UDP, length 96
22:07:26.994227 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 96
22:07:27.561369 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 96
22:07:27.671277 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 96
22:07:28.006316 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 96
22:07:28.618137 pppoe-wan Out IP 服务端IP.50000 > 进入IP.32964: UDP, length 96

一旦开白名单，似乎有包进了lo，回环了吗，只有进没有出了？ 可以看到pppoe-wan In IP 进入IP.发了一个148长度的包，接下来下一条服务器照同样大小也发了一份，并且发给了lo，然后又回给了自己。

22:07:28.652399 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 148
22:07:28.665062 lo    In  IP 服务端IP.33441 > 服务端IP.50000: UDP, length 148
22:07:28.777946 lo    In  IP 服务端IP.50000 > 服务端IP.33441: UDP, length 92
22:07:28.778022 lo    In  IP 服务端IP.50000 > 服务端IP.33441: UDP, length 92
22:07:28.842484 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 148
22:07:28.850514 lo    In  IP 服务端IP.48605 > 服务端IP.50000: UDP, length 92
22:07:28.850914 lo    In  IP 服务端IP.50000 > 服务端IP.48605: UDP, length 92
22:07:28.938108 lo    In  IP 服务端IP.50000 > 服务端IP.48605: UDP, length 92
22:07:29.098005 lo    In  IP 服务端IP.50000 > 服务端IP.48605: UDP, length 92
22:07:29.201430 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 92

貌似之前看到过这样的问题，不知道是不是同一类问题：https://github.com/juewuy/ShellCrash/issues/783 他影响的是DNAT转发内网的，我直接影响本机😂

请教下，这个流是不是进入核心了？

root@ImmortalWrt:/etc# ip ru
0:	from all lookup local
32765:	from all fwmark 0x1ed4 lookup 100
32766:	from all lookup main
32767:	from all lookup default
root@ImmortalWrt:/etc# ip r list table 100
local default dev lo scope host
root@ImmortalWrt:/etc#

没看懂，tproxy走的是个lo接口？

bsdcpp avatar Oct 16 '24 14:10 bsdcpp

我这边是把ipv6透明代理关了就能通过ipv6访问局域网设备了

pleasant98 avatar Oct 17 '24 10:10 pleasant98

我这边是把ipv6透明代理关了就能通过ipv6访问局域网设备了

谢谢反馈，我现在只能用黑名单模式，和nft/iptables关系不大

bsdcpp avatar Oct 17 '24 10:10 bsdcpp

@juewuy 通过tcpdump观察，开黑名单的时候：

22:07:26.882400 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 96
22:07:26.937646 pppoe-wan Out IP 服务端IP.50000 > 进入IP.32964: UDP, length 96
22:07:26.994227 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 96
22:07:27.561369 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 96
22:07:27.671277 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 96
22:07:28.006316 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 96
22:07:28.618137 pppoe-wan Out IP 服务端IP.50000 > 进入IP.32964: UDP, length 96

一旦开白名单，似乎有包进了lo，回环了吗，只有进没有出了？ 可以看到pppoe-wan In IP 进入IP.发了一个148长度的包，接下来下一条服务器照同样大小也发了一份，并且发给了lo，然后又回给了自己。

22:07:28.652399 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 148
22:07:28.665062 lo    In  IP 服务端IP.33441 > 服务端IP.50000: UDP, length 148
22:07:28.777946 lo    In  IP 服务端IP.50000 > 服务端IP.33441: UDP, length 92
22:07:28.778022 lo    In  IP 服务端IP.50000 > 服务端IP.33441: UDP, length 92
22:07:28.842484 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 148
22:07:28.850514 lo    In  IP 服务端IP.48605 > 服务端IP.50000: UDP, length 92
22:07:28.850914 lo    In  IP 服务端IP.50000 > 服务端IP.48605: UDP, length 92
22:07:28.938108 lo    In  IP 服务端IP.50000 > 服务端IP.48605: UDP, length 92
22:07:29.098005 lo    In  IP 服务端IP.50000 > 服务端IP.48605: UDP, length 92
22:07:29.201430 pppoe-wan In  IP 进入IP.32964 > 服务端IP.50000: UDP, length 92

貌似之前看到过这样的问题，不知道是不是同一类问题：#783 他影响的是DNAT转发内网的，我直接影响本机😂

请教下，这个流是不是进入核心了？

root@ImmortalWrt:/etc# ip ru
0:	from all lookup local
32765:	from all fwmark 0x1ed4 lookup 100
32766:	from all lookup main
32767:	from all lookup default
root@ImmortalWrt:/etc# ip r list table 100
local default dev lo scope host
root@ImmortalWrt:/etc#

没看懂，tproxy走的是个lo接口？

lo没问题啊，有问题的是为什么流量会进到内核，不进内核不会被打上标记

juewuy avatar Oct 19 '24 06:10 juewuy

@juewuy https://github.com/juewuy/ShellCrash/commit/c98e50bf013917cc25dfbbcd3667d26986d8abd3

juewuy avatar Oct 19 '24 06:10 juewuy

感谢修复，不过我测试了下，还是挺烧脑的： 外网wg进来是10.0.8.0/24网段，只添加了白名单mac。 nftables:

  1. redir ： 都没有问题
  2. tproxy/tun ：wg无法访问内外网

iptables: Redir/tproxy/tun: wg进来可以访问正常；局域网设备内外网正常，但离奇的是无法访问clash api的控制网页

bsdcpp avatar Oct 19 '24 09:10 bsdcpp

@bsdcpp 进阶设置防火墙里可能需要添加一下自定义网段

juewuy avatar Oct 19 '24 10:10 juewuy

@bsdcpp 进阶设置防火墙里可能需要添加一下自定义网段

谢谢，里面已经有10.0.8.1/24段了，而且新的immortalwrt有点难搞： redir + nftables 模式，怎么感觉规则有重复

chain prerouting {
		type nat hook prerouting priority dstnat; policy accept;
		tcp dport 53 return
		udp dport 53 return
		tcp dport != { 22, 80, 143, 194, 443, 465, 587, 853, 993, 995, 5222, 8080, 8443 } ip daddr != 198.18.0.0/16 return
		meta mark 0x00001ed6 return
		meta skgid 7890 return
		ip daddr 0.0.0.0 return
		ether saddr != { 00:04:4b:84:20:ac,fc:7c:02:92:b4:fa } ip saddr != 10.0.8.0/24 return
		meta nfproto ipv6 return
		meta l4proto tcp redirect to :7892
		tcp dport 53 return
		udp dport 53 return
		tcp dport != { 22, 80, 143, 194, 443, 465, 587, 853, 993, 995, 5222, 8080, 8443 } ip daddr != 198.18.0.0/16 return
		meta mark 0x00001ed6 return
		meta skgid 7890 return
		ip daddr 0.0.0.0 return
		ether saddr != { 00:04:4b:84:20:ac, fc:7c:02:92:b4:fa } ip saddr != 10.0.8.0/24 return
		meta nfproto ipv6 return
		meta l4proto { tcp, udp } meta mark set 0x00001ed4 tproxy to :7893
	}

bsdcpp avatar Oct 19 '24 10:10 bsdcpp

@bsdcpp 重启设备吧，感觉有点乱

juewuy avatar Oct 19 '24 10:10 juewuy

重启immortalwrt后还是一样的情况

bsdcpp avatar Oct 19 '24 10:10 bsdcpp

@bsdcpp 好吧，明天有空我看一下

juewuy avatar Oct 19 '24 10:10 juewuy

感谢，等你方便的时候，我主要用老的21的openwrt，一直很稳，这个新系统包括nftables确实比较令人崩溃。 我先看下是哪里执行了两次，sc重启有个报错：

Error: Could not process rule: File exists
add chain inet shellcrash prerouting { type filter hook prerouting priority -150 ; }
                          ^^^^^^^^^^

bsdcpp avatar Oct 19 '24 10:10 bsdcpp

应该是这行判断导致 https://github.com/juewuy/ShellCrash/blob/1bcd7b69d5990d26f9bd1ecdcdf3ca0f4d16a6d0/scripts/start.sh#L1314 改成

[ "$redir_mod" = "Tproxy模式" ] && ( modprobe nft_tproxy >/dev/null 2>&1 || lsmod 2>/dev/null | grep -q nft_tproxy ) && {

没有重复

bsdcpp avatar Oct 19 '24 10:10 bsdcpp

@bsdcpp OK

juewuy avatar Oct 19 '24 10:10 juewuy

对比了下nft和ipt的区别，mangle表里ipt的tproxy处理规则

Chain shellcrash_mark (4 references)
target     prot opt source               destination
RETURN     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:53
RETURN     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:53
RETURN     all  --  0.0.0.0/0            0.0.0.0/0            mark match 0x1ed6
RETURN     all  --  0.0.0.0/0            192.168.1.0/24
RETURN     all  --  0.0.0.0/0            192.168.3.0/24
RETURN     all  --  0.0.0.0/0            192.168.2.0/24
RETURN     all  --  0.0.0.0/0            192.168.77.0/24
RETURN     all  --  0.0.0.0/0            10.0.8.0/24
RETURN     all  --  0.0.0.0/0            0.0.0.0
TPROXY     tcp  --  0.0.0.0/0            0.0.0.0/0            MAC cc:2d:b5:69:85:cd TPROXY redirect 0.0.0.0:7893 mark 0x1ed4/0xffffffff
TPROXY     tcp  --  0.0.0.0/0            0.0.0.0/0            MAC 00:e1:4e:b4:48:9c TPROXY redirect 0.0.0.0:7893 mark 0x1ed4/0xffffffff

nft:

chain prerouting {
		type filter hook prerouting priority mangle; policy accept;
		tcp dport 53 return
		udp dport 53 return
		tcp dport != { 22, 80, 143, 194, 443, 465, 587, 853, 993, 995, 5222, 8080, 8443 } ip daddr != 198.18.0.0/16 return
		meta mark 0x00001ed6 return
		meta skgid 7890 return
		ip daddr 0.0.0.0 return
		ether saddr != { cc:2d:b5:69:85:cd, 00:e1:4e:b4:48:9c } return
		meta nfproto ipv6 return
		meta l4proto { tcp, udp } meta mark set 0x00001ed4 tproxy to :7893
	}

相比较，nft的好似不一样，具体逻辑我不太懂：

  1. daddr { 10.0.8.0/24, 192.168.1.0-192.168.3.255, 192.168.77.0/24, 0.0.0.0/32 }的没有return
  2. 只要前面没有return的全部set mark 0x00001ed4，而ipt是匹配mac的才一一set，是不是改成类似会好点 ether saddr = { cc:2d:b5:69:85:cd, 00:e1:4e:b4:48:9c } meta mark set 0x00001ed4 tproxy to :7893

bsdcpp avatar Oct 19 '24 12:10 bsdcpp

@bsdcpp 1应该是bug，2应该没什么区别

juewuy avatar Oct 19 '24 12:10 juewuy

@bsdcpp 1应该是bug，2应该没什么区别

嗯，我就怕有什么没考虑到的通过了所有return“关卡”来到了不该打标签的地方。一些回环啥的确实烧脑，难为大佬维护，不容易

bsdcpp avatar Oct 19 '24 12:10 bsdcpp

还有个神奇的地方是，iptables模式，只有在路由器上用127.0.0.1地址可以访问localhost:9999，用内网192.168.2.1访问不了。

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    REJECT     udp  --  anywhere             anywhere             udp dpt:https reject-with icmp-port-unreachable
2    ACCEPT     tcp  --  anywhere             localhost
3    LUCKY      all  --  anywhere             anywhere
4    LUCKY      all  --  anywhere             anywhere
5    ACCEPT     tcp  --  0.0.0.0              anywhere             tcp dpt:9999
6    REJECT     tcp  --  anywhere             anywhere             tcp dpt:9999 reject-with icmp-port-unreachable
7    ACCEPT     tcp  --  0.0.0.0              anywhere             tcp dpt:7890
8    REJECT     tcp  --  anywhere             anywhere             tcp dpt:7890 reject-with icmp-port-unreachable

应该是被6 REJECT掉了

bsdcpp avatar Oct 19 '24 13:10 bsdcpp

@bsdcpp localhost就是你本机，当然只能在本机访问

juewuy avatar Oct 19 '24 13:10 juewuy

-A INPUT -s 0.0.0.0/32 -p tcp -m tcp --dport 9999 -j ACCEPT -A INPUT -p tcp -m tcp --dport 9999 -j REJECT --reject-with icmp-port-unreachable

是这样的，这个0.0.0.0/32正常吗？我去掉下面那个REJECT就内网设备可以访问了，是不是没匹配到这个0.0.0.0/32，导致走到了REJECT

bsdcpp avatar Oct 19 '24 13:10 bsdcpp

@bsdcpp 你这个设备有点问题，正常是会获取到局域网ip段的

juewuy avatar Oct 19 '24 13:10 juewuy

@bsdcpp getlanip这个函数里有具体命令你可以运行试试

juewuy avatar Oct 19 '24 13:10 juewuy

😂，是的，我看了正常的机器是：

spiderClash:/# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     6    --  0.0.0.0/0            127.0.0.1
ACCEPT     6    --  0.0.0.0/8            0.0.0.0/0            tcp dpt:9999
ACCEPT     6    --  10.0.0.0/8           0.0.0.0/0            tcp dpt:9999
ACCEPT     6    --  127.0.0.0/8          0.0.0.0/0            tcp dpt:9999
ACCEPT     6    --  100.64.0.0/10        0.0.0.0/0            tcp dpt:9999
ACCEPT     6    --  169.254.0.0/16       0.0.0.0/0            tcp dpt:9999
ACCEPT     6    --  172.16.0.0/12        0.0.0.0/0            tcp dpt:9999
ACCEPT     6    --  192.168.0.0/16       0.0.0.0/0            tcp dpt:9999
ACCEPT     6    --  224.0.0.0/4          0.0.0.0/0            tcp dpt:9999
ACCEPT     6    --  240.0.0.0/4          0.0.0.0/0            tcp dpt:9999
REJECT     6    --  0.0.0.0/0            0.0.0.0/0            tcp dpt:9999 reject-with icmp-port-unreachable

bsdcpp avatar Oct 19 '24 13:10 bsdcpp