IKEEXT 服务被禁用时 L2TP/IPsec 连接失败

一台笔记本能连上 IKEv2 网关，却在 L2TP/IPsec 网关上失败，而且错误在任何用户名发出之前就出现了。配置文件通常是第一个怀疑对象，通常也是错的。Windows 把 IPsec 密钥交换放在一个服务里运行，该服务被禁用时，内置客户端就没有可用来协商的协议栈。动任何一个配置字段之前，先确认这个服务，再查清是谁禁用了它。

失败背后的服务

IKE and AuthIP IPsec Keying Modules 在服务列表中显示为 IKEEXT，负责执行密钥交换，并在 Windows 上占用 UDP 500 和 4500 套接字。禁用它，L2TP/IPsec 和 IKEv2 都会失去协商者，而 PPTP 和 SSTP 仍能工作，因为它们不依赖它。这种分化解释了为什么用户会报告同一台机器上一种 VPN 能用、另一种却死了。该服务属于操作系统的一部分，任何配置项都替代不了它。

释放这两个端口正是产生错误建议的副作用。某个工具或论坛帖子发现 500 和 4500 被占用，就停掉服务来释放它们，同时悄悄地从主机上移除了 IPsec。这两个效果是同一个动作，所以任何建议清空端口的指南描述的是一笔交换，而不是修复。

不靠猜把服务恢复

向服务管理器问两个问题：启动类型是什么，当前状态是什么。前者告诉你服务重启后会不会回来；后者告诉你它现在是否在运行。请在提升权限的命令行里执行这两个查询，这样同一个 shell 随后就能修改设置。

sc qc ikeext
sc query ikeext

启动类型为 Disabled 就解释了全部症状，修复办法是把它改回 Automatic 并启动。在服务控制台里，条目显示的是显示名称 IKE and AuthIP IPsec Keying Modules，所以在那份列表里搜 IKEEXT 什么也找不到。如果服务是在一次失败连接之后才启动的，请重启，因为以这种顺序初始化的协议栈可能以看似无关的方式失败。

sc config ikeext start= auto
net start ikeext

什么又会把它关掉

有些第三方 VPN 套件自带 IPsec 实现，并在安装时禁用 IKEEXT，之后 Windows 客户端就不工作了。在改配置文件毫无效果的机器上，卸载另一个产品恢复了 L2TP/IPsec；不带冲突组件重装也同样有效。该服务是在安装时被禁用的，不是用户切换的。

组策略也能锁定启动类型，这种情况下本地修改会在下次刷新时被回滚，拥有该策略的管理员必须去改。在重启前、重启后以及其他产品更新后分别记录启动类型，每次带上日期。反复回到 Disabled 的值会靠规律暴露它的主人，而不是靠猜测。

先读阶段，再读日志

服务跑起来之后，失败发生在哪个阶段决定下一步看哪里。IKE 阶段卡住通常意味着 UDP 500 或 4500 从未到达服务器，或者服务器在 NAT 后面而缺少对应的封装设置。走到凭据提示才失败是 PPP 认证问题，不是 IPsec。隧道建立起来却什么也通不了，是路由或拆分隧道故障，这三者中只有第一个位于 VPN 配置里。

证书配置会多出一个阶段。客户端必须信任签发机构，证书必须写明被验证的服务器；任一条件不满足时，对话框仍然报初始协商错误，所以真正原因出现在事件日志里。改配置之前先读日志条目，因为对话框把几种不同的失败压缩成了一句话。证书过期产生的对话框和禁用服务时一模一样，所以日志条目才重要。

记录每次尝试失败的阶段、错误文本和时间戳。这三个字段把可达性问题、认证问题和路由问题区分开，也让下一次改动成为判断而不是猜测。

本地修复证明不了什么

恢复服务只修好了路径上属于笔记本的那一半。服务正常只能证明本地这一半：远端仍必须接受选定的提议、提供的凭据以及数据包到达的源地址。笔记本上做的任何事都补偿不了在到达对端之前就丢弃 UDP 500 的防火墙。服务状态正常是先决条件，而不是隧道一定能建立的证据。

只有在接受 Windows 的 IPsec VPN 会停止工作这一点的前提下，禁用 IKEEXT 来释放端口才说得过去。它是通过移除需要该端口的功能来解决端口冲突，这很少是用户想要的交换。动手之前，确认服务存在、设为 Automatic 且在运行，没有安装第二套 IPsec 协议栈，并且预共享密钥或证书链与网关匹配。

• 客户端连接之前，IKEEXT 存在、设为 Automatic 且正在运行。
• 没有别的东西占用 UDP 500 或 4500。
• 旧客户端没有留下第二套 IPsec 协议栈。
• 密钥或证书链与网关配置匹配。
• 改配置之前已经记录了失败的阶段。