Windows IPSEC策略配置

Windows的IP安全策略（IPsec）并非什么神秘的高级功能，它就是一套内置于操作系统的、基于规则的网络层安全机制。很多人误以为只有域环境或企业级服务器才能用，实际上，从Windows 7到Windows 11，专业版及以上版本都完整支持。它的核心作用就两个：一是对网络流量进行加密，防止数据在传输途中被嗅探；二是对通信双方进行身份验证，确保数据来源可信，不被篡改。你不需要安装任何第三方软件，只要配置得当，就能实现主机防火墙级别的端到端安全通信。

在动手配置之前，必须搞清楚IPsec运作的三大组件，否则面对策略向导只会一头雾水。首先是认证头（AH），它只提供数据完整性校验和源身份认证，不加密载荷。这意味着数据内容本身是明文传输的，但接收方可以确信数据在传输过程中未被篡改，且确实来自声称的发送方。其次是封装安全载荷（ESP），这是最常用的协议，同时提供加密、完整性校验和身份认证。ESP会加密整个数据包的有效载荷，甚至在某些模式下连原始IP头都能隐藏。最后是安全关联（SA），这不是协议，而是通信双方协商好的一组参数，包括用哪种协议、什么加密算法、密钥怎么交换。每次成功的IPsec通信都需要建立一对SA，分别负责入站和出站流量。

传输模式只加密IP数据包的有效载荷，原始IP头保持原样。这种模式适用于两台主机之间的直接通信，比如保护一台管理服务器与数据库服务器之间的SQL查询流量。由于IP头未加密，中间路由设备仍然可以看到源目地址，能正常转发，但无法窥探实际传输的内容。隧道模式则会将整个原始IP数据包封装进一个新的IP包中，连原始IP头一起加密或认证。这种模式典型应用场景是网关到网关的通信，比如两个分支机构通过互联网建立安全连接，内网主机的真实IP地址被完全隐藏。在Windows单机策略配置中，绝大多数情况用的是传输模式。

Windows IPsec支持三种身份验证方式，选择哪种直接决定了你的部署复杂度与安全等级。Kerberos是域环境下的默认选择，它利用活动目录自动完成双向身份验证，无需手动管理密钥或证书，配置最简单，但所有参与通信的计算机必须加入同一个域或受信任的域。证书验证使用公钥基础设施（PKI），计算机持有由受信任证书颁发机构签发的证书，通信时互相出示并验证。这种方式灵活性最高，适合工作组环境或跨组织通信，但需要事先部署证书服务，每台机器都要正确安装证书。预共享密钥是最不推荐的方法，它就像设置一个简单的密码，双方配置相同的字符串即可完成验证。问题在于密钥以明文形式存储在注册表中，任何有管理员权限的人都能读取，而且密钥强度完全取决于使用者的设置习惯，容易被暴力破解或社会工程学手段获取。

打开运行对话框输入secpol.msc，这是进入本地安全策略最直接的路径。在左侧控制台树中找到“高级安全Windows Defender防火墙”，注意不是传统的“IP安全策略”节点，那个是基于旧版管理界面的，功能受限且与高级防火墙规则不互通。展开后右键点击“连接安全规则”，选择新建规则。系统会提供五种规则类型：隔离规则用于限制哪些计算机可以连接本机；身份验证豁免用于指定不需要IPsec保护的例外地址；服务器到服务器用于保护两台特定主机间的通信；隧道规则用于网关场景；自定义规则则允许你完全控制所有参数。对于大多数服务器加固场景，选择自定义规则最为合适。

假设有两台Windows Server 2022服务器，IP地址分别为192.168.10.10和192.168.10.20，需要确保它们之间所有TCP通信都经过加密。在192.168.10.10上新建自定义连接安全规则。在终结点页面，指定本地地址为192.168.10.10，远程地址为192.168.10.20。在要求页面，选择“要求对入站和出站连接进行身份验证”。在身份验证方法页面，如果两台服务器都在域内，直接选默认的Kerberos即可；如果是工作组环境，需要添加第一身份验证方法为预共享密钥并输入一致的字符串。在配置文件页面，勾选域、专用和公用，确保无论网络位置如何变化规则都生效。命名规则后完成创建。

此时规则已经存在，但还需要确认与之匹配的防火墙规则允许流量通过。在同一个控制台中进入“入站规则”，找到与所需服务对应的规则，双击打开属性，在“常规”选项卡中确保操作是允许连接，然后在“远程计算机”选项卡中可进一步限定来源。关键一步是切换到“高级”选项卡，在“边缘遍历”下方找到“连接安全规则”，确保其与刚才创建的连接安全规则关联。如果没有显式关联，系统会使用默认行为，通常也能正常工作，但显式关联能避免策略冲突。

图形界面适合单机操作，但面对几十上百台服务器，必须依靠命令行。Netsh是配置IPsec的传统工具，功能完整但语法复杂。以创建上述规则为例，先创建连接安全规则：

netsh advfirewall consec add rule name="SecureSQL" endpoint1=192.168.10.10 endpoint2=192.168.10.20 action=requireinrequireout auth1=computerpsk auth1psk="YourStrongPreSharedKey"

这条命令创建了一条名为SecureSQL的规则，要求双向身份验证，使用预共享密钥。如果使用证书验证，auth1参数改为computercert，并配合cauth1指定证书颁发机构。接下来确保防火墙允许对应端口的流量：

netsh advfirewall firewall add rule name="Allow SQL" dir=in action=allow protocol=TCP localport=1433 remoteip=192.168.10.20

对于更现代的部署方式，PowerShell提供了更强大的控制能力。使用New-NetIPsecMainModeRule和New-NetIPsecQuickModeRule可以分别创建主模式规则和快速模式规则。主模式负责协商密钥和身份验证，快速模式负责实际数据加密。以下示例创建一套完整的IPsec策略：

$mainModeRule = New-NetIPsecMainModeRule -DisplayName "MainMode-Auth" -LocalAddress 192.168.10.10 -RemoteAddress 192.168.10.20 -AuthMethod "PSK" -PreSharedKey "YourStrongPreSharedKey"
$quickModeRule = New-NetIPsecQuickModeRule -DisplayName "QuickMode-Encrypt" -MainModeRule $mainModeRule -EncryptionAlgorithm "AES256" -IntegrityAlgorithm "SHA256" -Protocol "ESP"

这套命令指定了使用预共享密钥进行主模式协商，快速模式采用AES256加密和SHA256完整性校验，协议使用ESP。相比netsh，PowerShell的模块化设计让策略管理更加灵活，可以分别调整身份验证和加密参数。

IPsec的安全性很大程度上依赖于密钥的定期轮换。主模式SA默认生命周期为480分钟，快速模式SA默认生命周期为60分钟。这意味着即使攻击者截获了加密流量，他们只有最多一小时的时间来破解快速模式密钥，而主密钥每八小时更换一次。对于高安全需求的环境，可以通过PowerShell调整这些值：

Set-NetIPsecMainModeRule -DisplayName "MainMode-Auth" -MainModeLifeTime 240
Set-NetIPsecQuickModeRule -DisplayName "QuickMode-Encrypt" -QuickModeLifeTime 30

将主模式生命周期缩短到240分钟，快速模式缩短到30分钟，可以进一步降低密钥被破解的风险，但会增加CPU开销，因为密钥协商需要计算资源。在性能敏感的环境下需要权衡。

Windows IPsec支持的加密算法套件随着操作系统版本演进不断更新。在Windows Server 2016及更高版本中，默认协商的加密套件已经相当安全，包括AES-GCM和AES-CBC变体。但如果你需要与旧版Windows或非Windows系统互通，就必须注意算法兼容性。例如Windows Server 2008 R2默认不支持AES-GCM，只支持AES-CBC和3DES。通过Get-NetIPsecQuickModeCryptoSet可以查看当前系统支持的加密套件列表。如果需要创建自定义加密套件以兼容旧系统：

$cryptoSet = New-NetIPsecQuickModeCryptoSet -DisplayName "LegacyCompatible" -EncryptionAlgorithm "AES128" -IntegrityAlgorithm "SHA1" -Protocol "ESP"
Set-NetIPsecQuickModeRule -DisplayName "QuickMode-Encrypt" -QuickModeCryptoSet $cryptoSet

注意SHA1和AES128的组合仅用于兼容性场景，新部署应坚持使用AES256-GCM和SHA384或更高强度算法。在纯Windows Server 2019以上环境，系统会自动协商最强算法，无需手动干预。

IPsec配置错误最常见的表现是连接超时或直接拒绝。Windows防火墙高级安全控制台中的“监视”节点是排错的第一站。展开后可以看到“连接安全规则”和“安全关联”，前者显示哪些规则处于活动状态，后者实时列出当前建立的主模式和快速模式SA。如果SA状态显示为“正在协商”且长时间未变为“已建立”，问题通常出在身份验证环节。使用事件查看器定位到“应用程序和服务日志”下的“Microsoft-Windows-IPsec/Operational”日志，这里记录了详细的协商过程。常见错误代码如0x80090317表示证书验证失败，0x8009030D表示预共享密钥不匹配。

Windows内置的ipseccmd命令（需要安装Windows SDK）或更现代的Get-NetIPsecStatistics PowerShell cmdlet可以提供统计信息，包括发送和接收的字节数、验证失败次数、重放攻击检测次数等。如果看到大量验证失败计数持续增长，基本可以确定是身份验证配置有问题。网络抓包工具也能分析IPsec流量，但ESP加密后的数据包内容不可读，只能看到外层IP头和ESP头，此时重点检查源目地址和SPI值是否与预期一致。

很多人配置完连接安全规则后，发现流量依然不通，原因在于忽略了防火墙规则与连接安全规则的配合逻辑。连接安全规则只负责“如何保护流量”，不负责“是否允许流量”。你仍然需要防火墙规则来放行特定的协议和端口。两者的关系是：防火墙规则定义允许什么流量通过，连接安全规则定义这些流量必须满足什么安全条件。如果一条入站防火墙规则允许来自任意地址的TCP 1433端口流量，但没有关联连接安全规则，那么未加密的SQL查询也会被接受。正确的做法是，在防火墙规则的“远程计算机”或“高级”属性中，将连接安全规则绑定，或者直接在防火墙规则的条件中指定“仅允许经过身份验证的流量”。

域隔离是IPsec在企业环境中的高级应用。核心思想是：域内所有计算机默认要求入站连接必须经过IPsec身份验证和加密，只有少数提供公共服务的服务器设置豁免规则。实施步骤是先在域控制器上通过组策略创建一条隔离连接安全规则，终结点设置为“任何IP地址”，要求入站和出站都进行身份验证，身份验证方法选择Kerberos。这条规则会分发到所有域成员计算机。然后为域控制器、DNS服务器、DHCP服务器等基础设施角色创建豁免规则，因为客户端在加入域之前无法完成Kerberos验证，必须允许未加密的DNS查询和域服务定位流量。豁免规则的动作设置为“不要求身份验证”，并精确限定远程IP地址为这些服务器的地址。通过这种层层递进的方式，域内所有非豁免流量都被强制加密，即使攻击者获得了内网访问权限，也无法嗅探或篡改任何通信内容。

IPsec加密会消耗CPU资源，尤其在高速网络环境下，软件加密可能成为瓶颈。现代服务器处理器普遍支持AES-NI指令集，能极大加速AES算法的加解密运算。Windows IPsec默认会利用AES-NI，无需任何配置。在10Gbps网络环境下，启用AES-NI的至强处理器可以轻松跑满带宽，CPU占用率通常不超过20%。但如果你使用了较旧的处理器或虚拟机未正确暴露AES-NI特性，性能会明显下降。可以通过性能监视器添加“IPsec v4 Driver”和“IPsec v6 Driver”计数器，观察每秒处理的字节数和活动SA数量，评估IPsec对系统的影响。对于虚拟机环境，需要在Hyper-V或VMware设置中确保向客户机暴露主机CPU的AES-NI功能。

某些IPsec行为无法通过图形界面或命令行直接配置，需要修改注册表。路径位于HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent。例如，DWORD值AssumeUDPEncapsulationContextOnSendRule设置为2，可以强制IPsec使用UDP封装，解决NAT设备对ESP协议支持不佳的问题。另一个有用的值是EnablePacketQueuing，设置为1允许在SA协商期间排队数据包，避免连接初始阶段的丢包。修改注册表后需要重启IPsec策略代理服务或直接重启系统才能生效。这些参数属于底层调优，仅在遇到特定网络兼容性问题时才需要使用，正常部署无需改动。