简而言之，我们试图在 GCP VPN 和 Zscaler 的 ZEN（Zscaler 执行节点）之间建立一个基于经典路由的 IPSec 隧道。到目前为止，无论使用的是 IKEv1 还是 v2 密码，我们都无法建立成功的第 2 阶段握手。在查看了从 ZEN（远程对等点）提取的 Zscaler 支持提供的日志后，我们的 GCP 云 VPN 对等点发送的通用提案似乎存在问题。根据 Zscaler 的文档；它们支持 GCP VPN 用于 IKEv1 和 v2 的所有默认设置（加密完整性、模式、哈希、DH 和生命周期），尽管它们确实在其文档中指明了优先设置。根据 Zscaler 支持的回复，他们需要单独订阅第 2 阶段 AES 加密。他们' 我们询问了我们配置 GCP 云 VPN 对等方以发送 NULL 阶段 2 提案的可能性，但是在 GCP 经典云 VPN 中没有针对这两种密码类型的特定可配置选项。有没有人遇到过 Zscaler 和 GCP 之间关于 IPSec 协商的类似情况，除了从 Zscaler 购买 Phase 2 AES 加密服务之外，您有什么建议吗？提前感谢您提供的任何建议和/或见解！除了从 Zscaler 购买 Phase 2 AES 加密服务之外，您还有什么建议吗？提前感谢您提供的任何建议和/或见解！除了从 Zscaler 购买 Phase 2 AES 加密服务之外，您还有什么建议吗？提前感谢您提供的任何建议和/或见解！
问问题
246 次
1 回答
0
再次感谢约翰的见解和帮助！我想答案一开始就在那里，我只是拒绝看到它，哈哈。这也让我理解了为什么我们使用 IKEv2 建立隧道的尝试也失败了——GCP VPN 发送他们的通用提议，目的是符合从远程对等方接收到的密码设置。在远程对等点也使用通用提议的情况下，GCP VPN 会根据远程对等点发送的硬件供应商 ID 选择“最佳匹配”。在这种情况下，Zscaler 执行节点 (ZEN) 远程对等点以未知的供应商 ID 进行响应，这可能是由于它是他们自己的专有未注册平台。如果它不包含在 GCP VPN 的已知硬件供应商 ID 列表中，
尽管如此，再次感谢您的所有帮助！
于 2020-08-05T19:50:34.270 回答