你的 Meraki MX 支持 Cisco Secure Client 吗？

两条支持帖在 Meraki 能否做 AnyConnect 这件事上互相矛盾，而双方都以同样的方式自信地错了。问题不在于 MX 是否说 IKEv2，因为设备上的 AnyConnect 是 TLS 服务，而不是 IPsec。两个彼此独立的检查决定答案，而且都不是品牌对比。按顺序做完，你得到的是一份兼容性记录，而不是一个观点。

先看型号和版本

从确切的设备及其运行的软件开始，因为该功能同时受这两者限制。Meraki 会发布一张列出受支持型号和最低固件的矩阵，而那张矩阵是唯一值得引用的权威。出现在清单里的型号并不自动处于支持该功能的版本上，而支持它的版本也可能不是你正在运行的版本。把型号和已安装固件记成两个独立事实。然后针对这一组合去读矩阵。

不要从同系列里一个相似型号去推理。清单是按型号划分的，差异是真实存在的。

AnyConnect 是 SSL 服务，不是 IPsec

Meraki 把 MX 上的 AnyConnect 描述为基于应用的 TLS 和 DTLS VPN，并将它与另一项独立的 L2TP/IPsec 客户端 VPN 服务并列记载。这是两个恰好共用一个仪表盘的产品。拿 IKEv1 和 IKEv2 相比，只能说明 IPsec 服务的情况，完全说明不了你的设备上是否存在 TLS 服务。如果你的证据是一张 IKE 版本表，那你回答的是另一个问题。

在比较客户端之前，先确认设备对外提供的是哪项服务。一条能用的 L2TP/IPsec 配置不会因为到达同一个组织就变成 AnyConnect 配置，两者需要不同的客户端配置。

MX 实际提供哪些功能

Cisco 的 ASA 功能清单不是 MX 的功能清单，一个支持十二件事的客户端并不会让网关也支持它们。比较你真正需要的功能：认证方式、分离隧道的表现、DNS 处理，以及设备要求的授权。每一项都要从 Meraki 针对已部署版本的文档里取。

通常出问题的地方就是认证。客户端提供而设备无法配置的方式，就是一个迟早要发生的支持工单。

客户端版本与授权

Cisco Secure Client 是同一客户端系列现在的名字，所以提到 AnyConnect 的文档未必过时。关键在于你的组织部署的是哪个版本，以及设备版本是否针对它做过验证。

在同一份指南里核对许可要求，而不是从别的平台去假设。然后把端点名称、证书校验和已批准的认证流程放在同一份服务记录里，因为这三者会各自独立地出问题。用户随手点过去的证书警告不是兼容性结论，而是未经验证的配置。远程接入只完成了一半，因为用户仍然需要路由和权限才能到达目的地。

用五个字段写记录

型号、固件、远程接入模式、客户端版本，以及部署所需的功能。五个字段，而“我们能不能用 AnyConnect”的答案藏在这个组合里，不在任何单独一项里。这份记录也告诉下一位工程师，固件升级后要重新核对什么。

然后端到端测试这条路径：完成认证、解析一个内部名称、到达一个被允许的资源，并确认不该到达的资源会被拒绝。登录成功但资源始终加载不出来，是一个部分结果，缺的那一半通常是路由或授权，而不是客户端。把测过的组合随变更一起归档，让下一个人继承证据而不是口号。