IPsec站点连接故障排除

概览

对于使用IPsec连接至Cato云进行WAN访问的网络，连接性至关重要。 IPsec站点的连接中断会扰乱业务功能。 本手册旨在指导该情境下的故障排除。

症状

可以通过以下方式确定IPsec连接失败。 管理员可能会注意到以下症状：

• IPsec站点在CMA中已断开连接 
  
• 连接不稳定的历史记录
• 穿过IPsec连接的流量性能不佳

可能原因

以下是故障排除时可以识别的可能原因。

• 对等连接性
  • 这包括对等方相互之间通过L3底层网络的稳定连接能力。
• IPsec配置不匹配
  • 变换集合或身份验证不匹配可能导致隧道无法形成，或在重新密钥完成前失败
• 底层网络性能
  • IPsec依赖于稳定的底层网络连接，以确保隧道内令人满意的性能。

问题故障排除

管理员可能遇到症状的故障排除步骤如下所列。 这些步骤旨在识别所面临问题的可能原因。 解决步骤将在本手册后续部分中强调。

在CMA中故障排除已断开或不稳定的IPSec站点

从事件中收集信息

使用CMA中的主页 > 事件页面，管理员可以快速获取账户中IPsec站点的连接事件历史。 可以通过选择“站点连接状态”预设或过滤事件类型“连接”和子类型“已断开”来过滤相关事件。 还可以使用“源站点”字段过滤目标站点的名称，也可以使用隧道协议值“IPSEC”过滤所有IPsec站点。

查看从相关站点中断的事件时间戳可以帮助集中调查方向。 在此时间戳中是否已知发生过更广泛的网络事件或当地电力事件？ 在这之前是否有任何审计追踪更改可能相关？

如果未找到断开事件且隧道仍然报告不稳定，可能是由于Cato和远程对等方之间的参数不匹配导致问题出现在重新密钥过程时。 继续以下步骤以进一步分析。

查看站点IPsec连接历史

网络 > 站点 > 站点配置 > IPsec 中的时间线对故障排除已断开连接的IPsec站点至关重要。

重要：如果该文件在CMA中不可用（未找到文件），则意味着Phase1（或IKE_SA在IKEv2中）尚未与远程对等协商。 确认两对等方之间的IKE和认证参数匹配。

时间线按钮提供的CSV文件将显示相关隧道日志的历史。 这些日志可以提供导致IPsec连接缺乏连接性的明确问题指示。 以下是常见的指示性信息示例：

信息表明流量选择器不匹配是配置不匹配的证据，尤其涉及到每一侧IPsec对等可用的子网。 如果您看到错误提示这是情况，请导航到解决IPsec配置不匹配。

上述信息也表明配置不匹配，这次与认证负载有关。 当然，为使连接成功，预共享密钥（PSK）需与这些负载匹配。 如果这些在任何连接尝试中明显，请导航到解决IPsec配置不匹配。

以上时间线显示了尝试与配置对等方连接，但未收到响应。 在该时间线中可以看到，无对等方交互发生，且由于不活动，SA被关闭。 这通常是由于缺乏L3可达性到远程对等。在这种情况下，请查看解决对等连接。 在这些情况下，请查看解决对等连接性。

可以在这里找到IKEv1和IKEv2可能时间线错误信息的完整列表。

使用数据包捕获进行故障排除

注意：在进行数据包捕获时，您为隧道配置的PoP IP将隐藏在10.x.y.z内部IP之后。

网络 > 站点 > 站点配置 > IPsec 页面中也有数据包捕获工具。 这将有助于提供对等方之间控制流量的数据包跟踪。 以上突出的问题也在这些数据包捕获中有所体现：

在变换集合中不匹配的子网，信息包将提示错误。 在本IKEv2示例中，信息性提示TS_UNACCEPTABLE表征了在变换集合中配置不匹配的症状。

在安全联合中参数不匹配时，任一对等方将在负载中包含错误。 在本IKEv2示例中，错误NO-PROPOSAL-CHOSEN清晰表明CMA中配置的算法或DH组与远程对等的配置不匹配。 这可能在隧道初始建立或重新密钥过程中发生。

在数据包捕获中还呈现了其他类型的配置不匹配。 例如，下面的捕获显示了另一个IKEv2示例，这次是认证使用的预共享密钥不匹配的情况：

在IKEv1或IKEv2中，对等之间任何上述实例或其他配置不匹配指示，请导航到解决IPsec配置不匹配。

数据包捕获也能识别IP级别上与对等方的连接性问题。 在下例中，数据包捕获仅显示单向的外发流量，提示对等方不可达。 如果故障排除的管理员看到不可达对等，请导航到解决对等连接。

故障排除VPN上的性能不佳

如果在VPN上性能不佳，通常表现为数据包丢失、高延迟或频繁断开。

通过隧道传输的流量将会出现数据包丢失，影响到相关应用程序，并可以通过从一台主机到另一台主机通过IPsec连接进行ICMP探测测试来确认。

延迟和隧道断开也将在应用程序性能中显现，并且可以通过网络 > 站点监控 > 网络分析页面进行判断。

如果发现性能问题，请导航至解决底层性能。

Azure IPSec中的数据包丢弃

在与Azure配置IPSec时，隧道吞吐量和每秒数据包数(PPS)由VPN网关的SKU和所使用的加密算法来决定。 例如，根据Microsoft的文档，使用GCMAES256时，VpnGw3 Generation2网关可以处理最高140,000个每秒数据包数(PPS)。

如果流量超过这些阈值，Azure将自动丢弃多余的数据包，可能导致明显的性能下降。 常见症状之一是吞吐量下降，这在CMA的网络分析中可能表现为流量量的降低。 然而，更精确的方法是直接在Azure门户中监视VPN网关的指标，这提供了隧道吞吐量和PPS值的实时洞察，从而诊断问题。

为减轻此问题，可考虑升级至更高IPSec SKU或部署Azure vSocket，两者均能增强您的VPN隧道容量，防止因流量过载导致的数据包丢弃。

解决已发现的问题

解决对等连接性

对于IPsec对等体未向PoP发送数据包的情景，通过时间线条目或数据包捕获显示，请确保远程对等体配置为连接到CMA分配的与隧道相同的IP地址。

如果已确认此配置，请确保远程对等体能够通过在端口4500和500上响应流量来跨越NAT限制的连接。 应在远程对等体上启用NAT-T(NAT穿越)。

如果远程对等设备配置为通过互联网响应ICMP请求，您也可以通过对设备的公网IP进行ICMP请求测试来检验其一般的可达性。

检查最近状态页面健康状况的变更 - 如果PoP遇到问题，这可能会影响IPsec隧道（每个隧道连接到一个Cato PoP位置）。 您可以在状态页面上监控Cato PoP健康状况。

如果远程对等体是Azure或AWS等云供应商，您还可以查看他们的状态页面。

如果对等设备在此IPsec连接中仍然不可达，请联系管理员以确保其对IPsec连接公开可访问。

解决IPsec配置不匹配

确保对等体的变换集的配置与站点> IPsec 页面中配置的相匹配。

要配置Cato对等体以匹配对等体的特定变换集，请根据IKEv1和IKEv2的链接文档中所述进行编辑配置。

隧道两端的所包括的子网也必须匹配，请确保这一点。 一些供应商要求所有包含在变换集中的子网仅包含在单个变换集消息中。 如果对等体是这种情况，管理员应在站点>高级配置下利用高级配置选项'IKEv2 每个有效负载发送单个TS'。 

解决底层性能

解决底层性能的重点是隔离与远程对等体的性能。

测试远程对等体ping公共web服务器8.8.8.8的能力。 如果延迟或数据包丢失与隧道一致，可以得出问题存在于远程对等体环境中的结论。

将案例提交给Cato支持

提交支持工单，并附上上述排错步骤的结果。 请在工单中包含以下信息：

• 相关的时间线条目及时间戳
• 相关的数据包捕获
• 确认匹配的变换集，包括子网关联和认证/加密参数