正文共：1888 字 46 图，预估阅读时间：2 分钟
IPsec的RFC协议规范提到（IPsec：RFC2401-互联网协议的安全架构），IPsec定义了两种类型的SA：传输模式和隧道模式。传输模式SA是两个主机之间的安全联盟，也是我们前面使用Windows系统测试的场景（Windows和H3C VSR对接IPsec VPN）；隧道模式SA是两个安全网关之间的安全联盟，我们之前测试的设备对接大多是安全网关之间隧道模式的IPsec（使用IKE建立保护IPv6报文的IPsec隧道）。
那Windows系统是否可以支持隧道模式呢？我们今天配置Windows Server主机和VSR协商试一下。
从“开始”→“管理工具”打开“本地安全策略”，或者运行secpol.msc也可以，然后从这里开始配置IPsec。
右击“IP安全策略，在本地计算机”，点击“创建IP安全策略”。
欢迎页面，直接“下一步”。
配置IP安全策略的“名称”。
安全通讯请求页面，有“激活默认响应规则”的选项，不要选，给低版本系统使用的。
勾选“编辑属性”，完成配置。到这里就完成了一个IP安全策略的添加。
点击完成后，在IPsec策略属性页面，有一个默认的IP安全规则，不用管它，点击“添加”IP安全规则。
对于使用隧道模式的IPsec策略，需要添加2条IP安全规则。在向导页面，可以看到IP安全规则的配置步骤：IP隧道操作属性、身份验证方法和筛选器操作。
首先配置第一条从Windows系统到VPN网关的策略，这里选择【隧道终结点由下列IP地址指定】，也就是隧道模式，配置IPv4隧道终结点为VPN网关的IP地址。
网络类型选择默认的“所有网络连接”即可。
然后进入到“IP筛选器列表”选择页面，此时列表为空，点击“添加”。
配置IP筛选器列表名称，点击“添加”来增加IP筛选器。
IP筛选器用于筛选IP流量需要的源、目标和通信类型信息。
可选描述，勾选“镜像”，也就是双向流量。
指定源地址，选择【我的IP地址】。
目标地址选择【一个特定的IP地址或子网】，并填入VSR的子网。
协议选择【任何】，这三步就像是VSR设备配置的IPsec保护的ACL一样。
完成IP筛选器配置。
确认IP筛选器列表信息无误，点击确定。
在安全规则向导中，选中刚才创建的IP筛选器列表，点击下一步。
进入筛选器操作选择页面，列表默认为空，点击“添加”。
添加IP安全筛选器操作，对应VSR的IPsec策略配置。
配置名称和描述信息。
操作选择【协商安全】。
不允许与不支持IPsec的计算机通讯。
IP流量安全也就是对流量进行完整性校验和加密，选择【自定义】，点击“设置”。
这里主要是确认VSR需要配置的算法，配置仅勾选ESP，完整性算法选择【MD5】，加密算法选择【DES】，点击“确定”完成设置。
设置完成后，点击“下一步”。完成IP安全性筛选器配置。
选中刚才添加的筛选器操作，点击“下一步”。
配置身份验证方法，选择预共享密钥（PSK），并配置密钥。
点击完成，到这里就添加完了第一条IP安全规则。
通过前面的操作，Windows系统到天翼云网关的IP安全规则已经添加好了，我们现在重复这些操作，添加一条反向的从天翼云网关到Windows系统的IP安全规则。
IPv4隧道终结点配置为Windows系统的网卡IP地址。
IP筛选器列表配置的源地址和目标地址与前面配置的相反。
筛选器操作可以复用，无需重复配置。
配置身份验证方法和第一次的配置保持一致。
添加完成后，检查新添加的两条IP安全规则处于选中状态。
切换到“常规”页签，点击“设置”查看或调整IKE秘钥交换的策略属性。
这里的相关配置需要和VSR保持一致；点击“方法”设置安全方法，我们本次仅记录算法，加密算法使用【3DES】，完整性算法使用【SHA1】，DH组使用【中(2)】。
IP安全策略创建完成之后，默认是没有激活的，需要在“本地安全策略”中，右击策略名称点击“分配”进行指派。
分配之后，策略已支指派状态变更为“是”。
接下来，我们根据Windows Server的配置，在VSR上创建IPsec策略。
首先，创建名称为windows的IKE keychain，配置与IP地址为10.24.1.2的对端使用的预共享密钥为明文tietouge。
#ike keychain windowspre-shared-key address 10.24.1.2 255.255.255.0 key simple tietouge
我们根据Windows Server的IKE配置，新建一个安全提议，配置认证算法为SHA1，加密算法为3DES，指定DH组为2，设置SA生存时间为28800秒。
#ike proposal 3402sha3des-cbcdh group2sa duration 28800
创建并配置IKE profile，名称为windows，调用keychain、proposal，并设置身份标识。
#ike profile windowskeychain windowsmatch remote identity address 10.24.1.2 255.255.255.255match local address 10.24.1.1proposal 3402
配置一个IPv4高级ACL，定义要保护由子网10.24.1.0/24和子网10.20.24.0/24的互访数据流。
#acl advanced 3402rule 0 permit ip source 10.20.24.0 0.0.0.255 destination 10.24.1.0 0.0.0.255rule 5 permit ip source 10.24.1.0 0.0.0.255 destination 10.20.24.0 0.0.0.255
创建IPsec安全提议windows，IP报文的封装形式默认为隧道模式，无需调整；采用的安全协议默认为ESP，无需调整；配置ESP协议采用的加密算法为DES，认证算法为MD5。
#ipsec transform-set windowstunnelprotocol espesp encryption-algorithm des-cbcesp authentication-algorithm md5
创建一条IKE协商方式的IPsec安全策略，名称为windows，序列号为10。
指定引用ACL 3402，引用安全提议为windows，引用的IKE profile为windows。指定IPsec隧道的本端IP地址为10.24.1.1，对端IP地址为10.24.1.1。
#ipsec policy windows 10 isakmptransform-set windowssecurity acl 3402local-address 10.24.1.1remote-address 10.24.1.2ike-profile windows
在接口G2/0上应用安全策略windows。
#interface GigabitEthernet2/0ip address 10.24.1.1 255.255.255.0ipsec apply policy windows
配置完成后，我们在Windows Server系统中使用ping触发协商，现象又回到了之前配置隧道模式的场景，首包丢失了，之后业务正常通信。
在VSR上查看IKE SA和IPsec SA信息。
查看抓包信息，确实和路由器的隧道模式现象一样，第一个ping包用于协商IPsec隧道，建立起IPsec隧道连接之后，ping包只有2个。
需要注意的是，Windows和VSR对接，并不能从VSR侧触发协商，可以协商起IKE的SA，但是不能协商起IPsec的SA。
如果从Windows系统抓包查看，可以看到快速模式协商失败，无法进入ESP加密的报文交互。
而如果我们从Windows侧触发协商之后，VSR侧就可以正常发起到Windows系统的访问了。
长按二维码
关注我们吧
