防火墙策略必须匹配报文路径、地址族和链顺序
防火墙在网络栈的特定位置执行报文策略。一条有用规则因此不只包含端口，还要明确地址族、挂钩、方向、连接状态和相对其他规则的位置。nftables 基础链按指定优先级接入 Netfilter 挂钩。报文实际经过的路径，决定它会遇到哪些裁决，而不是运维文档中描述的先后顺序。审阅策略必须保留这些执行上下文。 坏掉的样子 规则位于错误挂钩时，预期流量可能完全不受影响。INPUT 处理交付给当前命名空间本地的流量，FORWARD 处理经过它转发的流量，OUTPUT 面向本地产生的流量。宿主的容器转发路径，不一定就是本地输入路径。假定宿主级规则保护所有附近服务之前，应先查清实际流量经过哪个命名空间和挂钩。 地址族和方向错误也容易被掩盖。允许服务 TCP 目的端口，不同于匹配通常临时分配的客户端来源端口。只覆盖 IPv4 的策略不会自动覆盖 IPv6；IPv6 通信还依赖邻居发现等 ICMPv6 功能，丢弃所有非 TCP 报文，可能让 TCP 端口明明被允许的连接仍然失败。端口规则不能脱离链路和协议所需控制流量解释。 nftables 的 accept 不一定是所有基础链中的最终裁决。同一挂钩上更晚优先级的另一条链，仍能丢弃报文；drop 则会结束其遍历。只审阅一个表或一条链，可能看到允许计数器增长，却无法解释客户端为何失败。应查看全部适用规则集及其挂钩优先级，不能把第一条可见 accept 当成系统已经最终放行的证明。 快速验证 将脚本保存为 check-firewall.py，准备 Docker 后执行 python3 check-firewall.py。固定环境使用 nftables 1.0.6 和 Python 3.11.16。两个嵌套命名空间通过一次性 veth 同时进行 IPv4 与 IPv6 通信，容器获得实验所需 NET_ADMIN 和 SYS_ADMIN。规则不会修改宿主防火墙或现有服务，实验结束后随隔离环境移除： ...