经过不懈努力，我们基于strongSwan的IPsec VPN管理系统，已经成功支持了证书认证（点击即连！最强IPsec VPN管理系统终于能小白式操作了），并且可以作为VPN网关来使用（从点到网！我们的strongSwan管理系统支持网关模式了，可作中心枢纽互联多分支）。
在上个案例中，我们介绍的案例比较粗糙，适用于两端都具有公网IP地址的场景。理想很丰满，现实很骨感。但在实际使用中，面对分支机构、居家办公、移动设备等场景，可能大部分设备都不具备公网IP地址，或者是通过NAT映射配置的公网IP地址（浮动IP地址），这个时候该怎么配置互联呢？
今天，我就来演示一下这两种场景。测试组网如下所示：
其中：
VPN_GW、SPOKE1、SPOKE2三台设备均部署了基于strongSwan的IPsec VPN管理系统，SPOKE1和SPOKE2位于NAT设备后面，不具备公网IP地址，需要通过NAT设备CT、CU访问VPN_GW。需要实现PC1和PC2之间的互访。
接下来，我们先配置VPN_GW，新建一个到SPOKE1的IPsec连接。
相比于两端都有公网IP地址的情况，穿越NAT设备时，最重要的一点就是协商模式要选择【Aggressive/野蛮模式】（采用IKE野蛮模式建立保护IPv4报文的IPsec隧道）。此外，对端IP地址配置为SPOKE1经过NAT设备转换后的IP地址。
当然，这里的本端ID和对端ID，我们没有填写，因为留空的情况下，默认会带入两端的IP地址。
在二阶段配置中，本端网段和对端网段正常配置；安全协议只能选择【ESP】，因为AH协议无法穿越NAT设备（天翼云研发告诉我：AH封装的IPsec不能穿越NAT设备）。
这样，我们就配置好了VPN_GW到SPOKE1的IPsec连接。
接下来，我们配置SPOKE1到VPN_GW的IPsec连接。
注意，在一阶段配置中，本端IP地址无法使用设备上不存在的IP地址，所以我们要使用真实的接口IP地址10.11.1.1。而本端ID要与VPN_GW上配置的对端ID相对应，我们填入NAT设备转换后的IP地址124.2.17.2。同样的，对端ID留空则自动带入对端IP地址，可以不管。
同样的，二阶段配置中的本端网段和对端网段正常配置就可以了。
这样，VPN_GW和SPOKE1之间的IPsec连接就创建好了。
但是，我们还要考虑另外一种情况，那就是常见的家庭宽带拨号，NAT之后地址我们一般是无法预料的，此时该怎么办呢？
参考之前H3C设备的配置方法（多分支NAT穿越场景下通过POP节点实现分支间的IPsec加密互联），我们可以引入FQDN，也就是指定本端ID和对端ID。
接下来，我们创建VPN_GW和SPOKE2之间的IPsec连接。
这次，我们先配置SPOKE2设备。
跟SPOKE1设备的配置类似，我们需要将本端IP地址指定为设备上的IP地址10.44.1.4，对端IP地址使用VPN_GW的公网IP地址124.221.107.98。注意：本端ID我们手工指定为spoke2，对端ID手工指定为vpngw，协商模式选择【Aggressive/野蛮模式】。
同样的，二阶段配置中的本端网段和对端网段正常配置就可以了。
最后，我们来配置VPN_GW到SPOKE2的IPsec连接。
需要注意一阶段配置部分，因为SPOKE2的公网IP地址不固定，所以我们用%any匹配所有IP地址。本端ID和对端ID与SPOKE2设备上的配置相对应，协商模式选择【Aggressive/野蛮模式】。
同样的，二阶段配置中的本端网段和对端网段正常配置就可以了。
因为我们是反着配置的，正常是建议先配置VPN_GW设备，再配置SPOKE2设备，这样可以自动触发IPsec协商。
但是，我们针对这个问题做了一个看门狗程序，跟DPD检测做了联动，在DPD保持启用的情况下，会以DPD的探测间隔自动触发SA协商。
这样，无论先配置IPsec连接的哪一端，都能正常自动触发IPsec SA的协商建立。
通过以上实战，我们看到，凭借三大法宝：野蛮模式、灵活的身份标识（IP/FQDN）以及自动化的连接恢复机制，我们基于strongSwan的IPsec VPN管理系统能够轻松应对各种复杂的网络环境。无论是企业分支互联、员工远程接入，还是物联网设备上线，都能找到合适的配置模型。这么智能化的管理系统，怎能叫人不喜欢呢？
你的网络环境中，还有哪些奇葩的接入场景？欢迎在评论区提出，我们一起探讨解决方案！
声明：来自铁军哥，仅代表创作者观点。链接：https://eyangzhen.com/5354.html
