发现群晖的 iptables filter 表的规则是下面这样的(删了不相关的 chain),按 archiwiki 来说,QUICKCONNECT_RELAY 最后一条 drop 后,后续的 rule 和 chain 都不会执行了,怎么一个群晖的 https 请求还能通过 QUICKCONNECT_RELAY 后继续执行 INPUT_FIREWALL ?
Chain INPUT (policy ACCEPT)
target prot opt source destination
QUICKCONNECT_RELAY all -- anywhere anywhere
INPUT_FIREWALL all -- anywhere anywhere
Chain INPUT_FIREWALL (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
RETURN udp -- anywhere anywhere udp spt:41641
RETURN tcp -- anywhere anywhere multiport dports DSM-https,6690
RETURN udp -- anywhere anywhere udp dpt:41641
DROP all -- anywhere anywhere
DROP all -- anywhere anywhere
Chain QUICKCONNECT_RELAY (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:6690
ACCEPT tcp -- anywhere anywhere tcp dpt:DSM-https
ACCEPT icmp -- anywhere anywhere
DROP all -- anywhere anywhere
用 iptables -nvL
看,QUICKCONNECT_RELAY 最后的 drop 规则确实有网卡限制。
Chain QUICKCONNECT_RELAY (1 references)
pkts bytes target prot opt in out source destination
43542 31M ACCEPT tcp -- tun1000 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:6690
22127 3997K ACCEPT tcp -- tun1000 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5001
424 15264 ACCEPT icmp -- tun1000 * 0.0.0.0/0 0.0.0.0/0
2952 487K DROP all -- tun1000 * 0.0.0.0/0 0.0.0.0/0
1
kkk9 265 天前
|
2
om2mo 264 天前
iptables -A QUICKCONNECT_RELAY -j DROP
iptables -A QUICKCONNECT_RELAY -j RETURN |
3
lrh3321 264 天前
iptables -S 看看完整的吧,QUICKCONNECT_RELAY 最后一条的 DROP 应该有条件的,要不然你已有的 TCP 连接应该都被它 Drop 了。
|
4
kkkbbb 264 天前
QUICKCONNECT_RELAY 的规则前面的满足后面的就不会执行了,继续判断下一个 chain 了吧
|