两台主机之间的 IPsec：防护从哪里开始、到哪里结束

主机对上的防护始于安全关联终止之处，而这正是多数按网关思维形成的直觉会漏掉的一点。应用服务器与其数据库服务器可以直接保护彼此的会话，路径上不需要任何远程接入集中器，此时防护边界位于每台主机内部，而不在防火墙里。它带来的是选定流量的端到端覆盖。它并不能替你决定谁可以读取哪一行数据。

边界就在 SA 终止之处

RFC 4301 将传输模式的安全关联描述为主机对之间用于端到端保护的常见安排。这两台主机持有密钥，并各自决定自己的哪些数据包进入该关联。网关隧道则完全终止在别处，再通过一段额外的内部网段到达主机；即便数据包在大部分行程中都是加密的，那仍是另一条信任边界。

不过，主机到主机与传输模式并不是同义词。两台主机之间同样可以正确地建立隧道模式的安全关联，所以应先选模式，再描述端点。把两者都写进设计说明中、紧挨着对端地址的位置，因为只了解模式的人会自动假设成另一种。

SPD 决定保护，路由决定方向

路由表回答数据包往哪里去。安全策略数据库回答选定流量如何跨越防护边界，并且按方向、用各自的选择器分别作答。正是这种分工，才使得一条通往数据库的可用路由并不能证明该请求受到过保护，也使得 一次已建立的协商 并不能说明这个特定应用是否匹配到了它。在比较计数器之前先比较选择器，因为计数器只描述那些走到这一步的流量。

在 Linux 上，ip xfrm policy 会打印这些条目及其方向、优先级、选择器，以及 allow、block 或 trap 动作，而 ip xfrm state 则显示由此产生的安全关联和它们的计数器。把两者对照阅读，才能找出那种因为更宽泛的 allow 条目先被匹配、从而悄悄绕过隧道的流量。

优先级顺序属于策略的一部分，而不是实现细节。一条本应保护数据库端口的窄条目，会输给优先级更高的宽条目，而故障表现看起来就像是策略从未被查询过。

传输模式覆盖的是下一层，而不是 IP 头部

在传输模式下，ESP 头部位于 IP 头部与载荷之间，而该头部的地址字段对路径上的每台设备都保持可见。当地址不是秘密、载荷才是秘密时，这没有问题。如果你还需要隐藏内部拓扑，那它就是错误的选择，因为只有隧道模式才会把原始头部包进一个新的头部里。

两种模式都可以承载多种下一层协议，而 ESP 只会保护选择器匹配到的内容，而不是主机发出的所有内容。

选择范围比连接更窄

一条安全关联可以承载多条流量，但只承载策略所选中的那些。请记录对端身份、源与目的地址、协议，以及你打算建立的关系的服务范围，然后单独决定：不匹配的流量是否可以明文通行、必须受保护，还是在关联不可用时必须被丢弃。最后这个决定最容易带来意外，因为一条要求为错误源提供保护的规则，既能挡住入侵者，也同样能挡住你自己的管理访问。

在改动执行策略的过程中，保留一条经过批准的带外通道，并在需要它之前就测试好，而不是等到两台主机都不可达之后再试。

机器身份不等于应用权限

IPsec 认证的是已配置的对端，并保护选定的数据包。它不决定某个人可以编辑哪条数据库记录，也不会把可信的服务器身份变成对所有应用权限的授予。应用账号、角色与授权照旧留在原处，而应用层的 TLS 要求即便在网络路径已经受保护时，也仍然保有自己的目的。

验收设计时，请用来自预期源的一个操作，以及一个必须被拒绝的操作，并把所需关联无法建立时会发生什么一并纳入。普通的可达性测试只能告诉你数据包在流动；它不能告诉你这些包是在你写下的策略之下流动的。