摘要

  • RFC 3456 让 DHCPv4 穿过临时 IPsec 隧道，使租约、地址池、选项、重新配置与故障切换继续由成熟的配置系统承担，而不是复制进 IKE。
  • DHCPACK 与租入的内部地址只是配置收据，不是访问凭证：主机可以自行设定源地址，网关至 DHCP 服务器的一段也不会因前一段使用 IPsec 而自动受到保护。

两个地址属于两层事实

2003 年 1 月发布的 RFC 3456 描述了一台同时拥有外部地址与内部虚拟地址的远程主机。外部地址是 IPsec 隧道在互联网一侧的端点；内部地址则让主机在企业资源看来仿佛位于安全网关之后。两者共同完成转发，却不是同一份身份或权限证明。

纯文本、RFC Editor 记录、Datatracker 文件、文档历史、引用清单、后续引用与勘误检索能够确认规范记录，却不能说明某个用户是否被授权，也不能证明某次应用访问成功。

流程先建立 IKE 安全关联，再建立一个寿命很短、只能承载 DHCP 的隧道模式 SA。DHCPDISCOVER 或 DHCPREQUEST 经它到达网关。主机收到地址和选项后，可以用新地址作为 Quick Mode 身份的一部分，建立更广泛的 VPN SA。临时配置通道、地址租约和数据通道是三个不同状态；前一步成功不替后一步签字。

复用 DHCP，也给 IKE 划定边界

RFC 3457列出了远程接入所需的配置能力。RFC 2131以及 RFC 2132中的选项已经提供租约、地址池、续租与多类参数，RFC 3442还可交付无类别静态路由。RFC 3456 因而没有把 IKE 扩张为第二套地址管理系统。若只在 IKE 中加入少量参数，后来往往还要继续复制续租、认证与故障切换，密钥交换的敏感范围会越来越大。

虚拟接口使用硬件类型 31。客户端标识符必须在虚拟子网内唯一，并应尽量跨重启保持稳定。IANA ARP 参数注册表保留了这项分配。这些标识有助于把一次事务与租约对应起来，但“唯一”和“持久”仍只是配置属性，并不证明某个人或某项权限。

中继处出现了清楚的安全接缝

安全网关通常只是 DHCP 中继，而不是 DHCP 服务器。它可以写入 giaddr，也可以采用 RFC 3046的中继代理信息，把隧道虚拟端口编码进 Circuit ID。看到 DHCPACK 中的 yiaddr 后，网关还可能为该内部地址安装返回路由。

但 IPsec 的认证与完整性保护只覆盖远程主机到网关。网关到 DHCP 服务器的路径需要另一套保护，例如 RFC 3118的 DHCP 认证。第一段经过加密保护，不会使第二段凭空获得同样性质。

更关键的是，远程主机始终可以自行填写 IP 地址。即使 DHCP 消息经过认证，也不能据此完成访问控制。因此 RFC 3456 明确要求安全性不得依赖所分配的地址，而应由每隧道过滤器、Quick Mode 选择器或等价绑定来执行。RFC 2401的 IPsec 架构与 RFC 2409的 IKE 提供当时的策略和协商背景，却不证明任何具体部署已正确安装规则。

ACK 只是证据链的一张收据

DHCPACK 证明服务器或中继路径返回了配置；Circuit ID 说明网关准备把响应送往哪条隧道；路由项记录一次本地转发决定；SPD 或选择器记录策略绑定；实际数据包与应用响应才回答后续问题。只保存内部地址，会把这些不同权力压成一个看似方便、实则越权的符号。

Heng Lu 的现实层级方法帮助我们分别保存这些收据；运行代码优先要求查看真正安装的路由、选择器与数据包；最小初始规范解释了复用 DHCP、避免膨胀 IKE 的价值。这些是后来的编辑分析，不是对 RFC 作者私人意图的证明。

RFC 3456 没有因拒绝把租约叫作授权而削弱 DHCP。恰恰相反，它保住了 DHCP 的准确权限：配置虚拟存在。这个存在能做什么，仍必须由当前隧道身份与网关策略共同决定。

来源