当前位置: 首页 > news >正文

IPSec的封装——TK

封装模式IPsec封装模式传输模式 vs 隧道模式一句话本质IPsec封装模式的本质是“保护范围”的区别传输模式只保护IP载荷TCP/UDP等保留原IP头不变。隧道模式保护整个原始IP包再添加一个新IP头。一、设计初衷为什么要分两种模式IPsec设计于90年代面临两种主要需求端到端的主机安全两台主机之间直接通信中间网络是可信的如企业内部网络但担心链路被窃听。此时不需要隐藏源目IP只需要加密内容。→传输模式网关到网关的VPN两个安全网关之间建立隧道保护各自后面的私网主机。此时需要隐藏私网拓扑让公网只看到网关的IP地址。→隧道模式这两种需求对IP头的处理完全不同所以协议设计了两种模式。二、传输模式Transport Mode报文结构以ESP为例原始IP包 [ IP头源A目的B ] [ TCP头 ] [ 数据 ] 传输模式ESP封装后 [ IP头源A目的B ] [ ESP头 ] [ TCP头 ] [ 数据 ] [ ESP尾 ] [ ESP认证 ] ↑——————— 加密部分 ———————↑本质与精髓原IP头不动源IP和目的IP保持不变仍然是通信双方的真实地址。只加密上层协议TCP/UDP/ICMP等载荷被保护但IP头明文暴露。为什么这样设计因为端到端通信时中间路由器需要看到真实IP地址来转发报文。加密IP头会导致路由器无法路由。传输模式在“保证内容机密”的同时不破坏原有的路由结构。场景两台服务器在同一个安全域内如数据中心内部但需要加密通信内容防止同一交换机上的其他设备嗅探。或者作为更复杂隧道的一部分如GRE over IPsec中IPsec使用传输模式保护GRE包因为GRE已经提供了外层IP头。三、隧道模式Tunnel Mode报文结构以ESP为例原始IP包 [ 原IP头源私网A目的私网B ] [ TCP头 ] [ 数据 ] 隧道模式ESP封装后 [ 新IP头源网关1公网目的网关2公网 ] [ ESP头 ] [ 原IP头 ] [ TCP头 ] [ 数据 ] [ ESP尾 ] [ ESP认证 ] ↑—————————— 整个原IP包被加密 ———————————↑本质与精髓增加新IP头新IP头的源目地址是VPN网关的公网地址用于在公网上路由。加密整个原始IP包包括原始IP头。所以私网地址如192.168.x.x完全不可见。为什么这样设计因为私网地址在公网上不可路由。隧道模式把私网IP包“装进”一个公网IP包中由网关负责封装/解封装。同时隐藏了内部网络拓扑提高了安全性。场景站点到站点VPN企业总部与分支之间各自内网使用私有地址通过公网加密通信。远程访问VPN员工从家里访问公司内网客户端虚拟一个IP地址与VPN网关建立隧道。**************************************************************************************************************安全协议AH vs ESP本质区别与设计精髓AH认证头提供数据完整性和身份认证但不加密。它保护IP包的整个载荷和IP头中的部分字段防篡改。ESP封装安全载荷提供加密机密性 可选认证。它保护IP包载荷传输模式或整个IP包隧道模式核心区别AH保护数据不被篡改防改写ESP保护数据不被偷看防偷看 可选防篡改。为什么这样设计—— 两个独立的安全需求90年代设计IPsec时安全专家意识到有时只需要防篡改不需要加密。例如路由器之间交换的路由协议报文如OSPF你希望确保它没有被中间人修改但内容本身不必保密因为路由信息本来就是要公开的。加密会浪费CPU且可能触发出口管制当年密码技术受限制。但大多数场景需要同时保证机密性和完整性如VPN传输业务数据所以需要ESP。于是协议分成了两个独立协议AH专门做认证ESP专门做加密可选认证。后来ESP也加入了认证功能导致AH逐渐边缘化但AH仍有独特价值。AHAuthentication Header提供数据完整性和源认证但不加密。ESPEncapsulation Security Payload提供数据加密机密性并可选提供完整性和认证。两者都工作在IP层都需要IKE来协商密钥和参数。AH具体怎么干活1. 发送方处理以传输模式为例假设原始IP包[ IP头 ] [ TCP头 ] [ 数据 ]步骤计算完整性校验值ICV计算范围包括- IP头中的不可变字段源IP、目的IP、协议号等但不包括TTL、校验和等每跳会变的字段- 整个TCP头数据即整个上层协议数据在IP头和TCP头之间插入AH头。AH头包含- 下一个头Next Header标识TCP- 载荷长度- SPI安全参数索引- 序列号防重放- ICV前面算出的完整性校验值修改IP头中的“协议号”字段为51表示后面跟着AH。发出报文。最终报文结构[ IP头协议51 ] [ AH头 ] [ TCP头数据 ]2. 接收方处理看到IP头协议51知道后面是AH。根据SPI找到对应的SA包含密钥、算法等。用相同的算法对同样的字段范围IP头不可变部分 TCP头数据重新计算ICV。对比收到的ICV和自己算的是否一致一致 → 数据没有被篡改源IP真实。不一致 → 丢弃报文并记录异常。关键AH不修改IP头中的源/目IP也不加密任何数据。所以中间的转发设备能看到原始IP地址和TCP/UDP端口等所有信息只是不能篡改。三、ESP具体怎么干活ESP可以做两件事加密必须和认证可选。我们按完整功能加密认证讲。1. 发送方处理传输模式原始IP包[ IP头 ] [ TCP头 ] [ 数据 ]步骤在TCP头数据后面添加ESP尾ESP Trailer用于补齐加密块长度。将TCP头数据ESP尾一起加密使用协商好的加密算法如AES。在加密数据前加上ESP头包含SPI、序列号。可选对整个ESP头加密数据计算ICV附加到末尾。修改IP头中的“协议号”字段为50表示后面是ESP。发出报文。最终报文结构[ IP头协议50 ] [ ESP头 ] [ 加密的TCP头数据ESP尾 ] [ ESP认证可选]2. 接收方处理看到IP头协议50知道后面是ESP。根据SPI找到SA。如果开启了认证先验证ICV确保报文未被篡改。解密ESP头后面的数据还原出TCP头数据ESP尾。去掉ESP尾得到原始TCP头数据交给上层。**************************************************************************************************************ESP的“完整性”认证范围不包括外层IP头ESP明明能提供完整性校验为什么中间人修改IP头时ESP检测不到根本原因ESP的完整性校验ICV计算范围只覆盖ESP头 加密后的数据不包括外层IP头。而AH的完整性校验包括IP头中的不可变字段如源IP、目的IP。一、举例说明传输模式下ESP为什么保护不了IP头原始报文A → B传输模式ESP[ IP头源1.1.1.1目的2.2.2.2协议50 ] [ ESP头 ] [ 加密的TCP数据 ] [ ESP尾 ] [ ESP认证 ]ESP认证计算的范围ESP头 加密的TCP数据 ESP尾。IP头不在这个计算范围内。中间人攻击修改IP头目的IP 2.2.2.2 → 3.3.3.3中间人直接改掉IP头中的目的IP然后转发。报文到达3.3.3.3一个错误的设备它可能丢弃或错误处理。真正的B2.2.2.2根本收不到。但是ESP的ICV验证是在接收方B进行的既然B没收到就没人去验证。即使有人验证验证对象是ESP头加密数据IP头被改不影响ICV计算结果——因为IP头不在计算范围里。结果ESP完全无法阻止IP头篡改。二、为什么ESP这样设计性能与通用性IP头中的TTL、校验和等字段每经过一跳都会变化如果ESP把IP头纳入认证范围这些合法变化也会导致认证失败。所以ESP选择只保护稳定部分载荷。NAT穿透NAT设备需要修改IP头源IP、端口如果ESP认证了IP头NAT后认证必失败。因此ESP故意不保护外层IP头以便配合NAT-T。协议设计目标是否兼容NAT当前状态ESP加密可选认证牺牲IP头保护✅ 是配合NAT-T主流AH保护IP头载荷不加密❌ 否边缘化**************************************************************************************************************传输模式和隧道模式的使用区分如果隧道是加密点防火墙自己使用那么使用传输模式如果是给加密点防火墙后面的网络使用那么使用隧道模式。传输模式加密点就是通信的源和目的本身。数据包从防火墙发出目的也是防火墙或者防火墙是端到端的一环。此时不需要隐藏IP因为IP就是防火墙自己的公网地址。隧道模式加密点只是一个网关保护的是它后面的网络。源和目的不是防火墙本身而是内网的主机。此时需要把原始IP包整个加密再套上新IP头防火墙的公网地址从而隐藏内网结构。一、场景举例加密点防火墙自己使用例子两台防火墙之间直接建立IPsec VPN用于传输防火墙自己的管理流量比如SNMP、Syslog、BGP邻居等。源IP 防火墙A的公网IP1.1.1.1目的IP 防火墙B的公网IP2.2.2.2通信双方就是防火墙本身没有“后面的网络”。此时用传输模式[ IP头(1.1.1.1→2.2.2.2) ] [ ESP头 ] [ 管理数据 ]不需要加新IP头因为原IP头已经是公网可路由的且不需要隐藏。效率高少20字节开销。二、场景举例加密点给后面的网络使用例子总部防火墙公网IP 1.1.1.1与分支防火墙公网IP 2.2.2.2建立IPsec VPN保护总部内网192.168.1.0/24和分支内网192.168.2.0/24之间的流量。源IP 192.168.1.10总部主机目的IP 192.168.2.10分支主机通信双方是内网主机防火墙只是加密网关。此时必须用隧道模式[ 新IP头(1.1.1.1→2.2.2.2) ] [ ESP头 ] [ 原IP包(192.168.1.10→192.168.2.10) ]原IP包中的私网地址在公网上不可路由必须封装进新IP头。隐藏内网拓扑私网IP不暴露在公网。“加密点自己使用” → 防火墙是通信的端点→ 传输模式因为IP头就是真实的通信地址不需要额外封装。“加密点给后面的网络使用” → 防火墙是中间网关→ 隧道模式因为真实通信地址是内网主机需要被封装保护。三、一个容易混淆的补充GRE over IPsec 中的传输模式在GRE over IPsec中GRE隧道已经添加了外层IP头公网IP到公网IP此时IPsec用来保护这个GRE包。对于IPsec来说它保护的源和目的就是GRE包的外层IP头而这正是两个防火墙的公网IP —— 相当于IPsec是在“防火墙之间”保护所以可以用传输模式。这也符合老师的规则加密点防火墙自己使用GRE封装后的包源目是防火墙自身所以传输模式。AH头明明在新IP头后面内层为什么能验证新IP头报文格式是 [新IP头] [AH头] [原始IP包]AH头明明被夹在中间怎么去校验它前面的新IP头这听起来确实违反直觉。详细步骤发送方构建原始IP包私网A→私网B。在原始IP包前添加AH头此时AH头的ICV字段暂时填0。在AH头前添加新IP头源网关1公网目的网关2公网协议51。此时内存中已有完整报文[新IP头] [AH头] [原始IP包]。计算ICV按照RFC定义将以下数据拼接成一个缓冲区计算哈希新IP头中的不可变字段源IP、目的IP、协议号等跳过TTL、校验和等可变字段AH头本身包括下一个头、载荷长度、SPI、序列号等但ICV字段置0整个原始IP包将计算出的哈希值填入AH头的ICV字段。发送报文。详细步骤接收方收到完整报文[新IP头] [AH头] [原始IP包]。解析新IP头知道后面是AH协议51。根据AH头中的SPI找到SA获得算法和密钥。同样拼接以下数据新IP头中的不可变字段按相同规则提取AH头包括SPI、序列号等但使用报文中的ICV字段注意计算哈希时ICV字段应作为0处理因为原始ICV不参与计算整个原始IP包计算哈希与AH头中的ICV对比。一致则通过否则丢弃。为什么AH在NEW IP跟RAW IP之间呢无论是传输模式还是隧道模式也无论是AH还是ESP第一个字节必须是IP头。这是IP协议的铁律没有例外。正确的“最外面”对于隧道模式新IP头就是最外面第一个。AH头在新IP头后面但它通过ICV计算可以保护新IP头。这就是设计上看似反直觉但实际可行的原因。为什么传输模式下ESP也不能穿越NATESP传输模式 vs 隧道模式穿越NAT的本质区别核心结论传输模式ESP无法直接穿越NAT即使有NAT-T也困难且不推荐。隧道模式ESP配合NAT-T可以完美穿越NAT实际生产标准做法。到底是什么导致传输模式ESP不能穿越NAT而隧道模式ESP可以一、先明确三条不可动摇的“硬约束”TCP校验和依赖IP地址TCP校验和的计算包括“伪头部”伪头部中含有源IP和目的IP。这是TCP协议的规定目的是防止IP地址被篡改后上层协议不知道。NAT修改IP地址后必须同步更新TCP校验和否则接收方计算出的校验和与发送方的不一致会认为数据损坏而丢弃。NAT必须做这个更新。NAT要更新TCP校验和必须能读取TCP头包括校验和字段否则无法修改。二、传输模式ESP的因果链[1] 原始报文IP头源192.168.1.1目8.8.8.8TCP头校验和C1依赖192.168.1.1和8.8.8.8 [2] 经过传输模式ESP加密 → TCP头被加密NAT看不见 [3] 到达NAT设备NAT看到IP头源192.168.1.1 → 必须改为公网IP 1.1.1.1 [4] NAT知道改了源IP → TCP校验和必须重新计算因为伪头部变了 [5] 但是TCP头被加密 → NAT无法读取更无法修改校验和 [6] NAT无奈只改IP头不改变校验和因为改不了→ 转发 [7] 接收方解密后 → 得到IP头源1.1.1.1目8.8.8.8TCP校验和仍然是C1基于旧IP [8] 接收方计算校验和基于1.1.1.1和8.8.8.8→ 得到C2 ≠ C1 → 丢弃失败的根本原因NAT有“更新校验和”的需求但没有“访问TCP头”的能力因为加密。因果关系需求存在能力缺失 → 失败。三、隧道模式ESP的因果链[1] 原始报文内层IP头源192.168.1.1目192.168.2.1TCP头校验和C3依赖这两个私网IP [2] 经过隧道模式ESP加密 → 整个原始IP包被加密包括内层IP头和TCP头 [3] 外层加上新IP头源网关1公网1.1.1.1目网关2公网2.2.2.2 [4] 到达NAT设备NAT看到外层IP头源1.1.1.1 → 可能改为另一个公网地址例如1.1.1.100 [5] NAT思考我改了外层IP头但TCP校验和在哪里它在加密的内层里面。 [6] 关键内层TCP校验和依赖的是内层IP地址192.168.1.1和192.168.2.1与外层IP头无关。 [7] 因此NAT修改外层IP头**完全不影响内层TCP校验和的正确性**。NAT不需要修改内层校验和。 [8] NAT只需要修改外层IP头以及外层IP头校验和→ 转发 [9] 接收方解密后 → 内层TCP校验和C3依然正确 → 正常处理成功的根本原因NAT没有“更新内层TCP校验和”的需求因为外层IP修改与内层校验和无关。因果关系需求不存在 → 无需能力 → 成功。因素传输模式ESP隧道模式ESPNAT修改了哪个IP原IP头中的源IP私网→公网外层新IP头中的源IP公网→公网TCP校验和依赖哪个IP同一个IP就是被改的那个内层IP私网未被改NAT修改IP后TCP校验和会错吗会因为依赖的被改了不会因为依赖的没被改NAT需要更新TCP校验和吗必须不需要NAT能更新TCP校验和吗不能TCP头被加密不需要能力最终结果❌ 失败✅ 成功协议号问题另由NAT-T解决
http://www.zskr.cn/news/1388332.html

相关文章:

  • 全域无死角监测,无感技术筑牢矿山安全防线——黎阳之光重塑矿山安防新格局
  • PX4无人机Offboard模式实战:从Gazebo仿真到真机飞行避坑全记录
  • ASP.NET Core与Angular全栈开发自动化:代码生成器与AI代理协同工作流
  • 第四次小组会议纪要
  • 一文搞懂防孤岛和反孤岛的区别
  • 为AI工具调用添加数字签名收据:实现可审计与可信操作追踪
  • Unity Draw Call性能优化实战:从原理到真机调优
  • DeepSeek系统设计辅助:3步实现LLM集成效率提升47%(附可落地的Checklist)
  • 为Claude Desktop集成USDC钱包实现付费API自动化调用
  • 安卓7+ HTTPS抓包失效原因与4种实战解决方案
  • DS1302高精度RTC模块:嵌入式系统时间基准的硬件与软件实践
  • 荣耀出征 挂机练级与日常活动玩法心得 最新下载
  • 国内外5款用户行为分析工具盘点:国内企业为什么更应优先看 GrowingIO?
  • 刘晓艳2026年6月四六级押题卷各3套
  • 高效稳定短信验证平台怎么选?附选型避坑指南
  • 2026年无锡市本地上门黄金回收门店指南 彩金+铂金+金条+白银回收门店联系方式推荐 - 大熊猫898989
  • 计网期中考试2025回忆
  • 不只是`pacman -Syu`:深入理解Arch/Manjaro软件包管理的‘暗礁’与安全边界
  • Armv8-A架构ID_ISARx_EL1寄存器详解与应用
  • 基于ESPHome与NodeMCU的智能门铃改造:硬件连接与自动化配置详解
  • LoRaWAN GPS追踪器:硬件选型、低功耗设计与云端集成全解析
  • DIY太阳能土壤湿度传感器:低功耗设计与Gardena系统兼容方案
  • 基于Python与树莓派的家庭网络设备自动化监控方案
  • 基于RAG架构构建企业级智能问答机器人:从向量数据库到LLM的实战指南
  • Board Architect:一体化平台如何重塑嵌入式与IoT开发流程
  • Unity 2019.3.2 + ShaderForge:美术同学的第一行Shader代码(从结构体到半兰伯特)
  • 30元搞定ESP32以太网:手把手教你用LAN8720模块,避开RMII时钟和GPIO0的坑
  • ARM PMU性能监控与TLB缓存事件解析
  • 基于JTAG与OpenOCD的ARM嵌入式系统开源调试环境搭建与实战
  • 2026年台州市正规上门黄金白银回收品牌门店名录 K金+铂金+金条+银条回收门店联系方式推荐+指南 - 盛世金银回收