[info]文本整体是摘录于《使用 Strongswan 架设 Ipsec VPN》
地址：http://blog.csdn.net/zzsfqiuyigui/article/details/39533479[/info]

在架设基于strongSwan的过程中遇到了很多麻烦事，于是就Google到了上文。
这一段让我倍感抓心挠肝。（以下对原文进行了删节。）

Linux
如果命令行客户端使用 strongswan 本身，则没有问题，支持 ikev1/ikev2 和所有加密方法的连接。

但 Linux 的图形界面客户端 NetworkManager-strongswan 目前只支持 ikev2 连接，必须使用证书或 EAP （各种加密方法都支持，包括微软的 MSCHAPv2）进行认证，不支持纯密码（PSK）认证。这并不是 strongswan 的错误，或者技术不行（开源总是走在技术最前沿的，毕竟命令行是支持的），而仅仅是体现一种选择：ikev1 被 strongswan 项目认为是该淘汰的协议，而 PSK 加密被认为是非常不安全的。参考 strongswan 维基 NetworkManager 词条。

Android
Android 和 Linux 不一样，只支持 ikev1。其它方面和 Linux 一样，甚至有好多种 IPsec VPN 配置模式可供选择。

iOS/Mac OS X
它们声明使用的 IPsec 客户端为 Cisco，实际为自己修改的 racoon。它只支持 ike 协议的第一版即 ikev1，可以使用证书或纯密码（PSK）认证，但必须辅之 xauth 用户名/密码认证。

该修改版的 racoon 会优先使用不加密的积极模式，而积极模式是 strongSwan 所不支持的。所以要使用主力模式。

iOS 6 还有一个「衔尾」故障：它在第一阶段握手时会把数据包拆分成小块（fragmentation），然后「加密」发送。然而这种加密仅仅是声明的，其实并未加密，这就导致 strongSwan 及其它标准服务器端/Cisco 设备无法解密。另外 ikev1 的 fragmentation 插件是闭源的。开源服务器端无法对这些小块进行重组。参考：Cisco VPN stop working after upgrading to IOS 6

所以产生了一种权宜之计，就是使用小证书（小于 1024，默认一般为 2048）,来达到不拆包的目的。但是 Mac OS X 10.7 的更新却对这种方式进行了封杀，学习微软加入了证书验证，小证书直接拒绝。

所幸 strongswan 5.0.2 已经完成了 fragmentation 的开源实现和对 iOS 那个声明加密其实未加密故障的处理：IKE message fragmentation (cisco) + IOS 6.0 Hack for encrypted flaged ike fragmentation packets，该链接中也能找到 strongswan 4 的补丁。

Windows
微软的差劲只比 iOS 好一点。好处在于它支持了 ikev2，但是只在 Windows 7 以后支持，Vista 之前依然使用 ikev1。

坏处在于它的 ikev2 支持非常诡异，指定了 Diffie Hellman group（DH，迪菲－赫尔曼密钥交换组）必须是 modp1024。这是非常少见理论上不应该由系统管理员操心的加密选项：

在 strongswan 中，定义第一阶段（ike）和第二阶段（esp）加密方法的语法是：

ike/esp=encryption-integrity[-dhgroup][-esnmode]
第一阶段/第二阶段=加密方法-健壮性认证方法 （后面两项可选）[-DH 组] [-扩展序列号支持模式（RFC4304）]

参考：IKEv2CipherSuites

Windows 定义了一个可选的选项，导致了我们必须去定义整个第一阶段的加密方法。这样被破解的可能性就提高了。

其次在于它的 rekey（重连）。IPsec 的认证是有时效的，超过时间会重新认证。这种 CHILD_SA 认证可由服务器发出，也可由客户端发出，一般是由服务器发出。但是 Windows 7 的 ikev2 的表现是，如果你在路由器（NAT）后，收到这种请求会把微软内部的通知代码发出去，代码为 12345, 经过 strongswan 项目侦错后发现这个代码的意思是 ERROR_IPSEC_IKE_INVALID_SITUATION。但是处理不了，它不是 IPsec 标准协议定义过的错误。

于是有两种权宜之计：

一种是让 Windows 7 来主动 rekey。Windows 7 rekey 的时间大约是 58 分 46 秒，所以要配置服务器 rekey 时间比它长。但是效果非常不好。因为 rekey 是由三个变量控制的，key 的生命周期，key 的边际时间（生命周期前多久进行 rekey），和边际时间误差（rekeyfuzz），误差是不可控的。参考：ExpiryRekey。

即使能控制 strongswan 这边，Windows 依然是「大约」; 即使两边都能控制，假设服务器延后一秒 rekey，理论上如果连接持续时间足够长，依然能够撞车：58×60+46 次 rekey 后即 146 天后撞车，连一年都没有，在 Linux 服务器对 Windows 服务器这种使用实例中就明显不符合要求。

所以目前只能使用后一种方法即完全禁用服务器端 rekey。

最后，它的 EAP 认证也非常糟糕。MSCHAPv2 的 eap 身份不是 ikev2 身份（ikev2 身份一般是 EAP 用户名），所以必须在服务器端显式定义 eap_identity 来使用 Windows 7 的 eap 身份。

所以截止目前，我的VPN就只支持IOS的IPSEC与Android的strongSwan VPN Client。
暂时没有精力折腾别的了……