iptable 的 conntrack 模块何时跟踪数据包的状态?

iptable 的 conntrack 模块何时跟踪数据包的状态?

它首先需要存储状态。在我使用的某个旧 BSD 防火墙中,我猜它的名字是 IPFW,我过去常常设置一条规则,规定“跟踪离开数据包的状态”,并将该规则放置在接口的出站方向。然后,在入站方向设置另一条规则,根据出站方向的规则创建的状态检查它们。因此,过去有 2 条规则:(1) 填充状态表,这是在出站方向,(2) 查找状态表,这是在入站方向。

但是使用 connntrack,我看到它应用于 INPUT 链,例如这条规则:

iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

这让我感到疑惑,该语句实际上在做什么?

  • 它是否说它将通过将信息放入状态表中来开始跟踪符合该规则的数据包?
  • 或者说它已经拥有状态信息,并且将根据这些信息对入站消息采取行动?(例如,如果它们属于先前接受的连接,则接受?)。但是,在这种情况下,状态表在哪里填充?它按照哪条规则填充?还是没有规则且隐式?

答案1

Netfilter 和 conntrack 的介绍

首先是关于 Netfilter 和通用网络中数据包流的强制性示意图:

Netfilter 和常规网络中的数据包流

Netfilter 是将自身插入到网络堆栈的其余部分(由“路由决策”和其他白色圆边框部分表示)的数据包过滤框架。Netfilter 为其他子系统和“客户端”提供钩子和 API。这些部分包括连接跟踪(连接跟踪器)和iptables(或者nftables)Netfilter 与连接跟踪相当模糊。你可以考虑连接跟踪作为 Netfilter 的组成部分。

在描述数据包经过的各个步骤的示意图中,你可以看到在某个点(在 raw/PREROUTING 和 mangle/PREROUTING 之间,或在 raw/OUTPUT 和 mangle/OUTPUT 之间)数据包经过连接跟踪

在此刻,连接跟踪将在其自己的查找表(保存在内核内存中的微型查找数据库)中进行搜索:

  • 如果未找到此数据包的特征(并且未在原始表中声明为 UNTRACKED),则建立新的双向 conntrack元组条目(协议,然后是特定的系列和协议信息:初始源和端口,初始目标和端口,回复源和端口,回复目标和端口(最后两个通常是相反的,除非涉及 NAT 或某些奇怪的协议,例如匹配 ICMP 的回显请求的回显回复))描述流以状态 NEW 创建。
  • 如果它与前一个条目匹配(在任何方向上),并且与此流的状态兼容,则流状态可能会改变(例如:如果之前不是这种情况,则从 NEW 更改为 ESTABLISHED)。
  • 如果由于某些特定原因,数据包无法与现有流匹配,尽管它具有其特性(例如:在重新传输已经成功启动后收到的延迟 TCP 数据包,因此超出了序列和 SACK 值的窗口),该数据包将被标记为无效。
  • 还有一些其他情况,例如 RELATED:这是关于数据包不是流本身的一部分,但与可以与其他现有(即数据库中)流相关联的新流相关的情况。两个示例是接收数据包时产生的 ICMP 错误(例如:UDP 端口不可达)或当特殊协议助手(如内核模块)时nf_conntrack_ftp,它是连接跟踪子系统,检测到数据包是与在命令流(在端口 21 上)执行的 FTP 命令 PASV/EPSV 或 PORT/EPRT 相关的单独数据流的一部分。

解决这个问题

综上所述,以下是针对您提出的两个问题的答案:

  • 在主网络命名空间中连接跟踪一旦其模块(包括可能的相关协议特定子模块)加载,就开始跟踪连接。对于非初始网络命名空间(容器……),这还需要其他某个子系统引用它(例如 OP 的iptables的 conntrack 模块或使用稍后描述的命令conntrack)。这是默认设置,并且必须专门将数据包标记为 UNTRACKED连接跟踪子系统认为此数据包不被跟踪。在 Linux 上,只有少数情况需要不跟踪,但当然,状态防火墙和状态/动态 NAT 将不再可用(静态 NAT 甚至可能需要首先使用 UNTRACKED,仍然可以完成,但不能使用iptables或者nftables可以)。为了避免连接跟踪处理一些数据包,这种iptables可以使用规则(例如:端口 80/tcp):

    iptables -t raw -A PREROUTING -p tcp --dport 80 -j CT --notrack
    iptables -t raw -A OUTPUT -p tcp --sport 80 -j CT --notrack
    
  • 当数据包穿过过滤器/INPUT并到达此规则时:

     iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    

    iptables的特定内核模块xt_conntrack查询连接跟踪子系统(由各种相关内核模块处理nf_conntrack*)并在其查找数据库中询问此数据包的状态。如果答案是RELATEDESTABLISHED数据包匹配并继续执行 ACCEPT 判决。实际上结果已经是缓存在数据包第一次查找(通常由连接跟踪),因此这是一个廉价的“查找”。因此,这是处理之前已接受的流的通用规则。这些流可以在明确提及的规则中最初被接受,-m conntrack --ctstate NEW或者只是在未提及但放置在这个通用规则(但请记住INVALID状态,在执行此操作之前通常应该将其删除)。

  • 添加一个项目符号:PREROUTING 和 OUTPUT 之间对传入数据包和传出数据包的处理非常对称(即使它们看起来不对称):连接跟踪PREROUTING 和 OUTPUT 中的接口(以及其他几个地方,考虑到NAT正在与连接跟踪,除了第一个处于 NEW 状态的数据包iptables的 nat 表)。这可能与您写的有关 IPFW 的描述略有不同。如果运行应用程序的服务器也限制传出流量,那么它很可能需要相同的通用iptables在 filter/OUTPUT 和 filter/INPUT 中都制定规则,以允许已经接受的传入流量的传出回复数据包通过。


附加信息

有专门的工具可以与连接跟踪子系统的查找表来自conntrack 工具

  • conntrack:查询、删除或更新由处理的查找表的内容连接跟踪

    一些例子。

    您可以使用以下命令列出所有跟踪的条目(如果没有附加过滤器,条目可能会很大):

    conntrack -L
    

    如果您的系统正在执行 NAT(例如,私有 LAN 前面的路由器,或正在运行虚拟机和容器),您可以使用--any-nat--src-nat--dst-nat仅显示所有 NAT、所有源 NAT(伪装)或所有目标 NAT(通常用于转发端口):

    实时监控连接跟踪事件:

    conntrack -E
    
  • conntrackd:一个守护进程,其两个主要目的是(conntrack)流量核算和统计,或者高可用性状态防火墙集群状态同步。

答案2

连接跟踪是 Netfilter 的一个独立功能,它不与 IPTables 一起配置。

在此处输入图片描述

图中,conntrackINPUT 路径有两个步骤,OUTPUT 路径有一个步骤。这些步骤将各个数据包与连接跟踪表中跟踪的现有连接关联,或在表中创建新的连接跟踪条目。

Conntrack 功能是一个 Linux 内核模块,它通常包含在内核的默认配置中。

net.netfilter.nf_conntrack可以通过调整sysctl 值来调整 Conntrack 操作。

您的第二种选择是这样的。状态信息由 Conntrack 函数记录,而 IPTables 规则只是查阅 Conntrack 表来获取信息。

相关内容