简介：面向信息安全方向的学生与研究人员，这份基于预共享密钥的IPsec实验文档，完整记录了在VMware Workstation中利用两台Windows虚拟机配置IPsec、验证ICMP通信并抓包分析的全过程。资料以docx格式呈现，全文共1个文件，压缩包大小1.17MB，便于直接阅读或打印对照操作。内容从实验目的、环境搭建起步，逐步讲解创建IP安全策略、指派规则、设置预共享密钥、选择AH/ESP及MD5/SHA1/3DES算法等关键步骤，并配有Wireshark捕获AH与ESP头部的数据包分析，帮助读者理解IPsec工作机制与安全关联建立过程。目前已有176人学习下载，适合网络安全课程实验、自学IPsec原理或需要快速搭建安全隧道场景的读者。通过这份文档，可掌握预共享密钥认证的完整配置思路与常见排错方法，为后续复杂网络加密配置打下基础。

1. 基于预共享密钥的IPsec实验：配置完反而先 ping 不通？这不是故障

基于预共享密钥的 IPsec 实验做下来，最反直觉的一刻出现在策略指派之后：第一次 ping 直接超时，终端打印 Negotiating IP Security。别急着怀疑自己配错了，这是两台主机正在做 IKE 协商，安全关联还没建立。本文完整记录一次 Windows 虚拟机之间的 IPsec 配置：两台仅主机模式的虚拟机、一套预共享密钥、AH 与 ESP 双重保护 ICMP 流量、最后用 Wireshark 从抓包里读出协商与加密痕迹。整个过程按可复现路径写，含关键参数、GUI 向导的具体选项和四个踩坑记录。适合正在做网络安全课程实验、或者想搞清楚为什么策略配了却抓不到 AH/ESP 头部的读者。

2. IPsec协议机制与预共享密钥：为什么靠一段字符串就能互相认证

2.1 预共享密钥在对称加密体系里的定位

IPsec 要解决的不是“数据能不能加密”，而是“两台主机凭什么信任对方、用什么材料来加密”。预共享密钥（PSK）本质上是一段双方事先约定好的对称密钥材料，它不参与数据平面报文的加解密，而是参与 IKE 协商阶段的身份认证。在 Windows 的 IP 安全策略里，配置项叫做“使用此字符串保护密钥交换”，这个命名其实很准确：字符串保护的是密钥交换过程本身，而不是逐个数据包。

对照实际可选方案来看，身份认证方法通常有三类：Kerberos、证书、预共享密钥。Kerberos 依赖域环境，在两台没加域的工作组虚拟机里要先解决票据问题；证书方式最严谨，但需要搭建 CA 或有可用的企业证书服务，实验环境里反而多了一堆前置条件。预共享密钥的优势就是部署快、逻辑直观，两端只要把同一个字符串填进策略，协商时用 HMAC 类算法做一次计算，双方算出的指纹一致即可确认身份。代价是密钥更新困难：加入第三台主机时，如果沿用同一把 PSK，等于所有成员共享同一个身份，一台被攻破全部失效；如果为每对主机单独配密钥，维护量又上来了。所以它适合封闭的、节点数少的场景，模拟项目里这种两机环境几乎是理想选择。

密钥本身的类型也容易踩坑。预共享密钥不是口令，没有“至少几位、必须含特殊字符”的强制要求，但 Windows 的向导界面要求非空字符串，且两端必须逐字符一致。这里不建议填入弱密钥比如 123，抓包阶段虽然看不到 IKE 密钥交换的明文，但离线字典攻击并不需要抓到完整的预共享密钥，只要拿到协商过程中的载荷就能暴力试探。做实验用 lab-key-2024 这类中等强度字符串就够了。

2.2 AH 与 ESP 的取舍：实验里为什么两组算法都要配

实验配置里同时启用了 AH 和 ESP，各自算法还不一样：AH 的完整性算法用 MD5，ESP 的完整性算法用 SHA1、加密算法用 3DES。初看有点冗余，搞清楚两者分工就明白了。

AH（Authentication Header）负责完整性校验和来源认证，但不加密载荷。它会保护 IP 头中不变字段、AH 头自身和上层数据，任何被篡改的字段都会导致对端校验失败。ESP（Encapsulating Security Payload）则既做加密又做完整性保护，实验里把载荷用 3DES 加密，再用 SHA1 对 ESP 报文算摘要，保证数据既不可读也不可改。两者叠在一起时，抓包看到的效果是：外层有 AH 头部做认证，载荷部分被 ESP 封装加密，ICMP 的 type、code 和 payload 全部变成密文。

在 Windows 的安全措施设置里，“数据和地址不加密的完整性（AH）”与“数据和完整性加密（ESP）”两个复选框可以独立勾选，实验文档选了同时启用，目的就是让你在 Wireshark 里一次性看到两种头部。如果只勾 ESP，抓到的全是 ESP 流量，看不到 AH 头的格式；只勾 AH，载荷是明文，机密性验证缺位。这也解释了自定义安全措施为什么把 AH 和 ESP 都配上。

从密码学应用角度看，MD5 在现代安全实践中已经被认为强度不足，但这不影响它做教学演示——它能直观展示“完整性算法变化后抓包特征随之变化”。如果是真实生产环境，我不会选 MD5，AH 一致性应优先 SHA256，ESP 加密优先 AES-GCM，这属于“能看到边界”的部分。

2.3 IKE 协商两阶段：主模式与快速模式在做什么

预共享密钥不直接在数据包中出现，协商由 IKE 协议完成。IKE 协商分成两个阶段：第一阶段建立主模式安全关联，第二阶段建立快速模式安全关联。主模式在 Windows 的“IP安全监视器”里对应“主模式-安全关联”，是协商双方身份与密钥材料的阶段；快速模式才是为具体数据流建立 IPSec SA 的阶段，决定哪些流量用什么协议和算法保护。

主模式协商时，预共享密钥作为认证材料参与交换。双方先交换 SA 提议，包括加密算法、完整性算法、DH 组等，协商一致后各自生成会话密钥。这个过程中预共享密钥不直接发送，而是用于生成认证载荷，对端用同样字符串计算，一致则身份成立。抓包时你会看到 UDP 500 端口上多个 ISAKMP 报文两两成对出现，那就是主模式与快速模式的协商流量。建立 SAFE 之后，数据平面才开始走带 AH/ESP 头的包，配置完第一次 ping 超时，原因就在这里——报文到达时 IKE 还没来得及建 SA，主机就会返回 Negotiating IP Security 的中间状态。

3. 虚拟机环境准备：仅主机模式与网络基线验证

3.1 三种网络模式里为什么只能选仅主机

VMware 通常提供桥接、NAT、仅主机三种模式。桥接模式下虚拟机直接接入物理局域网，会和宿主机、路由器、宿舍里其他人的设备混在同一个广播域里，实验流量被无关 ARP 和广播干扰，抓包基线脏得一塌糊涂；NAT 模式通过虚拟 NAT 网关转发，两台虚拟机都挂在同一个 VMnet8 网段，通信路径经过虚拟网关，IPsec 协商过程里多了一跳 NAT 设备，而 IPsec 对 NAT 穿越本来就敏感，实验里会引入不必要的变量。

仅主机模式把虚拟机和宿主机用一个隔离的虚拟网段串起来，外部流量完全进不来，两台虚拟机之间的通信路径就是一条干净的虚拟二层链路。这个实验本质是验证协议行为，不是验证网关转发，隔离环境能让 Wireshark 抓到最纯粹的 IPsec 协商报文。另一个好处是 IP 地址可控：在仅主机网段里手动指定两个静态地址，策略的“所有 IP 通讯”生效范围就完全确定，不会出现 NAT 模式里地址漂移导致策略匹配不上的情况。

环境准备阶段我习惯先做两件事：给虚拟机固定 IP，再确保两机能通。Host_A 设置成 192.168.153.2/24，Host_B 设置成 192.168.153.3/24，网关留空，DNS 无所谓。这个地址段对应的是 VMware 虚拟网卡默认网段，如果机器上关闭了 DHCP 服务或改过网段，以真实 VMnet1 的网段为准。同时建议在配置 IPsec 策略之前先给两台虚拟机做快照，后续配置翻车可直接恢复，不用重装系统。

3.2 建立通信基线：配置前的最后一次互通确认

ipconfig /all 192.168.153.2 192.168.153.3 ping -n 4 192.168.153.3

我在两台虚拟机上把主机名分别改成 Host_A 与 Host_B，方便虚拟机切换窗口时区分角色。先用 ipconfig /all 确认网卡绑定地址确实生效，再在 Host_A 上发四个 ICMP 请求到 Host_B。这里 -n 4 是指定发包数量，避免默认无限 ping 造成后续抓包文件里全是 ICMP；确认 4 个请求全部收到回复，说明二层链路通、IP 栈正常、防火墙没拦截。这一步是整场实验的基线，后面所有“通不通”的判断都拿它做参照。

如果这一步就 ping 不通，先不要碰 IPsec 策略，按顺序检查虚拟网卡是否都处于仅主机模式、两台虚拟机是否在同一网段、Windows 防火墙是否拦截 ICMP。特别要注意 Windows 的公用网络配置文件默认开启防火墙，ICMP echo request 大概率会被拦，一个常见做法是临时在“高级安全 Windows 防火墙”里放行“文件和打印机共享(回显请求 - ICMPv4-In)”规则，或者实验期间临时关闭域/专用网络的防火墙入站规则。把基线打通后再往下走，否则后续配置完成后 ping 不通，很难区分是 IPsec 策略问题还是基础网络问题。

配置完网络以后，再回虚拟机设置里确认两台机器的网络适配器都挂在同一种网络模式。这里有个容易忽略的点：VMware 允许不同虚拟机挂在不同模式，Host_A 仅主机、Host_B NAT 也能开机运行，但两者永远互不通。检查“编辑虚拟机设置-硬件-网络适配器”里的实际勾选状态，比相信记忆可靠得多。

4. 预共享密钥配置三步走：MMC、向导参数与安全措施调优

4.1 先建好 MMC 控制台：IP安全策略管理和IP安全监视器一起装

Windows 的 IPsec 策略不在“控制面板”里直接暴露完整入口，藏在一堆管理单元背后。在 Host_A 的“运行”窗口输入 MMC 打开空白控制台，通过“文件-添加/删除管理单元”把两个单元加进去。“IP安全策略管理（在本地计算机）”负责创建和指派策略，“IP安全监视器”负责事后查看安全关联状态。两者一起装是省事的关键：配置完成后立刻在同一个控制台里切换到监视器页面看主模式关联是否建立，不用再开第二个窗口。

添加管理单元时注意选择作用域是“本地计算机”，不是“另一台计算机”或“Active Directory”。两台虚拟机是工作组环境，没有域策略下发的条件，必须各自在本地维护策略。单元名选错会导致策略建在别人的机器上，自己这台反而看不到。添加完成后建议把控制台另存为一个 .msc 文件放桌面，方便后续随时打开。

4.2 策略向导的四个关键决策点

创建策略入口在“控制面板-管理工具-本地安全策略”，右侧窗口右键“IP安全策略，在本地计算机”选“创建IP安全策略”。向导会依次经过：名称描述、默认响应规则、身份验证方法三个屏。默认响应规则一律勾选“激活此规则”，身份验证方法选“使用此字符串保护密钥交换（预共享密钥）”，填入约定好的字符串。

向导结束进入“属性-规则”页后，后续向导有四个决策点不能走默认值：

第一个是“隧道终结点”，选“此规则不指定隧道”。这个实验是两台同网段虚拟机直连，数据流没有经过网关，不涉及隧道封装，如果选了隧道终结点并填了对端地址，策略会试图把流量封装成隧道模式，反而导致抓包看到的头部结构与预期不符。

第二个是“网络类型”，选“所有网络连接”。实验文档里选的是所有网络连接而不是“局域网”，原因很简单：仅主机模式下虚拟机的流量走虚拟网卡，Windows 会把它识别为“本地连接”，但某些网卡驱动或虚拟化环境里也可能出现多个活动连接，“所有网络连接”保证策略在任何活动网卡上都生效，避免连接类型判断造成的策略漏匹配。

第三个是“IP筛选器列表”，选“所有IP通讯”。这个筛选器匹配源地址任意、目的地址任意、协议任意的所有 IP 包。实验目的是保护两台虚拟机之间的所有流量，这个选项覆盖得最全。如果只选“ICMP 通讯”，后面抓包就只能看到 ICMP 被保护，其他协议裸奔，验证结论就不完整。

第四个是“筛选器操作”，这是最容易点错的地方。选“协商安全”而不是“许可”或“阻止”，再选“不与不支持IPsec的计算机通讯”，最后在“IP通信安全措施”里选“自定义”。筛选器操作决定了对匹配流量采取的动作：许可是直接放行不协商，阻止是丢弃，协商才是建立 IPsec 保护的动作。“不与不支持IPsec的计算机通讯”保证对端如果没配策略，协商直接失败，宁可断网也不裸传，这个选项把实验结论收敛得很干净。

4.3 自定义安全措施参数：为什么是 MD5、SHA1 加 3DES

安全措施入口在“筛选器操作向导-自定义”后的“设置”按钮里，这里有三个参数决定受保护流量的密码学形态：

MD5 和 SHA1 都不被视为强安全算法，但实验文档指定它们，目的是让抓包特征明显。3DES 同理，它的分组加密特征在 Wireshark 的 ESP 载荷里看起来非常规整，适合教学观察。把这组参数配完后，数据平面会同时带 AH 头和 ESP 封装，日志里也能看到协商结果是 ESP:3DES/SHA1 + AH:MD5，这套组合在“安全措施”屏会清楚列出来。

密钥交换设置区域还有一个“生成新的密钥设置”按钮，点开后能看到 IKE 安全算法的默认值，包括 Diffie-Hellman 组和密钥生命周期。实验默认值通常不需要改，但要注意密钥生命周期：默认 480 分钟或一定流量占空比到期后，IKE 会自动重协商建立新的 SA，抓包时如果看到中间穿插新的 ISAKMP 流量，那可能是密钥轮换而不是异常。想减少干扰，可以把生命周期调长，但这属于边界参数，大多数人直接保持默认。

规则属性里最后一步是确认只勾选新配置的筛选器，并且不勾“默认响应规则”那一条。如果你同时勾了默认响应和自定义规则，策略匹配时会先按自定义规则跑，但默认响应规则的存在会让协商行为变得不可预期。文档里专门提醒“仅勾选新配置好的IP筛选”，就是避免这种双规则互踩。

一切配置完成后，回到“本地安全设置”窗口，右键新策略点“指派”，右侧“策略已指派”栏变“是”。此时在 Host_A ping Host_B，出现 Negotiating IP Security 是正常现象，等协商完成后基本就通了。别忘了 Host_B 也要完整做一遍同样的配置，IPsec 是双向协议，只在一边配策略、另一边裸奔，结果是协商失败、双向都不通。

5. 避坑排查：配了不生效与协商超时的四个典型问题

5.1 第一次 ping 显示 Negotiating IP Security 然后超时

现象：策略指派完成后，第一次 ping 对端，终端提示 Negotiating IP Security，随即显示请求超时，连续几次后才恢复连通。

原因：这是 IKE 协商的中间状态。第一个数据包到达时，发送端发现匹配了 IPsec 策略但还没有 SA，于是触发 IKE 协商，此时数据包本身不会被立即转发，而是等待安全关联建立。DH 交换、身份认证、快速模式协商需要往返几个报文，时间在几百毫秒到几秒之间，ping 的默认超时时间短，就表现为“失败”。

解决：不要急着改策略，等三到五秒再 ping 一次。打开“IP安全监视器-主模式-安全关联”，看到 Host_A 与 Host_B 之间存在活动关联后，连通性自然会恢复。如果一直停留在协商状态，则检查两端预共享密钥是否一致、时间是否正确，IKE 对时间偏差敏感，虚拟机关机后时间漂移严重时也会导致协商失败。

5.2 策略指派了但两机之间始终互通，且抓不到 IPsec 流量

现象：策略在两边都指派成功，ping 正常通，但 Wireshark 里只有明文 ICMP，没有 AH/ESP 头部，协商好像从未发生。

原因：最常见的是筛选器操作被配成了“许可”。筛选器操作向导里如果选了“许可”而不是“协商安全”，策略对匹配流量的动作就是直接放行，IPsec 完全不会介入，通信表现为裸传。另一个原因是“与不支持IPsec的计算机通讯”选错了方向，选成“允许”也会让发送端在协商失败后降级为明文通信，策略形同虚设。

解决：回到“新IP安全策略属性-规则-筛选器操作”，确认动作是“协商安全”，且“不允许与不支持IPsec的计算机通讯”。改完重新指派策略。检查方法是在 Host_A 上用指令查询生效规则，netsh ipsec static show policy name="新IP安全策略" 能看到筛选器操作的具体动作，是“协商安全”还是“许可”一目了然。

5.3 抓包时能看到 ISAKMP 协商，但看不到 ESP/AH 数据包

现象：Wireshark 里 UDP 500 端口的 ISAKMP 报文大量存在，协议协商也显示成功，但后续数据流量仍然是明文 ICMP，或者只有零星 ESP。

原因：主模式协商成功不代表数据流受到保护。快速模式协商才有对应数据流的 SA，而快速模式由一个名为“QM offer”的提议驱动，如果安全措施里没有匹配的算法组合，或者策略只列出了 AH 但实际流量要求 ESP，快速模式会协商失败。协商阶段结束后双方没有建立数据平面 SA，后续流量自然裸传。还有一种可能是抓包网卡选错了链路，比如在宿主机物理网卡上捕获，而虚拟机流量根本不过那块网卡，详见第六章。

解决：在“IP安全监视器-快速模式-安全关联”里确认是否存在活动 SA。若快速模式关联为空，回到安全措施设置里重新核对算法组合，确保两端完全一致。Host_A 配 AH:MD5 + ESP:3DES/SHA1，Host_B 也必须完全一致，任一算法不同，快速模式协商都会失败但主模式仍然显示正常。

5.4 只有一台虚拟机配了策略，结果两台都断网

现象：只给 Host_A 配置并指派了 IPsec 策略，Host_B 保持原样，结果 Host_A ping 不通 Host_B，Host_B ping 通 Host_A（或反过来）。

原因：这与“不与不支持IPsec的计算机通讯”设置直接相关。Host_A 发出第一个包时触发 IKE 协商，但 Host_B 没有策略监听 UDP 500 的协商请求，Host_A 等不到协商响应，又设置了“不与不支持IPsec的计算机通讯”不可降级，于是连接直接断开，表现为双向不可通。

解决：先把单边策略解除指派，恢复通信，再按同样步骤把 Host_B 补齐。IPsec 成对生效，任何一边缺配置，整体连通性就会归零。这个坑我在模拟项目里踩过一次，当时以为是策略里 IP 地址写错，排查了半天，最后发现只是另一边没配。从那以后我每次都强制两边同步配置，再进入抓包验证环节。这也是这个实验“先看 Host_A 单边配置失败，再两边都配置成功后连通”的教学设计本身想展示的过程。

6. Wireshark抓包分析：用过滤器和字段顺序读出协商过程

6.1 选对网卡和捕获过滤器

抓包前先决定在哪个接口上捕获。两台虚拟机挂在仅主机模式的虚拟网段上，流量经过宿主机上的虚拟网卡接口，Wireshark 需要选择那个接口，而不是物理网卡。在 Windows 下，仅主机模式对应的是“VMnet1”或名称含“VMware Virtual Ethernet Adapter”的接口。接口选错是最常见的抓包无效原因。

ip.addr == 192.168.153.2 && (isakmp || esp || ah)

这个过滤器组合了两个条件：只关注 Host_A 的地址，协议限定在 isakmp、esp、ah 三类。isakmp 对应 UDP 500 的 IKE 协商报文，esp 对应 IP 协议号 50，ah 对应 IP 协议号 51。加上地址条件能把抓包文件里无关广播和 ARP 全部过滤掉，只留下与这次 IPsec 通信相关的流量特征。

如果需要观察双向协商，把地址改成条件对：

(ip.addr == 192.168.153.2 && ip.addr == 192.168.153.3) && (isakmp || esp || ah)

ip.addr 操作符匹配源或目的地址，两个条件同时满足会得到两机之间的完整协商轨迹。这个写法比单独看单侧更清晰，能直接看到协商的请求响应成对关系。捕获到一定数量后停止，一般几十秒内存下的包量足够分析。

6.2 数据包顺序与字段识别

抓包顺序一般是先一段 ISAKMP 协商，随后进入稳定的 ESP/AH 数据流。ISAKMP 报文展开后可看到 SA 载荷里列出的加密算法和完整性算法，这些值应与自定义安全措施里配置的 3DES、SHA1、MD5 对应上。ESP 报文则重点看三处：SPI（标识是哪条 SA）、序列号（防重放的计数）、载荷长度。AH 报文头部结构相对简单，载荷区可见完整性校验值覆盖的字段。

分析时有个容易误解的地方：ESP 加密后，ICMP 的 type 和 code 完全不可见。如果你在包列表里点开一个 ICMP 报文却看不到标准的 “Echo (ping) request”，而只是 ESP 封装，那是预期行为，不是抓包异常。同样，ping 不通时抓包看到大量 ISAKMP 重传，基本可以断定是协商失败，把注意力放在身份认证载荷的对端匹配上。

6.3 用“安全关联 + 抓包”双证据做最终验证

Wireshark 不是唯一验证手段，我会把它和“IP安全监视器”配合使用。先在控制台里打开“IP安全监视器”，主模式安全关联里能看到身份验证方法一栏明确写着“预共享密钥”，快速模式安全关联里能看到协商出的协议是 ESP:3DES/SHA1 + AH:MD5，这和抓包里实际出现的头部完全对应，形成双证据闭环。

验证通过后再做一个抗丢失测试：在 Host_A 上持续 ping Host_B，同时观察抓包窗口，此时 ESP 包数量应持续增长，AH 包同样稳定出现，不再有新的 ISAKMP 报文。如果中途突然插入新的 ISAKMP 流量，说明 SA 正在轮换或老化，属于正常行为。最后把两台虚拟机关机再开机，重新 ping，确认策略在重启后依然生效——这能验证策略是否已持久化并随系统加载。

这套流程走完之后，建议留着抓包文件，后续做密钥不同导致的失败实验时，和正常抓包做对比，两个文件一对照，协商流程差异会非常直观。从那次以后我每次配置类似 IPsec 实验，都会强制走一遍“快照基线、双端配置、安全关联确认、抓包验证”的顺序，这套顺序帮我省下了大量来回查策略的时间。希望这次的记录能帮你少走几步弯路，顺利把 IPsec 的协商和抓包跑通。

本文还有配套的精品资源，点击获取