跳到主要内容

9.10 快速参考与工具链

本章核心知识点回顾

  • Netfilter: 内核网络数据包处理框架，提供 Hook 机制。
  • Netfilter Hooks: 5 个关键点（PRE_ROUTING, LOCAL_IN, FORWARD, LOCAL_OUT, POST_ROUTING）。
  • Connection Tracking (conntrack): 跟踪连接状态，是 NAT 和状态防火墙的基础。
  • NAT: 网络地址转换，包括 SNAT 和 DNAT。
  • IPTables / nftables: 用户空间规则管理工具。 ==================

走到这一章的尾声，你脑子里应该塞满了宏、结构体指针和回调函数。这很正常——Netfilter 不是一个简单的「插拔插头」的机制，它是一张缠满了网线的接线板。

在这个最后的小节里，我们不引入新概念了，而是把这一章用到的「工具」摊在桌子上检查一遍。这包括两部分：我们在内核代码里调用的那些核心方法，以及我们在现实世界（用户空间）里用来调试它的工具。

内核核心方法速查​

这些是你在内核模块开发时真正会打在键盘上的符号。每一个都对应着我们在前文拆解过的某个动作。

1. Hook 的注册与注销​

这是把你的代码挂进网络栈的必经之路。

  • int nf_register_hook(struct nf_hook_ops *reg);

    • 用途：注册单个 nf_hook_ops 对象。这是最基础的用法，填好结构体，调它，你的回调函数就生效了。
    • 注意：如果返回非零，说明注册失败（比如优先级冲突或内存不足），你的模块应该处理这个错误。

  • int nf_register_hooks(struct nf_hook_ops *reg, unsigned int n);

    • 用途：批量注册。第二个参数 n 是数组长度。
    • 场景：像 nf_conntrack 这种需要在多个协议族和多个钩子点同时安插「眼线」的模块，用这个方法一口气把数组里的钩子全打进去，省得循环调用。

  • void nf_unregister_hook(struct nf_hook_ops *reg); / void nf_unregister_hooks(struct nf_hook_ops *reg, unsigned int n);

    • 用途：注销钩子。
    • 警告：别以为这步不重要。如果你的模块卸载时忘记注销钩子，内核还保留着指向你那块已释放内存的函数指针——结果就是「漂亮的」内核 Panic。

2. IPTables 表的注册​

这部分代码属于 iptables 内核框架的实现。如果你想写一个自定义的 iptables 模块或者扩展，你会用到它们。

  • struct xt_table *ipt_register_table(struct net *net, const struct xt_table *table, const struct ipt_replace *repl);

    • 用途：在内核中注册一个表（比如 filter 表或 nat 表）。这通常发生在模块初始化阶段。
    • 参数：repl 包含了初始规则和替换信息。

  • void ipt_unregister_table(struct net *net, struct xt_table *table);

    • 用途：注销表。这会释放与该表相关的所有内核资源。

3. 连接跟踪 的生命周期​

这是 Netfilter 最核心的记忆系统。

  • static inline void nf_conntrack_get(struct nf_conntrack *nfct);

    • 用途：增加连接跟踪对象的引用计数。
    • 机制：就像 C++ 的 shared_ptr 或 Rust 的 Arc。每当你把这个连接的指针存到别的地方（比如 SKB 里）时，必须调这个函数，防止对象被提前释放。

  • static inline void nf_conntrack_put(struct nf_conntrack *nfct);

    • 用途：减少引用计数。当计数归零时，nf_conntrack_destroy() 会被调用，这个连接的档案袋会被彻底销毁。

  • static inline struct nf_conn *resolve_normal_ct(...)

    • 用途：这是连接跟踪逻辑的入口。nf_conntrack_in() 调用它来决定这个包的命运。
    • 逻辑：它先调用 __nf_conntrack_find_get() 在哈希表里搜；找到了，就把现有的 nf_conn 绑定到 SKB 上；没找到，就调 init_conntrack() 创建一个新的。还记得我们说的「未确认列表」吗？新创建的条目初始状态就在那上面。

  • struct nf_conntrack_tuple_hash *init_conntrack(...)

    • 用途：分配并初始化一个新的 nf_conn 对象。
    • 细节：这里面会调用 nf_ct_find_expectation() 看看是不是 FTP 这种有「预期连接」的流量。如果是，它会直接把新连接和主连接关联起来，设置 IPS_EXPECTED_BIT。

  • static struct nf_conn *__nf_conntrack_alloc(...)

    • 用途：底层的内存分配器。它从 slab 分配器拿出一块内存给 nf_conn，并顺手把超时定时器挂上去——这个定时器一到点，就会调用 death_by_timeout() 来处决这个连接。

4. 扩展的注册​

无论是 Target（动作）还是 Match（匹配条件），或者是 Conntrack 的扩展，都遵循这一套接口。

  • Target (动作)

    • int xt_register_target(struct xt_target *target);
    • void xt_unregister_target(struct xt_target *target);
    • 用途：注册像 NF_DROP、NF_ACCEPT 或 LOG 这样的动作。你写自定义的「丢弃并报警」模块就用这个。

  • Match (匹配)

    • int xt_register_match(struct xt_match *target);
    • **void xt_unregister_match(struct xt_match *target);`
    • 用途：注册匹配条件，比如按「字符串内容匹配」或按「时间匹配」。

  • Conntrack Extensions (连接扩展)

    • int nf_ct_extend_register(struct nf_ct_ext_type *type);
    • void nf_ct_extend_unregister(struct nf_ct_ext_type *type);
    • 用途：我们在上一节看到了那些扩展（timestamp, acct, ecache）。它们就是通过这个接口告诉内核：「嘿，如果需要在连接跟踪里存点自定义数据，请按这个结构体来扩容。」

核心宏定义​

代码里除了函数，还有几个绕不过去的宏。

NF_CT_DIRECTION(hash)​

  • 定义：include/net/netfilter/nf_conntrack_tuple.h
  • 输入：一个 nf_conntrack_tuple_hash 对象（通常是从哈希表里捞出来的）。
  • 输出：方向枚举值。
    • IP_CT_DIR_ORIGINAL (0)：原始方向（发起请求的方向）。
    • IP_CT_DIR_REPLY (1)：回复方向。
  • 为什么需要它：因为 nf_conn 里的 tuplehash 数组只有两个元素（[0] 和 [1]），内核用这个宏迅速判断当前的哈希条目属于哪个方向，从而知道应该解析哪个 IP 和端口。

数据结构对照表​

写代码时，光有 API 不行，还得知道谁管谁。

表 9-2: IPv4 命名空间下的表​

这些是你加载 iptables 相关内核模块后出现在 /proc/net/ip_tables_names 里的名字。

Linux Symbol (netns_ipv4)对应的内核模块路径作用
iptable_filternet/ipv4/netfilter/iptable_filter.c默认的 filter 表，用于防火墙过滤。
iptable_manglenet/ipv4/netfilter/iptable_mangle.cmangle 表，用于修改包头（TOS 等）。
iptable_rawnet/ipv4/netfilter/iptable_raw.craw 表，用于在连接跟踪之前处理包（配置 NOTRACK）。
arptable_filternet/ipv4/netfilter/arp_tables.cARP 包过滤表。
nat_tablenet/ipv4/netfilter/iptable_nat.cNAT 表，负责地址转换。
iptable_securitynet/ipv4/netfilter/iptable_security.cSELinux 相关的安全表（需开启 CONFIG_SECURITY）。

表 9-3: IPv6 命名空间下的表​

结构和 IPv4 几乎一样，只是名字多了个 6。

Linux Symbol (netns_ipv6)对应的内核模块路径
ip6table_filternet/ipv6/netfilter/ip6table_filter.c
ip6table_manglenet/ipv6/netfilter/ip6table_mangle.c
ip6table_rawnet/ipv6/netfilter/ip6table_raw.c
ip6table_natnet/ipv6/netfilter/ip6table_nat.c
ip6table_securitynet/ipv6/netfilter/ip6table_security.c

表 9-4: Netfilter Hook 优先级​

这是决定你的钩子函数比 conntrack 先跑还是后跑的关键。数值越小，优先级越高（越先执行）。

优先级宏数值典型用途
NF_IP_PRI_FIRSTINT_MIN最先执行，用于某些必须抢占的操作。
NF_IP_PRI_CONNTRACK_DEFRAG-400分片重组。必须在连接跟踪之前把包拼起来。
NF_IP_PRI_RAW-300raw 表。用于 -j NOTRACK，在跟踪前把包截胡。
NF_IP_PRI_CONNTRACK-200连接跟踪。这是最核心的一环。
NF_IP_PRI_MANGLE-150mangle 表。修改包头。
NF_IP_PRI_NAT_DST-100DNAT。目标地址转换（通常在路由之前）。
NF_IP_PRI_FILTER0filter 表。这是 iptables 默认的过滤点。
NF_IP_PRI_SECURITY50security 表。
NF_IP_PRI_NAT_SRC100SNAT。源地址转换（通常在路由之后）。
NF_IP_PRI_CONNTRACK_HELPER300Helper。FTP/SIP 的辅助连接处理。
NF_IP_PRI_LASTINT_MAX最后执行。

定义位置：include/uapi/linux/netfilter_ipv4.h

工具与库 (Tools and Libraries)​

最后，从内核代码回到现实世界。调试 Netfilter 不能只靠 printk，你需要一套称手的工具。

conntrack-tools​

这是 Netfilter 官方提供的用户空间工具集，由两个部分组成：

  1. conntrack: 命令行工具。
    • 用途：直接查看连接跟踪表。
    • 常用命令：
      • conntrack -L: 列出当前所有连接（就像看警察局的在册嫌疑人名单）。
      • conntrack -D <ip>: 删除特定 IP 的所有连接（有时候连接僵死了，需要手动斩断）。
  2. conntrackd: 守护进程。
    • 用途：用于连接同步（比如在负载均衡的双机热备场景，两台机器的 conntrack 表得保持一致）和事件日志记录。

libnetfilter_* Libraries​

如果你想写 C 程序来操作 Netfilter，而不是直接写内核模块，你需要这些库：

  • libnetfilter_conntrack: 在用户空间操作连接跟踪表（conntrack 命令就是用这库写的）。
  • libnetfilter_queue: 将数据包从内核排队到用户空间处理（常用于复杂的 IDS/IPS）。
  • libnetfilter_log: 获取内核的日志数据包。

官方资源：详情请见 Netfilter 官网。

本章回响​

这一章我们拆解了 Linux 网络子系统的「控制中枢」——Netfilter。

还记得我们在开头留下的那个悬念吗？为什么 iptables 能在数据包飞过网卡的那一刻，从容地决定它是该留下、改头换面还是被丢弃？

答案不在 iptables 的命令里，而在内核的五个 Hook 点和那张巨大的哈希表里。Netfilter 的本质是一个协作框架：它定义了一套规则（Hook），让各种独立的模块——防火墙、NAT、连接跟踪、甚至是你自己写的模块——能在不修改主网络栈代码的情况下，介入数据包的路径。

我们看到了连接跟踪如何像「老练的侦探」一样，不仅仅看眼前的包，还能记住谁和谁在「通话」（Tuple）；我们看到了 NAT 如何在这份记忆的基础上，悄悄修改包头的地址，让内外网的对话能够进行；我们也看到了 Helper 如何像「特勤组」一样，处理 FTP 这种不仅说话还要「另开一间房」的复杂协议。

最重要的是，我们建立了一种基于优先级和扩展的思维方式。所有的模块都在同一条链上排队，优先级决定了谁先动手，扩展机制决定了谁能在档案袋里夹私货。

在下一章中，我们将离开这一层复杂的网络逻辑，进入另一个更底层的领域——Socket 缓冲区（SKB）。如果说 Netfilter 是大脑的决策逻辑，那么 SKB 就是承载信息的数据血液。理解了 SKB 的结构，你才算真正理解了 Linux 网络数据的物理形态。

练习题​

练习 1：understanding​

题目：假设你需要拦截并分析一台 Linux 服务器中所有“即将到达本机但尚未经过路由查找”的 IPv4 数据包。根据 Netfilter 钩子的工作流程，你应该在哪个钩子点注册回调函数？请说明该钩子点位于内核网络栈的哪个具体函数中。

答案与解析

答案：NF_INET_PRE_ROUTING，位于 ip_rcv() 函数中。

解析：根据 Netfilter 钩子的定义，NF_INET_PRE_ROUTING 是所有入站数据包到达的第一个钩子点。此时数据包刚刚通过网卡驱动进入内核，正在进行协议栈的初步处理，尚未进行路由查找（决定是转发给本机还是转发给其他主机）。因此，若要拦截所有入站数据包，这是最早的机会。文中明确指出该钩子位于 IPv4 的 ip_rcv() 方法中。

练习 2：application​

题目：如果管理员希望编写一个 Netfilter 内核模块，修改所有“本地生成并即将发出”的数据包的 IP 头部（例如实现透明代理或 IP 伪装），该模块应该在哪个 Netfilter 钩子点注册？对应的内核函数是什么？

答案与解析

答案：NF_INET_LOCAL_OUT，位于 __ip_local_out() 函数中。

解析：本地生成的出站数据包在通过路由查找确定出接口后，但在最终离开内核进入网卡驱动之前，会经过 NF_INET_LOCAL_OUT 钩子。这是修改本机发出数据包内容的最佳位置（如进行 SNAT 或修改端口）。文中指出该钩子位于 __ip_local_out() 方法，而在 NF_INET_POST_ROUTING（ip_output）之前处理，此时数据包已经经过了本机的路由查找。

练习 3：application​

题目：在 Linux 内核的连接跟踪机制中，数据包第一次到达时，系统会创建一个新的 nf_conn 条目。请描述这个新条目从创建到正式生效（插入哈希表）的中间状态，以及哪个函数负责将其从“中间状态”转变为“正式生效”状态。

答案与解析

答案：中间状态称为“未确认”状态，条目位于网络命名空间的 unconfirmed 列表中。由 __nf_conntrack_confirm() 函数负责将其从未确认列表移动到哈希表中。

解析：当 resolve_normal_ct() 创建新连接时，它调用 init_conntrack()，此时条目并未立即放入主哈希表，而是放入 netns_ct 的 unconfirmed 列表中。这样做是为了防止数据包随后被丢弃（例如校验和错误）导致哈希表被无效条目污染。只有当数据包成功通过后续验证（通常在 NF_INET_POST_ROUTING 或 NF_INET_LOCAL_IN 钩子中），ipv4_confirm 回调会调用 __nf_conntrack_confirm()，将条目正式插入哈希表并从未确认列表中移除。

练习 4：thinking​

题目：FTP 协议在实际数据传输前，会通过控制通道协商动态的端口进行数据连接。单纯的连接跟踪（仅匹配 IP 和端口）无法正确关联这种动态数据流。请结合本章知识，分析 Netfilter 子系统是如何利用“连接跟踪辅助模块”和“预期连接”机制来解决 FTP 数据包被错误丢弃的问题的？

答案与解析

答案：Netfilter 使用专门的 Helper（如 nf_conntrack_ftp）解析控制通道的载荷，提取出即将协商使用的端口，并为此创建一个“Expectation（预期连接）”。当后续匹配该特征的数据包到达时，内核会将其标记为 RELATED 状态，而不是视为无效的新连接。

解析：对于 FTP 等复杂协议，控制连接（如 21 端口）中的数据包载荷包含了后续数据连接的地址和端口信息。内核加载的 nf_conntrack_ftp helper 会深度检测这些数据包，读取 payload 中的 PORT 或 PASV 命令。基于此信息，内核会创建一个 nf_conntrack_expect 结构，告诉内核：“马上会有一个去往端口 X 的连接，它是属于当前控制连接的”。当那个数据包确实到达时，连接跟踪系统会发现它匹配了 Expectation，从而建立关联，并将连接状态标记为 IPS_EXPECTED（预期连接）。这样，防火墙规则（如 iptables -m conntrack --ctstate RELATED）就能识别并放行这个动态的数据包，而不是将其视为未经授权的入站连接而丢弃。

要点提炼​

Netfilter 框架通过在协议栈的关键路径上预置五个「钩子」（如 PRE_ROUTING 和 LOCAL_IN），允许内核模块在这些检查站拦截数据包。无论是实现防火墙过滤、NAT 转换，还是更高级的 IPVS 负载均衡，本质上都是调用 NF_HOOK 宏，在这些桩点上注册回调函数并返回 NF_ACCEPT 或 NF_DROP 等裁决值，从而在不修改主干代码的情况下干预流量的命运。

连接跟踪是 NAT 和状态防火墙的基石，它通过哈希表记录双向通信的元组信息，将无状态的网络栈转化为有状态的会话管理。该机制优先级极高，在数据包进入路由决策之前就已介入；它在看到新流量时创建 struct nf_conn 条目，并在后续数据包到达时快速匹配以更新状态或超时，只有在数据包最终通过所有检查后，条目才会被正式确认写入全局哈希表。

Netfilter 并非单一防火墙，而是一个可扩展的底座，支撑着 IPVS（L4 负载均衡）、IP sets（高效管理海量 IP 集合）以及 iptables 等上层功能。IPVS 利用钩子修改转发目标地址以实现流量分发，而 IP sets 则通过内核哈希表优化了匹配性能，解决了传统防火墙在处理大量地址时的效率瓶颈。

针对 FTP 等复杂协议的多通道问题，Netfilter 引入了连接跟踪助手机制。这些助手充当「协议翻译官」，监听控制通道（如 FTP 的 PORT 命令）中的特定模式，动态创建「预期连接」记录。这使得随后发起的数据连接能够通过 master 指针关联到主连接，并被防火墙识别为 RELATED 状态从而自动放行，解决了动态端口穿越防火墙的难题。

iptables 作为用户空间的前端工具，其核心作用是通过 setsockopt 将规则下发至内核，内核中的表（如 filter 表）则依据协议族和优先级注册到对应的 Netfilter 钩子上。虽然 iptables 目前是主流，但内核已经向 nftables 演进，后者通过统一的代码库和虚拟机执行引擎，解决了旧架构在协议处理上的代码重复和规则更新性能问题。

编辑此页
最后由 Charliechen114514 于 更新