

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# App Mesh 安全性疑難排解
<a name="troubleshooting-security"></a>

**重要**  
支援終止通知：2026 年 9 月 30 日， AWS 將停止支援 AWS App Mesh。2026 年 9 月 30 日之後，您將無法再存取 AWS App Mesh 主控台或 AWS App Mesh 資源。如需詳細資訊，請參閱此部落格文章[從 遷移 AWS App Mesh 至 Amazon ECS Service Connect](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)。

本主題詳細說明您使用 App Mesh 安全性時可能遇到的常見問題。

## 無法使用 TLS 用戶端政策連線至後端虛擬服務
<a name="ts-security-tls-client-policy"></a>

**徵狀**  
將 TLS 用戶端政策新增至虛擬節點中的虛擬服務後端時，與該後端的連線會失敗。嘗試將流量傳送至後端服務時，請求會失敗，並顯示`HTTP 503`回應代碼和錯誤訊息：`upstream connect error or disconnect/reset before headers. reset reason: connection failure`。

**Resolution**  
為了判斷問題的根本原因，我們建議您使用 Envoy 代理程序日誌來協助您診斷問題。如需詳細資訊，請參閱[在生產前環境中啟用 Envoy 偵錯記錄](troubleshooting-best-practices.md#ts-bp-enable-envoy-debug-logging)。使用下列清單來判斷連線失敗的原因：
+ 透過排除 中提到的錯誤，確保後端連線成功[無法連線至虛擬服務後端](troubleshooting-connectivity.md#ts-connectivity-virtual-service-backend)。
+ 在 Envoy 程序日誌中，尋找下列錯誤 （在偵錯層級記錄）。

  ```
  TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED
  ```

  此錯誤是由下列一或多個原因所造成：
  + 憑證並未由 TLS 用戶端政策信任套件中定義的其中一個憑證授權單位簽署。
  + 憑證不再有效 （已過期）。
  + 主體別名 (SAN) 不符合請求的 DNS 主機名稱。
  + 請確定後端服務提供的憑證有效，並由 TLS 用戶端政策信任套件中的其中一個憑證授權單位簽署，且符合 中定義的條件[Transport Layer Security (TLS)](tls.md)。
  + 如果您收到的錯誤如下，則表示請求正在繞過 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 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue-bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。如果您認為您找到安全漏洞或對 App Mesh 的安全性有任何疑問，請參閱[AWS 漏洞報告準則](https://aws.amazon.com/security/vulnerability-reporting/)。

## 當應用程式產生 TLS 時，無法連線至後端虛擬服務
<a name="ts-security-originating-tls"></a>

**徵狀**  
從應用程式而非 Envoy 代理產生 TLS 工作階段時，與後端虛擬服務的連線會失敗。

**Resolution**  
這是已知問題。如需詳細資訊，請參閱[功能請求：下游應用程式與上游代理 GitHub 問題之間的 TLS 交涉](https://github.com/aws/aws-app-mesh-roadmap/issues/162)。 GitHub 在 App Mesh 中，目前支援來自 Envoy 代理的 TLS 起始，但不支援來自應用程式。若要在 Envoy 使用 TLS 起始支援，請在應用程式中停用 TLS 起始。這可讓 Envoy 讀取傳出請求標頭，並透過 TLS 工作階段將請求轉送至適當的目的地。如需詳細資訊，請參閱[Transport Layer Security (TLS)](tls.md)。

如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。如果您認為您找到安全漏洞或對 App Mesh 的安全性有任何疑問，請參閱[AWS 漏洞報告準則](https://aws.amazon.com/security/vulnerability-reporting/)。

## 無法宣告 Envoy 代理之間的連線正在使用 TLS
<a name="ts-security-tls-between-proxies"></a>

**徵狀**  
您的應用程式已在虛擬節點或虛擬閘道接聽程式上啟用 TLS 終止，或在後端 TLS 用戶端政策上啟用 TLS 起始，但您無法宣告 Envoy 代理之間的連線是透過 TLS 交涉工作階段發生。

**Resolution**  
此解析度中定義的步驟會使用 Envoy 管理界面和 Envoy 統計資料。如需設定這些項目的說明，請參閱 [啟用 Envoy 代理管理界面](troubleshooting-best-practices.md#ts-bp-enable-proxy-admin-interface)和 [為指標卸載啟用 Envoy DogStatsD 整合](troubleshooting-best-practices.md#ts-bp-enable-envoy-statsd-integration)。下列統計資料範例使用 管理界面以簡化操作。
+ 對於執行 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 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。如果您認為您找到安全漏洞或對 App Mesh 的安全性有任何疑問，請參閱[AWS 漏洞報告準則](https://aws.amazon.com/security/vulnerability-reporting/)。

## 使用 Elastic Load Balancing 對 TLS 進行故障診斷
<a name="ts-security-tls-elb"></a>

**徵狀**  
嘗試設定 Application Load Balancer 或 Network Load Balancer 來加密虛擬節點的流量時，連線和負載平衡器運作狀態檢查可能會失敗。

**Resolution**  
為了判斷問題的根本原因，您需要檢查下列項目：
+ 對於執行 TLS 終止的 Envoy 代理，您需要排除任何設定錯誤。請遵循 中上述提供的步驟[無法使用 TLS 用戶端政策連線至後端虛擬服務](#ts-security-tls-client-policy)。
+ 對於負載平衡器，您需要查看 的組態 `TargetGroup:`
  + 請確定`TargetGroup`連接埠符合虛擬節點定義的接聽程式連接埠。
  + 對於透過 HTTP 與您的服務產生 TLS 連線的 Application Load Balancer，請確定`TargetGroup`通訊協定設定為 `HTTPS`。如果正在使用運作狀態檢查，請確定 `HealthCheckProtocol` 設定為 `HTTPS`。
  + 對於透過 TCP 與您的服務產生 TLS 連線的網路負載平衡器，請確定`TargetGroup`通訊協定設定為 `TLS`。如果正在使用運作狀態檢查，請確定 `HealthCheckProtocol` 設定為 `TCP`。
**注意**  
需要`TargetGroup`變更`TargetGroup`名稱的任何更新。

正確設定後，您的負載平衡器應使用提供給 Envoy 代理的憑證，提供安全的服務連線。

如果您的問題仍未解決，請考慮開啟 [GitHub 問題](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here)或聯絡 [AWS Support](https://aws.amazon.com/premiumsupport/)。如果您認為您找到安全漏洞或對 App Mesh 的安全性有任何疑問，請參閱[AWS 漏洞報告準則](https://aws.amazon.com/security/vulnerability-reporting/)。