简介这是一份基于预共享密钥的互联网协议安全IPsec实验文档面向信息安全研究人员、网络安全专业学生以及需要为网络通信实施安全增强的工程技术人员。内容依托VMware Workstation中的两台Windows虚拟机完整记录了从验证初始连通性、创建IP安全策略、配置预共享密钥到指派策略并使用Wireshark捕获包含AH与ESP头部的数据包的全过程。通过对照实验前后主机间ICMP通信的变化读者可清晰理解IPsec在传输模式下如何保证数据的机密性与完整性同时掌握安全关联建立、密钥交换和协议分析等关键技能。资源包内含1个docx格式文档大小1.17MB已有176人浏览学习。文档以图文步骤呈现配合实验结果分析非常适合网络安全实验教学、课程设计或自学IPsec配置能帮助初学者快速上手并为进一步学习复杂加密技术奠定基础。1. 基于预共享密钥的IPsec实验双Windows虚拟机间的配置与抓包分析IPsec预共享密钥配置是学习网络安全时绕不开的一段流程在VMware Workstation里用两台Windows虚拟机把这段流程完整走一遍再配合Wireshark把AH和ESP头部抓出来看能解决“配置向导点完了但协议到底跑没跑起来”的典型困惑。实验本身不需要额外硬件或付费工具两台仅主机模式的虚拟机、一个预共享密钥、一套Windows本地安全策略向导就能完整覆盖身份认证、密钥协商、AH/ESP封装和数据加密传输的整个链路。它的核心不在把向导一步步点完而在于对比三组现象配置IPsec前ICMP能直接通、仅一端配置策略时显示“Negotiating IP Security”、两端对称配置后通信恢复且IP安全监视器里出现主模式安全关联。这个实验适合正在学IPsec或网络安全课程的在校学生也适合需要在内网里快速理解IPsec行为、又不想在真实设备上冒险的从业者。文章按环境准备、策略配置、两端对称配置、常见问题和抓包验证的顺序展开所有步骤都带具体细节和参数说明。2. 实验环境准备仅主机模式的网络隔离与ICMP连通基线2.1 为什么选择VMware的仅主机模式而非桥接或NAT实验环境包含三部分VMware Workstation、两台Windows虚拟机、Wireshark。很多人在做这个实验时想当然地选择桥接或NAT模式结果抓到一堆来自宿主机或外部网络的无关流量反而干扰了对IPsec协商过程的分析。在做类似模拟项目X的实验时我更推荐仅主机模式。仅主机模式的工作逻辑是虚拟机通过VMnet1虚拟交换机连接不经过物理网卡不访问外网。两台虚拟机接入同一个仅主机网络后彼此之间能通信但外界网络设备看不到也干扰不了它们。这个隔离特性对IPsec实验太关键了——整个协商过程只有两台虚拟机参与Wireshark抓到的每一条ICMP或协商报文都是实验流量不存在背景噪声。实际的好处是仅主机模式下如果配置出问题影响范围被限制在虚拟网络里不会把宿主机或其它物理设备拖下水。要注意的是不同版本的VMware里“仅主机模式”对应的虚拟网络编号可能不同默认网段也不一定一致。不要默认两台虚拟机的IP一定在同一个网段先打开“虚拟网络编辑器”确认VMnet1的网段再把两台虚拟机的IP手动规划到该网段里。2.2 固定IP、防火墙规则与连通性基线验证在配置IPsec策略之前先确认两台虚拟机之间能正常通信这是整个实验的基线。我一般不给虚拟机用DHCP自动获取而是手动指定同一网段的固定IP。原因很直接IPsec策略里的筛选器匹配的是IP地址如果IP变了策略就得重新验证排错时无从下手。在Windows虚拟机里打开网络适配器设置把Host_A和Host_B的IPv4地址分别设为同一网段里两个空闲地址掩码保持一致。网关可以不填因为仅主机模式没有出网需求填了也没有实际路由可用。以管理员身份打开命令行用命令确认网卡状态和IP分配。ipconfig /all输出里的IPv4地址和子网掩码是后续配置的依据。如果结果里同时出现多个网卡要找与VMnet1对应的那个。下一步做连通性测试ping 192.168.xxx.xxx -t把目标地址换成对端虚拟机的实际IP-t参数让ping持续执行方便后续在配置IPsec策略过程中实时观察状态变化。ping通是预期结果不通就先解决网络问题再往下走。常见的原因是Windows防火墙默认拦截ICMP入站需要在“高级安全Windows Defender防火墙”里放行“文件和打印机共享回显请求 - ICMPv4-In”规则或者临时关闭防火墙来排查确认网络通之后再恢复。这一步确认完成后记录两个IP地址。后面配置筛选器操作时虽然实验里选择的是“所有IP通讯”而不是指定IP对但记录IP仍然有帮助——在IP安全监视器和Wireshark里确认流量主体时靠的就是这两组地址。2.3 Wireshark在抓包前需要确认的两件事在开始配置IPsec之前先把Wireshark打开一次确认它能正确识别仅主机网卡并抓包。这样到实验后面需要抓包时不会被“找不到网卡”“权限不足”之类的问题打断节奏。选择与VMnet1对应的“VMware Virtual Ethernet Adapter”接口启动抓包后ping一下看到ICMP报文即代表抓包环境就绪。Wireshark抓包时有三个细节需要提前处理。第一必须用管理员权限启动Wireshark否则接口列表可能为空或只能看到低层接口抓不到完整数据。第二仅主机模式下数据从VMnet1虚拟交换机走宿主机上的抓包接口选VMnet1而不是虚拟机内网卡名。第三建议在Wireshark的“视图”菜单里关闭名称解析IP和MAC地址解析会让报文列表更“好看”但也可能掩盖协议细节对AH和ESP头部分析不利。这些准备做完后续抓包就不会被环境问题干扰。3. 在Host_A上配置IPsec策略MMC管理单元与预共享密钥的设置路径3.1 在MMC控制台添加两个关键管理单元IPsec策略在Windows上的配置入口是MMC控制台。在Host_A中按WinR打开“运行”对话框输入MMC并确定弹出的是空白的控制台框架。新控制台里看不到任何可操作的管理项需要通过“文件 → 添加/删除管理单元”手动添加。在可用管理单元列表里找到“IP安全策略管理”点击“添加”弹出一个“选择计算机”的对话框选择“本地计算机”确认后这个管理单元就出现在控制台左侧。之后再次打开“添加/删除管理单元”把“IP安全监视器”也加进去。IP安全监视器用到的地方在后面验证阶段——它负责显示主模式安全关联是否建立、使用了什么身份验证方法。完成添加后控制台左侧应能同时看到“IP安全策略在本地计算机”和“IP安全监视器”两个节点。这一步看起来只是把两个管理单元拖进控制台但实际影响排错效率。如果没有IP安全监视器后面策略指派后通信仍然不通时就只能靠猜无法区分是协商失败还是路由错误。3.2 创建IP安全策略并设置预共享密钥除了MMC控制台Windows还保留了“控制面板 → 管理工具 → 本地安全策略”的入口。打开后进入“本地安全设置”展开“IP安全策略在本地计算机”。这里与MMC里添加的管理单元指向的是同一份策略库用哪个入口创建策略都行但建议全程固定使用MMC控制台减少窗口切换。右击“IP安全策略在本地计算机”选择“创建IP安全策略”弹出向导。第一步给策略起名和填写描述命名建议带实验标识例如IPsec_PSK_Lab描述备注身份验证方式和配置时间。向导到“默认响应规则”时保持勾选启用。“默认响应规则”的意思是当对端发起安全协商时本机自动按规则响应这正是IPsec协商所必需的能力。接下来是“默认响应规则身份验证方法”选择“使用此字符串保护密钥交换预共享密钥”输入预设密钥。这里输入的密钥必须和Host_B完全一致大小写、空格、特殊字符都不能有差异。我建议先在记事本里录入密钥字符串例如Lab2024#Key然后在两台虚拟机上复制粘贴不要让手动输入产生肉眼看不见的差异。密钥里避免用中文和扩展字符纯ASCII字母数字加符号的兼容性最好。3.3 安全规则向导中的三个关键选项策略创建完后系统会弹出“新IP安全策略属性”窗口点击“添加”进入安全规则向导。这里有三个选项直接决定策略的生效范围需要逐一理解。第一个是“隧道终结点”选择“此规则不指定隧道”。这里的含义是使用IPsec传输模式而非隧道模式。传输模式不改变原始IP头部只保护IP数据包的载荷隧道模式则会把原始IP包完整封装进一个新的IP头部。实验里两台虚拟机直连没有需要穿越的网关指定隧道没有意义传输模式是匹配这个场景的唯一合理选择。第二个是“网络类型”选择“所有网络连接”。Windows安全策略可以按网卡类型区分规则选择所有连接意味着任何网卡进出的流量都应用规则这能简化实验复现避免因网卡类型不同而出现策略“有些时候生效有些时候不生效”的困惑。第三个是“IP筛选器列表”向导给出了预设的“所有IP通讯”直接选择。这个筛选器命中的是不区分协议类型的所有IP流量ICMP、TCP、UDP都会触发IPsec协商实验里用ping产生的ICMP流量就在覆盖范围之内。自定义筛选器的做法放到生产环境再说实验阶段用默认项最不容易出错。3.4 自定义安全措施AH用MD5、ESP用SHA1加3DES安全规则向导继续走到“筛选器操作”点击“添加”进入筛选器操作向导。常规选项选择“协商安全”表示对端支持IPsec时建立安全通道对端不支持时就拒绝通信。紧接着“与不支持IPsec的计算机通讯”一定要选择“不与不支持IPsec的计算机通讯”这一步的意思是说本机只跟能协商IPsec的主机通信做不到就丢弃数据包。这正是实验里只配置一端策略时ping不通的原因。在“IP通信安全措施”里选择“自定义”点击“设置”进入自定义安全措施设置。界面有两段配置需要处理AH和ESP。AH部分把“数据和地址不加密的完整性”的完整性算法设置为MD5ESP部分把“数据和完整性加密”的完整性算法设置为SHA1加密算法设置为3DES。这个组合不是随手选的AH负责对IP头部和载荷做完整性校验、不加密数据ESP负责加密载荷并做完整性保护两者在传输模式下并行工作。为什么不推荐更现代的AES或SHA256核心原因是教学效果。AES加密后的载荷在Wireshark里也能看到但3DES的块大小是8字节填充规则更简单填充位和密文长度观察起来更直观。MD5选项过时了但它的固定16字节输出和SHA1的20字节输出在抓包里的区别清晰适合对照学习。真实生产环境我已经不会再用MD5或3DES但实验环境保留这个组合没有安全风险反而能帮助理解头部结构。3.5 指派策略与“Negotiating IP Security”的准确含义回到“本地安全设置”窗口右击新建的IP安全策略选择“指派”确认右侧“策略已指派”栏显示“是”。这时候在Host_A上ping Host_B会出现实验里的标志性现象请求超时显示“Negotiating IP Security”。“Negotiating IP Security”不是一条通信成功的回显而是Windows网络栈对协商过程的提示。Host_A有IPsec策略命中发起安全协商但Host_B没有对应的IPsec响应能力协商卡在了第一步。这是预期的中间状态说明策略在Host_A上已经生效并开始尝试保护流量。到这一步仅Host_A配置完毕通信不通是正常的。需要继续把同样的配置在Host_B上执行一遍才能建立真正的IPsec会话。4. 在Host_B完成对称配置预共享密钥一致性与主模式安全关联4.1 Host_B的重复步骤与三个必须一致的参数在Host_B上重复Host_A的完整步骤打开MMC添加管理单元创建IP安全策略设置预共享密钥添加安全规则配置筛选器操作最后指派策略。整个过程与Host_A完全对称。三个必须逐字一致的参数需要格外留意。预共享密钥字符串是最容易出错的一项两端输入的密钥只要多一个空格协商就会失败。筛选器操作算法组合也要一致Host_A用了AH-MD5、ESP-SHA1加3DESHost_B必须原样配置算法不匹配时协商同样无法完成。还有规则里的“所有网络连接”和“所有IP通讯”选择如果Host_B改成其它选项筛选器命中的流量范围就不一致策略行为会出现奇怪的不对称。在Host_B配置时用记事本粘贴密钥是稳妥的习惯。预共享密钥在Windows策略库里不会明文显示靠记忆重输一定会出错。这个习惯也适用于生产环境预共享密钥是长期有效的静态凭证部署方式比证书简单但任何一端泄漏都意味着整个隧道体系都需要更换密钥脚本化和集中管理更合理。4.2 主模式安全关联的确认方式Host_B配置并指派策略后回到Host_A的控制台展开“IP安全监视器”找到“主模式-安全关联”。这里能看到协商成功后留下的记录。一条成功的主模式关联记录包含本地地址、远程地址、身份验证方法和密钥交换状态。验证标准有三个。身份验证方式必须显示“预共享密钥”说明密钥确认成功两端地址分别对应Host_A和Host_B的IP状态字段显示已建立而不是“协商中”或“断开”。如果这里没有任何关联说明协商根本没走到主模式阶段问题大概率出在密钥不一致或筛选器没命中。如果关联存在但状态异常说明可能出现了策略库冲突或旧缓存残留。IPsec协商分两个阶段主模式和快速模式。主模式完成身份验证并生成密钥材料快速模式在这个基础上协商具体的AH/ESP安全措施。Windows的“IP安全监视器”里看到的主模式安全关联代表双方已经用预共享密钥完成了身份确认并交换密钥材料后面抓包能看到AH和ESP头部报文就是这个协商结果的直接体现。4.3 配置完成后的ICMP往返延时变化两端配置完成后在Host_A上ping Host_B状态从“Negotiating IP Security”恢复成正常的请求回复。一个容易被忽略的观察点是往返延时的变化。配置IPsec后每个ICMP报文在发送前要经过AH和ESP处理完整性计算、加密、填充接收方还要反向校验和解密。在虚拟机环境下这部分计算开销会体现在往返延时上比裸奔ping时的数值高一到两毫秒。如果配置IPsec前后延迟几乎不变反而要怀疑IPsec是否真的生效了——也许数据包压根没走策略保护的路径。连续ping后延迟增量会逐渐回落因为首次ping时主模式协商刚完成安全关联刚建立处理路径处于冷启动状态。后续报文走相同的安全关联时系统已完成初始化延迟逐步趋于稳定。对比实验前后的延迟曲线能更直观地理解IPsec封装开销的存在。5. IPsec实验常见问题与避坑清单从协商失败到抓包抓不到5.1 两端预共享密钥不一致现象两端策略都已指派但ping始终显示“Negotiating IP Security”或“请求超时”IP安全监视器里看不到任何主模式关联。原因IPsec主模式协商的第一步就是验证身份预共享密钥以共享秘密形式参与身份载荷的哈希计算任何一位不一致都会导致身份验证失败协商直接中止。Windows不会弹出错误提示只在系统事件日志里留下协商失败记录排查起来容易被忽略。解决在两端重新输入密钥用记事本复制粘贴避免手输产生不可见字符差异。修改后重新触发一次ping观察IP安全监视器是否出现主模式关联。如果仍然没有检查两端输入的密钥里是否带了前后空格。5.2 “所有IP通讯”筛选器把无关流量也拦截了现象配置完成后不仅是ICMP不通TCP、UDP等其它通信也异常连远程桌面的会话也断开了。原因“所有IP通讯”这个筛选器命中的是所有IP协议策略要求一切流量都走安全协商。对端如果没有收到同等策略或协商失败流量会被策略直接丢弃。实验环境里两台虚拟机没有其它依赖服务这个问题不容易暴露但在真实生产环境里这个筛选器的杀伤力很大。解决实验环境保持现状即可这是教学目的。如果要把这套策略迁移到生产环境建议创建自定义IP筛选器列表只匹配源地址和目的地址协议限定为ICMP或指定目的端口避免策略范围失控把该走的业务流量全拦截掉。5.3 Wireshark抓不到AH或ESP报文现象两台虚拟机通信正常Wireshark选择VMnet1接口抓包过滤器设置esp或ah却看不到任何协议报文。原因优先检查抓包位置和权限。仅主机模式下数据从Host_A虚拟网卡到VMnet1虚拟交换机再转到Host_B虚拟网卡宿主机里选VMnet1接口能抓到。但Wireshark访问虚拟交换机接口需要管理员权限非管理员启动时接口列表不完整或抓不到数据。另一个常见干扰是IPv6仅主机网络默认启用IPv6时ping命令可能优先走IPv6地址而IPv4的IPsec策略不覆盖IPv6流量Wireshark里只会看到裸的ICMPv6报文。解决以管理员身份重启Wireshark确认选中VMnet1对应接口。在抓包过滤栏里同时加上icmpv6做对照或者干脆在命令行用ping -4强制走IPv4验证。关闭名称解析后重新抓包也能减少干扰。5.4 策略指派后的延迟生效与缓存残留现象策略指派后立即ping第一次还能通第二三次才出现“Negotiating IP Security”或者相反指派后立刻失败过几十秒又通了。原因Windows的IPsec策略加载不是完全实时。指派操作会触发策略引擎重新加载但正在进行的连接不受新策略影响只有新连接才会被新策略约束。旧的安全关联在缓存中尚未过期时也可能在策略更新后继续维持原有通信。解决每次测试前清空ARP缓存或者等待几秒后再测试。最干净的方法是把两台虚拟机重启一遍让策略引擎完全重载。生产环境不建议频繁做这样的重启操作实验环境没有这个顾虑直接重启最省心。5.5 IP安全监视器里主模式关联数为零现象两端策略均已指派且通信正常或异常但IP安全监视器里看不到任何主模式安全关联记录。原因反差来自策略选择问题。如果系统里有多条IP安全策略同时被指派策略引擎会选择与流量最匹配的一条执行选中的有可能不是实验创建的那条策略。或者实验策略被重复添加了两次规则冲突导致匹配结果异常监视器里自然看不到预期关联数据。解决在“本地安全设置”里把无关的IP安全策略全部取消指派只保留实验策略重新指派后观察监视器。仍然看不到关联的话删除策略后重新创建一次注意不要误删其它有效策略。6. 用Wireshark分析AH与ESP头部验证IPsec确实保护了数据流量6.1 设置抓包过滤条件只保留AH、ESP与ICMP流量在Wireshark的过滤栏里输入esp || ah || icmp这个过滤器把ESP、AH和ICMP三类报文并列展示。启用IPsec后一次ping会产生一系列报文主模式协商阶段的ISAKMP报文、快速模式协商报文以及后续带AH或ESP头部的ICMP报文。如果过滤结果里只剩下裸的ICMP回显请求和回显应答没有任何AH或ESP头部说明流量没有被IPsec保护需要回到策略检查上去。多次ping之后过滤结果里的报文会有两条主线ICMP请求和回显的序列以及对应的AH/ESP封装数据。对比配置前的原始ICMP报文就能看出IPsec协议在数据链路中插入的额外头部。6.2 解读AH头部SPI、序列号与完整性校验范围选中一条包含AH头部的报文在IP层下面是AH能看到安全参数索引SPI、序列号和完整性校验数据。SPI是两端在协商阶段动态分配的数值收发方向的SPI不一定相同两端根据SPI找到对应的安全关联这一机制是IPsec多隧道并行时区分流量的核心。序列号字段针对防重放攻击设计每个数据包依次递增。同一方向上如果发现序列号不连续说明中间存在数据包丢失需要排查链路问题。AH与ESP最本质的区别在保护范围AH保护整个IP包中不变字段和载荷的完整性但不加密数据。实验里AH和ESP同时启用时报文结构能直接看到完整性校验先做、加密后加的顺序这个层次关系在抓包里就是一行一行的头部排列不用猜。6.3 解读ESP头部加密载荷与填充边界ESP头部结构比AH简单包含SPI、序列号和初始化向量IV三个核心字段后面跟着加密后的载荷尾部是填充数据和下一个头部字段。3DES加密块大小是8字节原始载荷长度不足8的整数倍时需要填充这就是填充字段存在的原因。在Wireshark里没有配置解密密钥时ESP载荷显示为十六进制密文看不出ICMP数据的内容。实验里一般不建议强行解密ESP载荷专注分析头部结构就可以。需要注意的是ESP解密的密钥来自主模式协商生成的会话密钥不是配置里输入的预共享密钥本身强行用预共享密钥去解密ESP载荷是一个常见的理解误区。6.4 传输模式下IP头部与AH/ESP的层次关系传输模式下IP头部保持不变AH和ESP被插在IP头部之后、传输层协议头部之前。对比同一对ping报文在IPsec配置前后的结构差异能直接看出策略的作用配置前是IP头加ICMP数据配置后变成IP头加AH头加ESP头加加密的ICMP数据。这个可见的结构差异就是验证IPsec生效的最有力证据。配合IP安全监视器里的主模式安全关联记录两端信息对照整个实验链路就闭合了。从那以后我在配置完任何IPsec策略后第一步永远是抓包确认而不是只看通信是否恢复——因为数据包“能通”但实际没被保护的情况才是最大的坑。希望这篇经验能帮你在自己的实验或项目里少走几个弯路。本文还有配套的精品资源点击获取