选择您的 Cookie 首选项

我们使用必要 Cookie 和类似工具提供我们的网站和服务。我们使用性能 Cookie 收集匿名统计数据,以便我们可以了解客户如何使用我们的网站并进行改进。必要 Cookie 无法停用,但您可以单击“自定义”或“拒绝”来拒绝性能 Cookie。

如果您同意,AWS 和经批准的第三方还将使用 Cookie 提供有用的网站功能、记住您的首选项并显示相关内容,包括相关广告。要接受或拒绝所有非必要 Cookie,请单击“接受”或“拒绝”。要做出更详细的选择,请单击“自定义”。

App Mesh 安全故障排除

聚焦模式
App Mesh 安全故障排除 - AWS App Mesh

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

重要

终止支持通知:2026 年 9 月 30 日, AWS 将停止对的支持。 AWS App Mesh 2026 年 9 月 30 日之后,您将无法再访问 AWS App Mesh 控制台或 AWS App Mesh 资源。有关更多信息,请访问此博客文章从迁移 AWS App Mesh 到 Amazon ECS Service Connect

本主题详细介绍了您在使用 App Mesh 安全时可能遇到的常见问题。

无法通过 TLS 客户端策略连接到后端虚拟服务

症状

向虚拟节点中的虚拟服务后端添加 TLS 客户端策略时,与该后端的连接会失败。尝试向后端服务发送流量时,请求失败并显示 HTTP 503 响应代码和错误消息:upstream connect error or disconnect/reset before headers. reset reason: connection failure

解决方案

为确定问题的根本原因,我们建议使用 Envoy 代理进程日志来帮助您诊断问题。有关更多信息,请参阅 在预生产环境中启用 Envoy 调试日志记录。使用以下列表来确定连接失败的原因:

  • 排除 无法连接到虚拟服务后端 中提到的错误,确保与后端连接成功。

  • 在 Envoy 进程日志中,查找以下错误(记录在调试级别)。

    TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

    该错误可能是由以下一个或多个问题导致的:

    • 该证书未由 TLS 客户端策略信任包中定义的证书颁发机构之一签名。

    • 证书不再有效(已过期)。

    • 主题备用名称 (SAN) 与请求的 DNS 主机名不匹配。

    • 确保后端服务提供的证书有效,由您的 TLS 客户端策略信任包中的一个证书颁发机构签名,并且符合中定义的标准 传输层安全性协议 (TLS)

    • 如果您收到的错误与下面的错误类似,则表示该请求正在绕过 Envoy 代理并直接到达应用程序。发送流量时,Envoy 上的统计数据不会发生变化,这表明 Envoy 不在解密流量的路上。在虚拟节点的代理配置中,确保 AppPorts 包含应用程序正在侦听的正确值。

      upstream connect error or disconnect/reset before headers. reset reason: connection failure, transport failure reason: TLS error: 268435703:SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER

如果您的问题仍未解决,请考虑GitHub 提出问题或联系 Su AWS pport。如果您认为自己发现了安全漏洞或对 App Mesh 的安全性有疑问,请查看AWS 漏洞报告指南

当应用程序源自 TLS 时,无法连接到后端虚拟服务

症状

从应用程序而不是从 Envoy 代理发起 TLS 会话时,与后端虚拟服务的连接会失败。

解决方案

这是一个已知问题。有关更多信息,请参阅功能请求:下游应用程序和上游代理之间的 TLS 协商 GitHub 问题。在 App Mesh 中,目前支持 Envoy 代理发起 TLS,但不支持应用程序发起 TLS。要在 Envoy 上使用 TLS 发起支持,请在应用程序中禁用 TLS 起源。这样,Envoy 可读取出站请求标头,并通过 TLS 会话将请求转发到相应的目的地。有关更多信息,请参阅 传输层安全性协议 (TLS)

如果您的问题仍未解决,请考虑GitHub 提出问题或联系 Su AWS pport。如果您认为自己发现了安全漏洞或对 App Mesh 的安全性有疑问,请查看AWS 漏洞报告指南

无法断言 Envoy 代理之间的连接正在使用 TLS

症状

您的应用程序已在虚拟节点或虚拟网关侦听器上启用 TLS 终止,或者在后端 TLS 客户端策略上启用 TLS 启动,但是您无法断言 Envoy 代理之间的连接是通过 TLS 协商的会话进行的。

解决方案

本解析中定义的步骤使用了 Envoy 管理界面和 Envoy 统计信息。有关配置这些内容的帮助,请参阅 启用 Envoy 代理管理界面启用 Envoy DogStats D 集成以进行指标卸载。为简单起见,以下统计示例使用了管理界面。

  • 对于执行 TLS 终止的 Envoy 代理:

    • 使用以下命令确保已在 Envoy 配置中引导 TLS 证书。

      curl http://my-app.default.svc.cluster.local:9901/certs

      在返回的输出中,您应看到至少一个条目 certificates[].cert_chain 指定 TLS 端点。

    • 确保代理侦听器的成功入站连接数与 SSL 握手次数加上重复使用的 SSL 会话数完全相同,如以下示例命令和输出所示。

      curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep downstream_cx_total listener.0.0.0.0_15000.downstream_cx_total: 11 curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.connection_error listener.0.0.0.0_15000.ssl.connection_error: 1 curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.handshake listener.0.0.0.0_15000.ssl.handshake: 9 curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "listener.0.0.0.0_15000" | grep ssl.session_reused listener.0.0.0.0_15000.ssl.session_reused: 1 # Total CX (11) - SSL Connection Errors (1) == SSL Handshakes (9) + SSL Sessions Re-used (1)
  • 对于执行 TLS 发起的 Envoy 代理:

    • 使用以下命令确保已在 Envoy 配置中引导 TLS 信任库。

      curl http://my-app.default.svc.cluster.local:9901/certs

      您应该在 certificates[].ca_certs 下方看到至少一个条目,显示在发起 TLS 期间用于验证后端证书的证书。

    • 确保成功连接到后端集群的出站连接数与 SSL 握手次数加上重复使用的 SSL 会话数完全相同,如以下示例命令和输出所示。

      curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep upstream_cx_total cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.upstream_cx_total: 11 curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.connection_error cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.connection_error: 1 curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.handshake cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.handshake: 9 curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "virtual-node-name" | grep ssl.session_reused cluster.cds_egress_mesh-name_virtual-node-name_protocol_port.ssl.session_reused: 1 # Total CX (11) - SSL Connection Errors (1) == SSL Handshakes (9) + SSL Sessions Re-used (1)

如果您的问题仍未解决,请考虑GitHub 提出问题或联系 Su AWS pport。如果您认为自己发现了安全漏洞或对 App Mesh 的安全性有疑问,请查看AWS 漏洞报告指南

使用 Elastic Load Balancing 排除

症状

尝试配置应用程序负载均衡器或网络负载均衡器以加密虚拟节点的流量时,连接和负载均衡器运行状况检查可能会失败。

解决方案

为确定问题的根本原因,您需要检查以下内容:

  • 对于执行 TLS 终止的 Envoy 代理,您需要排除任何配置错误。然后,遵循 无法通过 TLS 客户端策略连接到后端虚拟服务 中的步骤。

  • 对于负载均衡器,您需要查看负载均衡器的配置 TargetGroup:

    • 确保该 TargetGroup 端口与虚拟节点定义的侦听器端口相匹配。

    • 对于通过 HTTP 向您的服务发起 TLS 连接的应用程序负载均衡器,请确保将 TargetGroup 协议设置为 HTTPS。如果正在使用运行状况检查,请确保将 HealthCheckProtocol 设置为 HTTPS

    • 对于通过 TCP 向您的服务发起 TLS 连接的网络负载均衡器,请确保将 TargetGroup 协议设置为 TLS。如果正在使用运行状况检查,请确保将 HealthCheckProtocol 设置为 TCP

      注意

      任何更新 TargetGroup 都需要更改 TargetGroup 名称。

正确配置后,您的负载均衡器应使用提供给 Envoy 代理的证书为您的服务提供安全连接。

如果您的问题仍未解决,请考虑GitHub 提出问题或联系 Su AWS pport。如果您认为自己发现了安全漏洞或对 App Mesh 的安全性有疑问,请查看AWS 漏洞报告指南

下一主题:

Kubernetes

上一主题:

可观察性
隐私网站条款Cookie 首选项
© 2025, Amazon Web Services, Inc. 或其附属公司。保留所有权利。