对非 Meraki 站点到站点 VPN 对等点进行故障排除
To view this article in English, click here.
MX 安全设备提供配置与非 Meraki 设备的连晋的 VPN 隧道配置的功能。本文介绍非 Meraki VPN 的注意事项、所需配置设置,以及如何对 MX 到非 Meraki VPN 的连接进行故障排除。
有关对 Meraki 到 Meraki VPN 进行故障排除的信息,请参考站点到站点 VPN 故障排除。
思科 Meraki VPN 设置和要求
请参阅以下知识库文章,其中概述了 VPN 概念:IPSec 和 IKE
思科 Meraki 设备对其到非 Meraki 对等点的 VPN 连接有以下要求:
- 预共享密钥(无证书)。
- 局域网静态路由(没有 VPN 接口路由协议)。
- 主模式(不支持攻击性模式)下的 IKEv1(不支持 IKEv2)。
- 通过 UDP 端口 500 和 4500 接入。
以下 IKE 和 Ipsec 参数是 MX 使用的默认设置:
-
第 1 阶段(IKE 策略):3DES、SHA1、DH 组 2、有效期 8 小时(28800 秒)。
-
第 2 阶段(IPsec 规则):任意 3DES、DES 或 AES 任意;MD5 或 SHA1;已禁用 PFS;有效期 8 小时(28800 秒)。
建议尽可能将这些设置保留为默认设置。如果远程对等点需要,可以通过实施自定义 Ipsec 策略更改这些参数。
注意:非 Meraki VPN 对等点是组织范围的对等点,因此,将针对组织中的所有此类 MX 设备配置对等点。如果您希望多个 MX 连接到同一个第三方 VPN 对等点,它们将有相同的共享密钥。
使用主互联网上行链路建立非 Meraki VPN 连接。如果主上行链路发生故障,VPN 连接将使用辅助互联网上行链路。请记住,如果发生故障转移,第三方对等点将需要辅助上行链路 IP 地址的相应配置。您可以在配置 > 流量整形 > 上行链路配置下找到主上行链路设置。
为了在不同组织的两个 MX 设备之间建立 VPN,必须使用非 Meraki VPN 对等点连接。请参阅我们的文档,了解更多信息。
使用事件日志进行故障排除
您可以从监控 > 事件日志中查看事件日志。取消选中除 VPN 外的所有事件日志类型,然后点击“搜索”按钮。同时,如果您需要了解问题发生的特定事件,还可以定义特定的时间范围来缩小结果范围。
以下日志条目显示 MX (IP: 1.1.1.1) 和非 Meraki VPN 设备 (IP:2.2.2.2) 之间成功的 VPN 连接:
Jan 1 06:50:05 VPN msg: IPsec-SA established: ESP/Tunnel 1.1.1.1[4500]->2.2.2.2[4500] spi=122738512(0x750d750) Jan 1 06:50:04 VPN msg: initiate new phase 2 negotiation: 1.1.1.1[4500]<=>2.2.2.2[4500] Jan 1 06:50:04 VPN msg: ISAKMP-SA established 1.1.1.1[4500]-2.2.2.2[4500] spi:91f7c94b98a41ce8:85abf36d937b096f Jan 1 06:50:03 VPN msg: initiate new phase 1 negotiation: 1.1.1.1[500]<=>2.2.2.2[500]
查看事件日志,找到表示第 1 阶段或第 2 阶段协商过程中发生故障的条目。以下是第 1 阶段故障日志条目示例:
May 8 07:23:53 VPN msg: failed to get valid proposal. May 8 07:23:53 VPN msg: no suitable proposal found. May 8 07:23:43 VPN msg: phase1 negotiation failed.
事件日志:“未接受收所选的任何建议”(第 1 阶段)
错误说明:无法建立第 1 阶段。此事件日志显示控制面板的事件日志中记录了以下错误“信息交换中未接收受所选的任何建议”
错误解决方案:此错误一般是由于两个 VPN 设备之间配置不匹配引起的。下面列出的步骤将有助于您对此问题进行故障排除。
- 验证第 1 阶段参数匹配
- 验证预共享密钥相同。
- 检查每端能否都可连接隧道中介绍所述的对等点地址。
- 验证是否在出站接口上启用了 ISAKMP
事件日志:“未接受所选的任何建议”(第 2 阶段)
事件日志:“未接收所选的任何建议”(第 2 阶段)
错误说明:无法建立隧道,并且事件日志显示第 1 阶段协商成功,但是在第 2 阶段初始阶段之后记录了以下错误消息:“信息交换中未接受收所选的任何建议”。
错误解决方案:这可能是由于第 2 阶段安全关联不匹配引起的。请验证第三方 VPN 对等点是否共享相同的第 2 阶段参数,以及是否满足以下要求:
- 有效期:基于时间的有效期(不使用基于数据的有效期)
- IKE 版本:v1(不支持 IKEv2)
事件日志:“无法预处理 ph2 数据包/无法获取 sainfo”
错误说明:无法建立隧道,并且控制面板的事件日志中记录了以下错误“消息:无法预处理 ph2 数据包(端:1,状态:1),消息:无法获取 sainfo。” ”
错误解决方案:这可能是由于 Ipsec 隧道定义中的子网不匹配(一般是子网掩码不匹配)引起的。请进行检查,确保 VPN 隧道的每端上的本地和远程子网匹配。
注意:当尝试使用 Microsoft Azure 建立 VPN 隧道时,会遇到此错误。有关更多信息,请参阅本文中有关 Microsoft Azure 故障排除的说明。
事件日志:“0x08 标志无效”
错误说明:MX 仅使用 IKEv1 支持站点到站点 VPN。如果远程终端上配置有 IKEv2,会在事件日志中看到“0x08 标志无效”消息。
错误解决方案:将远程终端从使用 IKE v2 切换到使用 v1。
事件日志:“任何适用的 rmconf 中都不允许交换攻击性模式”
错误说明:MX 仅支持第 1 阶段协商的主模式。如果配置非 Meraki 对等点攻击性模式,就会在事件日志中看到此错误,表示无法建立隧道。
错误解决方案:更改远程对等点的配置以便在第 1 阶段使用主模式。
事件日志:“任何适用的 rmconf 中都不允许交换身份保护”
错误说明:一个或多个对等点没有有效的第 1 阶段配置,导致对等点之间不匹配。如果配置远程对等点使用攻击性模式 ISAKMP(不受 MX 支持),或者 MX 从控制面板中未配置的第三方对等点接收 ISAKMP 流量,也会出现此错误。
错误解决方案:确保两个对等点的第 1 阶段配置匹配,并且远程对等点配置为主模式。作为跟进步骤,在 MX 的主网络接口上执行,并按 IP 地址和“isakmp”进行过滤,以确保两个对等点可以通信。另请检查 IP 地址并确保它是已经添加到控制面板中的有效对等点。
事件日志:“第 1 阶段协商由于超时失败”
错误说明:针对我们尚未建立隧道的非 Meraki VPN 对等点生成了 VPN 对等点绑定流量。在尝试开始第 1 阶段协商以建立隧道时,我们未收到远程端的响应。
错误解决方案:使用一些简单测试(例如 ping)查看两个站点之间的丢包情况。执行数据包捕获,验证 ISAKMP 流量是由本地对等点发送的。如果收到 ISAKMP 流量后,远程端没有响应,请验证远程端的配置是否是使用本地对等点建立隧道。
一些主机可以通过隧道通信,其他主机不行
错误说明:已成功建立隧道;但是一些主机无法通过隧道通信。
错误解决方案:如果某些主机通过 VPN 隧道发送流量存在问题,并且其他主机无法通信,很有可能是因为此客户端系统的数据包没有路由到 MX。客户端系统的网关不正确,或者子网掩码不正确。
隧道在一段时间后定期断开
错误说明:已成功建立隧道并且可以传输流量,但一定时间之后,隧道断开。
错误解决方案:如果 MX 和远程对等点之间的第 2 阶段有效期不匹配,则在较低的第 2 阶段有效期过期之前,隧道将建立并且正常工作。请确保两个对等点上设置的第 2 阶段有效期相同(MX 默认值为 28800 秒,并且 MX 不支持基于数据库的有效期)。
结论和供应商特定示例
事件日志可用于确定是否成功建立非 Meraki VPN 连接,故障条目有助于快速识别设备之间的哪些设置有可能不匹配。在确保设备之间的设置匹配后,成功协商消息表示已成功建立 VPN 隧道。请参考以下链接,了解供应商特定配置示例:
- 思科 ASA
-
- 注意:我们建议运行 ASA 8.3 或更高版本,因为运行早期版本有可能导致隧道过早断开。
- Netgear Prosafe
- Watchguard XTM
- Sonicwall
Microsoft Azure 故障排除
思科 Meraki 设备和 Microsoft Azure 之间最常见的一个站点到站点 VPN 问题是由于本地/远程子网不匹配引起的,如上述内容所述。
在 Microsoft Azure上完成 VPN 配置后,请查看为遍历 VPN 隧道指定的地址空间。这一般包括超网(汇总地址)及其各个子网。例如,当通告网络 192.168.10.0/24 和 192.168.20.0/24 时,超网将为 192.168.0.0/19。
在控制面板内,请务必在“非 Meraki 对等点 - 专用子网”字段内添加 Microsoft Azure 网络的超网(在我们的示例中为 192.168.0.0/19)而非各个子网。如果忽视这一点,就会由于子网不匹配导致无法建立 VPN 隧道。