如果我们以 Linux 命令为例ip xfrm：
ip xfrm policy add src $LOCAL dst $REMOTE dir out tmpl src $SRC dst $DST proto esp reqid $ID mode tunnel
这做什么tmpl？
更新：当然，我知道我们需要指定$SRC和$DST。但是，既然这些已经在 SA 中通过命令指定ip xfrm state，为什么我们需要在中重复它们？称其为“模板”是什么意思？对我来说，它似乎只是一个指向预先存在的 SA（ ）tmpl的指针。state
答案1
它告诉内核如何处理数据包（对于策略），或者当流量与此策略匹配时out数据包必须来自哪里（对于策略）（策略有点特殊，因为它们可能根据选择器在两个方向上都适用，请参阅infwd这个答案)。在您的示例中，策略将通过具有端点 IP 地址$SRC和$DST以及 reqid 的ESP 隧道模式 SA 发送流量$ID。
为什么我们需要在 tmpl 中重复它们？
实际查找 SA/状态。这些存储在哈希表中，地址（特别是目标地址）是哈希值的一部分。对于隧道模式 SA，与出站策略匹配的数据包的地址不一定与 SA 的地址匹配（对于传输模式，您可能不必将地址添加到模板中）。
那么称之为“模板”的含义是什么？
不确定，但可能与获取有关，也就是说，如果尚未建立匹配的 SA，则该信息将作为创建新 SA 时密钥守护进程的模板。
答案2
模板的目的是匹配策略和状态 (SA)。策略中的源/目标 IP 通常与状态中使用的不同，因此需要额外的源/目标 IP 对。
之所以称为模板，是因为它用于匹配 ID（参见人 ip-xfrm）在 state 中提供。以下是手册页中 template 的定义：
TMPL := ID [ mode MODE ] [ reqid REQID ] [ level LEVEL ]
ID := [ src ADDR ] [ dst ADDR ] [ proto XFRM-PROTO ] [ spi SPI ]
如您所见，它必须包含一个 ID，该 ID 与 xfrm 状态中的 ID 完全相同。
答案3
看看关于“SPD 的组织又称为“XFRM 规则””在净/xfrm.h：
基本对象：
- 策略规则，struct xfrm_policy （=SPD 条目）
- 转换包，struct dst_entry == struct xfrm_dst （=SA 包）
- 变压器实例，struct xfrm_state (=SA)
- 模板克隆 xfrm_state、struct xfrm_tmpl
... 策略条目具有最多 XFRM_MAX_DEPTH 个转换的列表，由模板 xfrm_tmpl 描述。每个模板都解析为一个完整的 xfrm_state（见下文），我们将转换包打包到返回给请求者的 dst_entry 中。...
有了
这个模板，我们通过 SAD 搜索具有选择器允许的适当模式/协议/算法的条目。如果未找到适当的条目，则从密钥管理器请求它。
所以：
- 每个都
tmpl定义一个 IP 数据包的转换。
每个转换都意味着 IP 数据包多一层封装。
例如：要压缩流量并通过加密隧道发送，我们将指定两个tmpl：第一个用于 IPComp，第二个用于 ESP。 tmpl充当 xfrm_state (=SA) 创建的模板。
有关 SP 和 SA 的详细定义和解释，请参阅 IPsec 标准 (RFC 4301：互联网协议的安全架构）。
简而言之你的例子
ip xfrm policy add src $LOCAL dst $REMOTE dir out tmpl src $SRC dst $DST proto esp reqid $ID mode tunnel
为符合选择器的传出流量创建 SP src $LOCAL dst $REMOTE。这$REMOTE是数据包最终目的地的 IP 地址。
tmpl src $SRC dst $DST proto esp reqid $ID mode tunnel为匹配的流量定义一个转换 — ESP 隧道：每个匹配的 IP 数据包将被包装在 ESP 数据包中并发送到$DST。这$DST是 ESP 隧道远端的 IP 地址。
当然，我知道我们需要指定 $SRC 和 $DST。但是，既然这些已经在 SA 中通过 ip xfrm state 命令指定，为什么我们需要在 tmpl 中重复它们？
严格来说，创建 SP 时 SA 不必存在。
典型情况（甚至在 IPsec 标准中也有描述）是 SP 单独存在，并且只有第一个与 SP 的选择器匹配的 IP 数据包才会触发相应 SA 的创建。
答案4
在出站处理的情况下，tmpl 用于查找用于相应接口的流量转换的 SA