阿里云VPN网关常见问题与解决方法

阿里云VPN网关产品2017年5月20日正式对外公测（相关介绍可参考：link），至今已经上线半年多的时间，在这段时间内我们也收到了很多用户的问题反馈及建议，对于用户提出的建议我们们归纳整理，并且会在接下来的时间里排期改进。

在这篇文章里，我们会重点关注用户在使用过程中遇到的问题以及相应的解决方法。需要说明的是，目前的阿里云VPN网关只支持IPsec VPN功能，SSL VPN功能近期将会推出。

IPsec（Internet Protocol Security）协议是一个协议组合，包括IKE密钥交换协议以及数据流加密协议（ESP 或 AH，阿里云VPN网关使用ESP协议）， IPsec VPN“隧道”的协商过程分为两个阶段，第一个阶段是IKE SA的协商，第二阶段是IPsec SA的协商，在VPN连接控制台上即可以查看VPN连接当前的协商状态。

VPN连接参数说明：

上图是创建一条vpn连接时所需要的全部参数，下面会针对每一个参数做一下解释以及注意事项的说明。

基本参数：

• 名称：VPN连接的名称，方便区分VPN网关的不同用途，不属于协商参数。
• VPN网关：阿里云上购买的VPN网关。
• 用户网关：可以是用户线下idc内的网关或是另一个VPC内部的VPN网关。
• 本端网段：需要和用户idc互通的云上VPC内的网段，属于第二阶段协商参数。可以填写多个网段，网段之间用逗号分隔，比如192.168.1.0/24,192.168.2.0/24，但需要注意的是只有在IKE V2版本下才可以配置多网段。
• 对端网段：需要和云上VPC互通的用户idc内的网段，属于第二阶段协商参数。可以填写多个网段，网段之间用逗号分隔，比如172.10.1.0/24,172.10.2.0/24，但需要注意的是只有在IKE V2版本下才可以配置多网段。
• 是否立即生效：是否销毁当前已协商成功的隧道并重新发起协商。

第一阶段协商参数：

• 预共享密钥：用于IPsec VPN网关与用户线下idc网关之间的身份认证。默认情况下系统会帮助用户随机生成，用户也可以指定密钥，但要注意的是用户线下网关上要配置相同的密钥。
• 版本：这里的版本指的是IKE协议的版本。IKE协议目前有两个版本，分别是IKE V1和IKE V2，相对于V1版本，V2版本简化了SA的协商过程并且对于多网段的场景提供了更好的支持，所以建议用户选择IKE V2版本，但前提是线下idc的用户网关也同样支持IKE V2版本。
• 协商模式：指的是IKE V1版本的协商模式，分为主模式（main）和野蛮模式（aggressive）， 在IKE V2版本情况下协商模式没有实际意义，无需特别关注。相对于主模式，野蛮模式具有协商快速且协商成功率高的优点，但由于在协商过程中有明文传输关键信息的阶段，所以安全性不如主模式。当然协商成功之后的信息传输安全性是没有变化的。
• 加密算法：第一阶段协商所需要的加密算法。阿里云VPN网关和用户线下idc网关算法要一致。
• 认证算法：第一阶段协商所需要的认证算法。阿里云VPN网关和用户线下idc网关算法要一致。
• DH分组：Diffie-Hellman密钥交换算法。阿里云VPN网关和用户线下idc网关的DH算法要一致，有些设备上配置这个算法的命令可能叫做pfs。
• SA生存周期：第一阶段协商出的SA的生存周期。涉及到SA的过期销毁及重新协商问题，所以建议阿里云VPN网关和用户线下idc网关的SA生存周期配置一致。
• LocalId：作为阿里云VPN网关的标识，用于第一阶段的协商。默认情况下，LocalId不需要用户填写，后台会自动使用VPN网关的公网IP作为Id，但用户如果指定的LocalId为FQDN格式的，则建议将协商模式改为野蛮模式（aggressive）。
• RemoteId：作为用户线下idc中VPN网关的标识，用于第一阶段的协商。
  默认情况下，RemoteId不需要用户填写，后台会自动使用用户网关的公网IP作为Id，但用户如果指定的RemoteId为FQDN格式的，则建议将协商模式改为野蛮模式（aggressive）。

第二阶段协商参数：

• 加密算法：第一阶段协商所需要的加密算法。阿里云VPN网关和用户线下idc网关算法要一致。
• 认证算法：第一阶段协商所需要的认证算法。阿里云VPN网关和用户线下idc网关算法要一致。
• DH分组：Diffie-Hellman密钥交换算法。阿里云VPN网关和用户线下idc网关的DH算法要一致，有些设备上配置这个算法的命令可能叫做pfs。
• SA生存周期：第一阶段协商出的SA的生存周期。涉及到SA的过期销毁及重新协商问题，所以建议阿里云VPN网关和用户线下idc网关的SA生存周期配置一致。

VPN网关常见问题：

• VPN连接状态为“第一阶段协商失败”
  第一阶段协商失败可能的原因大部分都是由于阿里云VPN网关与用户线下idc内的VPN网关的第一阶段配置参数不一致有关，比如：
  1. 预共享密钥不一致。
  2. IKE协议版本不一致。
  3. 协商模式不一致。
  4. LocalId或RemoteId不一致。
  5. 加密、认证算法不一致。
  6. DH分组不一致，有些设备上需要显示的指定这个参数，否则可能默认为None。
  7. 用户线下VPN网关未开启NAT穿越。
  8. 有些极端情况下，参数完全一致也无法协商成功，这种情况下建议用户将两端的协商模式改为野蛮模式（aggressive）。
• VPN连接状态为“第二阶段协商失败”
  这个状态表明第一阶段的协商已经成功，问题出在第二阶段的协商上，一般情况下可能的原因有：
  1. 本端网段/对端网段与用户线下idc内的VPN网关配置不一致，当然有些VPN设备的配置可能是通过acl的方式来实现本端网段/对端网段的设置的，这种情况用户参考相关设备的操作手册。
  2. 加密、认证算法不一致。
  3. DH分组不一致，有些设备上需要显示的指定这个参数，否则可能默认为None。
• VPN连接状态为“第二阶段协商成功”，但云上ECS无法连通用户idc内的服务器
  这种情况一般和路由以及acl相关配置相关：
  1. 检查VPN网关所在的VPC内的虚拟路由器上的路由配置，具体的配置可以参考VPN网关的最佳实践：
     https://help.aliyun.com/document_detail/54113.html?spm=5176.doc53810.6.552.uLU3WQ
  2. 检查用户idc内的服务器上的防火墙/iptables相关的设置，重点关注是否允许云上ECS的私网网段访问进来。
  3. 云下idc的网段属于公网私用场景并且云上ECS绑定了公网ip或存在nat网关，这种情况需要用户提工单申请公网私用白名单。
• VPN连接状态为“第二阶段协商成功”，但云下idc内的服务器无法连通云上ECS
  1. 检查用户idc内的路由设置，即检查访问云上ECS的流量是否允许进入VPN隧道。
  2. 检查云上ECS的安全组设置，即检查ECS安全组规则中是否允许云下idc服务器的私网网段连入。
• VPN连接状态为“第二阶段协商成功”，但多网段场景下，一部分网段能通，部分网段不通
  1. 多网段的场景下，建议用户使用ikev2协议。
  2. 如果已经使用了ikev2协议但问题仍然存在，建议用户检查一下线下VPN网关的sa状态，正常状态应该是协商出一个SA，比如172.30.96.0/19 === 10.0.0.0/8 172.30.128.0/17，如果存在多个SA说明线下VPN网关实现的并非标准的ikev2协议，这种情况下，只能通过将多网段拆分到不通的vpn连接中解决。比如vpn连接A为172.30.96.0/19 === 10.0.0.0/8，vpn连接B为172.30.96.0/19 === 172.30.128.0/17。拆分连接后需要注意，由于连接A和连接B需要共享第一阶段SA，所以连接A和连接B的第一阶段协商参数要保持一致，比如预共享密钥、加密算法等等。