nftables 通过 ct helper 模块（如 nf_conntrack_ftp）实现 ftp 等多通道协议安全引流，核心是让 conntrack 正确识别控制与数据连接并标记为 related 状态，再配合 ct state related,established accept 规则放行，同时需绑定 helper、限制源 ip 和数据端口范围，并禁用 loose 模式防伪造。
利用 nftables 的 ct helper 模块安全引流 FTP 等多通道协议，核心是让连接跟踪（conntrack）能正确识别并关联控制连接与数据连接，避免因状态不匹配导致被动连接被拦截。FTP、SIP、TFTP、IRC 等协议在建立主会话后会动态协商额外端口或地址用于数据传输，传统无状态过滤规则无法自动放行这些“衍生连接”，必须依赖 helper 协同工作。
启用并绑定 ct helper 到对应协议端口
helper 不是默认激活的，需显式为特定端口/协议注册。FTP 分为主动模式（PORT）和被动模式（PASV），现代环境基本只用 PASV，因此重点配置 21 端口的 FTP helper：
- 加载内核模块：
modprobe nf_conntrack_ftp（RHEL/CentOS 可能还需nf_nat_ftp） - 确认 helper 已注册：
conntrack -L helper | grep ftp应显示ftp及其绑定端口（默认 21） - 若需自定义端口（如 FTP 运行在 2121），用 nft 手动绑定：
nft add rule inet filter input tcp dport 2121 ct helper set "ftp"
配合 conntrack 状态规则放行数据连接
helper 本身不放行流量，它只是让 conntrack 能把 PASV 响应中的端口信息解析出来，并将后续数据连接标记为 RELATED 状态。因此，nftables 规则中必须明确允许 RELATED 流量：
- 在 INPUT 链顶部添加：
nft add rule inet filter input ct state related,established accept - 确保该规则在 DROP/REJECT 规则之前，否则 RELATED 连接会被提前阻断
- 不要仅靠
ct state established—— 数据连接不是 established，而是 related
限制 FTP 数据连接范围，防止滥用
helper 自动放行所有 RELATED 连接，但攻击者可能伪造 PASV 响应诱导防火墙打开任意端口。需叠加主动防护：
- 限定 FTP 控制连接源 IP：
nft add rule inet filter input tcp dport 21 ip saddr { 192.168.10.0/24, 203.0.113.5 } accept - 对 PASV 数据连接加端口白名单（如限定 50000–51000）：
nft add rule inet filter input tcp dport 50000-51000 ct status dnat ct state related accept - 启用
nf_conntrack_ftp loose=0（写入/sys/module/nf_conntrack_ftp/parameters/loose）禁用宽松模式，强制只信任真实 PASV 响应中协商的端口
验证与排错要点
常见失败原因不是规则写错，而是 helper 未生效或状态匹配顺序错误：
- 用
conntrack -E实时监听连接事件，上传文件时应看到两条记录：一条是 21 端口的 control 连接，一条是 50000+ 端口的 data 连接，且后者proto-src-port显示为 RELATED - 检查
nft list ruleset中ct state related,established是否位于 DROP 规则之前 - 若使用 Docker 或 NAT 环境，确保
nf_nat_ftp模块已加载，否则 DNAT 后的 PASV 地址无法被正确重写
