nftables verdict map 组织多端口策略的规则设计

我在整理一组多端口入站策略时，最容易失控的不是端口数量，而是规则把同一类判断复制了很多遍：22、80、443 分别写一条，后来又给每条加来源地址、日志和例外，修改一次就要到处找。nftables 的 verdict map 更适合把“端口是什么”与“命中后进入哪种策略”拆开：用 inet_service 做键，用 accept、drop 或 jump 做值，再把具体服务条件放到普通链里。

把端口先变成可维护的策略入口

verdict map 不是“端口集合”的另一种写法。集合只回答是否匹配，map 还要返回一个值；当值的类型是 verdict 时，每个键直接对应一个控制动作。命名 map 可以单独增删元素，适合端口策略经常调整的服务器。

下面的关系图只表达配置中的实体边界，是原创说明图，不是本机规则运行截图。

用一张 map 分派多个服务策略链

示例把 SSH 单独放到 ssh_policy，把 Web 的 80 和 443 合并到 web_policy。这样端口分派规则保持稳定，来源地址、连接状态等变化只影响对应策略链。代码中的注释说明设计意图，示例本身不代表已经在某台机器执行。

table inet edge {
    # 端口是键，verdict 是值；80 和 443 共用 Web 策略链
    map port_policy {
        type inet_service : verdict
        elements = { 22 : jump ssh_policy, 80 : jump web_policy, 443 : jump web_policy }
    }

    # 基础链只做入口、连接状态和未命中后的默认收口
    chain input {
        type filter hook input priority filter; policy drop;
        # 已建立连接直接放行，非法状态直接丢弃
        ct state vmap { established : accept, related : accept, invalid : drop }
        # 本机回环不经过端口策略分派
        iifname "lo" accept
        # 命中的端口进入 map 返回的服务链，未命中继续看后续规则
        tcp dport vmap @port_policy
    }

    chain ssh_policy {
        # 只把管理网段放入 SSH 服务策略，其他来源返回上层
        ip saddr 192.0.2.0/24 accept
        return
    }

    chain web_policy {
        # Web 服务链可以继续叠加来源、连接状态或限速条件
        ct state new accept
        return
    }
}

这里的关键不是把所有端口写在一行，而是让 map 的值保持“一个明确的 verdict”。如果 80 和 443 的最终条件完全相同，可以共享一条链；如果某个端口需要不同来源白名单，就给它单独的策略链，不要在 map 外再复制一套长规则。

未命中与 jump/goto 的边界要先想清楚

多端口策略最危险的误解是“map 没找到端口就等于放行”。实际上，规则只在命中元素时产生对应 verdict；没有匹配的端口会继续按当前链的后续规则处理，最后才受到 base chain 的 policy 影响。上例的 policy drop 正是未明确允许端口的收口。

jump 适合把一个端口送入可复用的普通链，普通链执行到 return 后回到调用位置继续判断；goto 也会转到目标链，但返回时不回到发起跳转的这条链。策略链只是组织方式，不会替代状态跟踪、来源限制或默认 policy。

增量更新时只改元素，不重写整张表

命名 map 的维护价值在于，端口变化可以作为独立变更处理。实际执行前应准备本地控制台或回滚通道，并先确认 table、map 和链名；下面只展示维护命令的写法：

# 查看当前表，确认 map 的类型和元素
nft list table inet edge

# 临时把 8443 归入 Web 策略链，不复制整条端口规则
nft add element inet edge port_policy { 8443 : jump web_policy }

# 下线一个端口映射，避免残留旧策略
nft delete element inet edge port_policy { 22 }

# 需要恢复时重新加入原来的服务链
nft add element inet edge port_policy { 22 : jump ssh_policy }

若声明类型时写成了错误的键，例如把端口 map 声明成地址类型，后续元素和规则就会在类型层面不匹配。多字段条件也可以用连接键扩展，例如“来源地址 + 目标端口”，但那已经不是单纯的多端口分组，应明确写成 ipv4_addr . inet_service : verdict，并让规则侧使用相同的字段连接顺序。

常见问题

verdict map 能不能直接写多个动作？

一个元素对应一个简单 verdict。需要日志、计数等非终止动作时，把它们放在命中前后的普通规则中，或跳到专门的策略链，不要把 map 当成动作列表。

为什么新增端口后仍然访问不了？

先区分 map 是否命中与策略链是否放行：键类型、协议字段、链名和来源条件任一不符，最终都可能落到后续规则或 policy drop。

什么时候用连接键而不是单端口 map？

当同一端口对不同来源或目标产生不同 verdict 时，才考虑地址、端口等字段的连接键；只有按端口分组时，inet_service : verdict 更直观、维护成本也更低。