如果你翻开近五年的信息安全工程师真题，会发现一个绕不开的考点——IPsec协议。AH认证头到底认证什么？ESP封装安全载荷为什么既能加密又能认证？传输模式和隧道模式的新增IP头差异到底长什么样？IKE的两次协商分别干了什么？这五个问题如果回答不完整，选择题的正确率就稳不住。本文从协议族全景出发，拆解AH与ESP的封装格式差异、两种工作模式的数据包结构变化、IKE两阶段密钥协商的协议交互细节，最后用历年真题验证命题人到底在哪个位置挖坑。读完你会发现，IPsec本质上是一套围绕"认证、加密、密钥管理"三个维度构建的IP层安全解决方案，而考试考的，正是你对这三个维度边界条件的理解深度。
IPsec全称IP Security，是IETF制定的一套开放标准协议族。理解IPsec之前必须回答一个前置问题：IPv4设计之初没有内置安全机制。源IP地址可以伪造、传输内容明文可读、中间节点可以篡改数据包——这些漏洞在互联网早期不是致命缺陷，但当电子商务、远程办公、政务内网互联等场景出现后，IP层安全性就成了刚需。需要特别指出的是，IPv6在设计时将IPsec作为必选组件纳入协议栈，而IPv4的IPsec则是后来打上的"安全补丁"。这个差异不直接影响考试，但它解释了为什么在IPv4环境中配置IPsec需要额外关注NAT穿越和协议兼容性问题。
IPsec在网络层提供安全服务。这意味着它保护的粒度是整个IP数据包。HTTPS工作在应用层，只保护HTTP流量；SSH工作在应用层，只保护远程登录数据。但当你需要保护两台网关之间所有业务流量时，必须下到网络层。这就是IPsec存在的技术理由。
IPsec提供的安全服务可概括为三类：认证回答"你是谁"，确保对端不是冒充者；完整性回答"数据有没有被篡改"；机密性回答"数据有没有被偷看"。这三个维度的具体实现分别交给两个核心协议——AH和ESP。值得注意的是，AH和ESP可以单独使用，也可以组合使用——先用ESP加密再用AH认证外层——但在实际工程中通常只用ESP即满足需求，AH+ESP组合极为少见且增加开销。
IPsec协议族按功能分三块。第一块是安全协议：AH（认证头，IP协议号51）和ESP（封装安全载荷，IP协议号50）。第二块是密钥管理：IKE（互联网密钥交换），负责协商安全参数和密钥。第三块是基础概念：SA（安全关联）、SPD（安全策略数据库）和SAD（安全关联数据库）。这三块加起来构成了一套完整的IP层安全框架。软考中，AH和ESP的区别、两种工作模式的适用场景、IKE两阶段协商过程是绝对高频考点，下面逐一展开。
AH全称Authentication Header，IPv4协议号51。AH只做一件事：对IP数据包进行认证和完整性校验，不加密数据。
命题人最爱在这个点挖坑。答案是：加密有代价。加解密消耗CPU，加密后中间设备（防火墙、IDS）无法检查内容。在只需确认数据未被篡改、发送方身份真实但无需隐藏内容的场景——比如公开数据查询服务——AH就是更优选择。
AH的认证范围覆盖IP头中的不变字段，但不包括传输中会变化的字段。TTL每经过路由器减一，头部校验和随之变化，如果AH也认证它们，接收端必然对不上。RFC 4302明确列出AH计算时视为零值的字段：服务类型、标志位、分片偏移、TTL、头部校验和。命题陷阱就在这：题目问"AH对IP头是否提供完整性保护"，正确答案是"对不变字段提供"，而非笼统的"保护整个IP头"。
AH头部紧跟在IP头之后、传输层载荷之前。它包含六个字段：下一个头（指示AH后面是什么，如TCP=6）、载荷长度、保留字段（固定为0）、SPI（32位，在接收端查找对应SA）、序列号（32位，防重放）、认证数据（ICV完整性校验值，变长）。
ICV计算依赖共享认证密钥和选定的哈希算法。标准算法包括HMAC-MD5-96和HMAC-SHA1-96。虽然MD5和SHA-1已不再安全，但IPsec使用的是HMAC模式，其安全性不完全等同于底层哈希。现代部署推荐HMAC-SHA-256以上。
序列号配合接收端滑动窗口实现防重放：发送方每包序列号加一，接收方维护一个窗口（通常大小为32或64），只接受序列号在窗口范围内且未被接收过的包。序列号小于窗口左边界说明是过期重放包直接丢弃；序列号远大于窗口右边界则扩大窗口并接受，但跳跃过大会触发安全告警。需要指出，AH和ESP都支持防重放，这并非AH特有功能，但真题有时故意把防重放和某单一协议绑定来迷惑考生。
AH在IPv4中的位置：IPv4头之后、传输层载荷之前。IPv6中AH被定义为一个扩展头，位于逐跳选项头、路由头、分片头之后，但在目的选项头和上层协议头之前。这个差异不常出现在选择题中，但在网络规划设计师的案例分析中可能会要求考生判断IPv6扩展头排列顺序是否正确，记住AH在IPv6中的顺序属于加分知识。
ESP全称Encapsulating Security Payload，IP协议号50。与AH不同，ESP的核心能力是加密。认证对ESP可选——可以在"只加密不认证"和"既加密又认证"两种模式下运行，但不能"只认证不加密"。ESP设计的第一驱动力就是机密性。
ESP包结构从前到后：SPI（32位）、序列号（32位）、载荷数据（变长，加密后）、填充（0~255字节，对齐加密块大小）、填充长度（8位）、下一个头（8位）、认证数据（变长，ICV，仅启用认证时存在）。
ESP的认证覆盖ESP头部（SPI和序列号）及加密载荷，不包括外部IP头。AH则能部分覆盖IP头。这是两个协议的本质区别之一，也是选择决策的关键依据。
ESP的加密算法路径分两代。第一代是独立加密加独立认证模式：先用分组加密算法（AES-CBC最为常见，密钥长度支持128、192、256位三种规格）加密载荷，再用单独的HMAC对ESP包做认证。AES-CBC要求数据长度必须是128位的整数倍，不足时需要填充，填充遵循PKCS#7规则。这种"加密后再签名"的路径存在一个理论缺陷：攻击者可能通过观察解密后的填充是否合法来获取明文信息（Padding Oracle攻击），虽然这在IPsec的威胁模型中不是主攻向量，但设计者一直在寻求更好的方案。
第二代是AEAD算法（带关联数据的认证加密），代表是AES-GCM和AES-CCM。AEAD在一次密码学操作中同时完成加密和认证，理论上无可区分攻击面，效率也因减少了单独的HMAC计算而大幅提升。目前IETF在RFC 8221中将AES-GCM列为ESP的必选算法，AES-CBC降为可选。考生只需记住这个趋势即可，真题不会考查具体算法实现的攻击细节，但可能问"以下哪个是ESP推荐的加密算法"或"AEAD算法的特点是什么"。
ESP加密范围从载荷数据一直到下一个头字段，填充和填充长度也在加密范围内。SPI和序列号不加密——原因很简单，接收端必须先用SPI定位对应的SA，才能获取解密所需的算法和密钥。真题中确考过"ESP加密了哪些字段"，将SPI列入加密范围的选项即为错误选项。
第一，安全服务：AH提供认证和完整性，不提供机密性；ESP提供机密性，认证可选。第二，IP头保护：AH认证覆盖IP头不变字段，ESP完全不涉及。第三，NAT兼容性：AH与NAT不兼容（ICV计算含源IP），ESP隧道模式配合NAT-T（UDP封装）可与NAT共存。第三个维度是场景判断题的高频落脚点。
软考考生在这一节挫败感最重，因为"传输"和"隧道"这个命名本身就容易误导——让人以为"传输模式是直连、隧道模式是中转"。直观方向没错，但技术细节相差甚远。两种模式的本质区别不在于通信端点之间的距离远近，而在于"IPsec保护的客体是原始IP数据包本身还是另一个完整封装后的IP数据包"。换句话说，真正的分界线是：IPsec保护层的起始点和终止点是否与IP通信的实际端点重合。
传输模式下，AH或ESP头部插入在原始IP头和传输层载荷之间。原始IP头不变，只保护传输层载荷（AH同时保护IP头不变字段）。适用场景是两台主机间的端到端安全通信，保留原始IP地址。
以ESP传输模式为例，包结构：原始IP头 → ESP头(SPI+序列号) → 加密的TCP/UDP载荷+填充+填充长度+下一个头 → ESP认证数据。与原始包相比，只是在IP头和传输载荷间插入了ESP头并在末尾追加认证数据。
隧道模式在原始IP包之外新建一个外层IP头，将整个原始包作为载荷保护。原始包的每一个字节——源IP、目标IP、TTL、协议号——全部进入受保护区域，外界只看到外层IP头信息。
以ESP隧道模式为例，包结构：新IP头 → ESP头 → 加密的(原始IP头+TCP/UDP载荷)+填充+填充长度+下一个头 → ESP认证数据。与传输模式的关键差异：加密区域包含一整个原始IP头。
假设总部网段192.168.1.0/24与分公司172.16.0.0/24通过互联网互联。分公司员工（172.16.0.100）访问总部文件服务器（192.168.1.50）：原始包到达分公司VPN网关，网关将整个原始包封装进ESP隧道模式新包，外层源IP是分公司网关公网地址，目标IP是总部网关公网地址。数据包经互联网到总部网关后解密、剥除外层
本篇完！