As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Solução de problemas de segurança do App Mesh
**Importante**
Aviso de fim do suporte: em 30 de setembro de 2026, AWS o suporte para o. AWS App Mesh Depois de 30 de setembro de 2026, você não poderá mais acessar o AWS App Mesh console ou os AWS App Mesh recursos. Para obter mais informações, visite esta postagem no blog [Migrando do AWS App Mesh Amazon ECS Service Connect.](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)
Este tópico detalha problemas comuns que podem ser enfrentados com a segurança do App Mesh.
## Não é possível se conectar a um serviço virtual de back-end com uma política de cliente TLS
**Sintomas**
Ao adicionar uma política de cliente TLS a um back-end de serviço virtual em um nó virtual, a conectividade com esse back-end falha. Ao tentar enviar tráfego para o serviço de back-end, as solicitações falham com um código de resposta `HTTP 503` e a mensagem de erro: `upstream connect error or disconnect/reset before headers. reset reason: connection failure`.
**Resolução**
Para determinar a causa raiz do problema, recomendamos usar os logs do processo de proxy do Envoy para ajudar a diagnosticar o problema. Para obter mais informações, consulte [Ativar o registro em log de depuração do Envoy em ambientes de pré-produção](troubleshooting-best-practices.md#ts-bp-enable-envoy-debug-logging). Use a lista a seguir para determinar a causa da falha de conexão:
+ Certifique-se de que a conectividade com o back-end seja bem-sucedida, descartando os erros mencionados em [Não é possível conectar-se a um back-end de serviço virtual](troubleshooting-connectivity.md#ts-connectivity-virtual-service-backend).
+ Nos logs do processo do Envoy, procure os seguintes erros (logados no nível de depuração).
```
TLS error: 268435581:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED
```
Esse erro é causado por um ou mais dos motivos a seguir:
+ O certificado não foi assinado por uma das autoridades de certificação definidas no pacote de confiança da política do cliente TLS.
+ O certificado não é mais válido (expirou).
+ O nome alternativo do assunto (SAN) não corresponde ao nome de host DNS solicitado.
+ Certifique-se de que o certificado oferecido pelo serviço de back-end seja válido, assinado por uma das autoridades de certificação em seu pacote confiável de políticas de cliente TLS e atenda aos critérios definidos em [Transport Layer Security (TLS)](tls.md).
+ Se o erro recebido for como o abaixo, isso significa que a solicitação está ignorando o proxy do Envoy e acessando diretamente a aplicação. Ao enviar tráfego, as estatísticas no Envoy não mudam, indicando que o Envoy não está no caminho certo para decifrar o tráfego. Na configuração de proxy do nó virtual, verifique se as `AppPorts` contêm o valor correto que o aplicativo está receptando.
```
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
```
Se o problema ainda não tiver sido resolvido, considere abrir um [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue-bug-report.md&title=Bug%3A+describe+bug+here) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/). Se acredita ter encontrado uma vulnerabilidade de segurança ou se tiver dúvidas sobre a segurança do App Mesh, consulte as [diretrizes do relatório de vulnerabilidade da AWS](https://aws.amazon.com/security/vulnerability-reporting/).
## Não é possível se conectar a um serviço virtual de back-end quando a aplicação está originando o TLS
**Sintomas**
Ao originar uma sessão TLS de uma aplicação, em vez do proxy Envoy, a conectividade com um serviço virtual de back-end falha.
**Resolução**
Esse é um problema conhecido. Para obter mais informações, consulte a [Solicitação de recurso: negociação de TLS entre o aplicativo downstream e o problema do proxy upstream](https://github.com/aws/aws-app-mesh-roadmap/issues/162). GitHub No App Mesh, o TLS de origem atualmente é compatível com o proxy Envoy, mas não pela aplicação. Para usar o suporte ao TLS de origem no Envoy, desative o TLS de origem no aplicativo. Isso permite que o Envoy leia os cabeçalhos da solicitação de saída e encaminhe a solicitação para o destino apropriado por meio de uma sessão TLS. Para obter mais informações, consulte [Transport Layer Security (TLS)](tls.md).
Se o problema ainda não tiver sido resolvido, considere abrir um [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/). Se acredita ter encontrado uma vulnerabilidade de segurança ou se tiver dúvidas sobre a segurança do App Mesh, consulte as [diretrizes do relatório de vulnerabilidade da AWS](https://aws.amazon.com/security/vulnerability-reporting/).
## Não é possível afirmar que a conectividade entre os proxies do Envoy está usando o TLS
**Sintomas**
Sua aplicação habilitou o encerramento do TLS no nó virtual ou no receptor do gateway virtual, ou o TLS de origem na política de cliente TLS de back-end, mas você não consegue afirmar que a conectividade entre os proxies do Envoy está ocorrendo em uma sessão negociada por TLS.
**Resolução**
As etapas definidas nesta resolução usam a interface de administração do Envoy e as estatísticas do Envoy. Para obter ajuda para configurá-los, consulte [Ativar a interface de administração do proxy Envoy](troubleshooting-best-practices.md#ts-bp-enable-proxy-admin-interface) e [Habilite a integração do Envoy DogStats D para descarga métrica](troubleshooting-best-practices.md#ts-bp-enable-envoy-statsd-integration). Os exemplos de estatísticas a seguir usam a interface de administração para simplificar.
+ Para o proxy Envoy executando o encerramento do TLS:
+ Certifique-se de que o certificado TLS tenha sido inicializado na configuração do Envoy com o comando a seguir.
```
curl http://my-app.default.svc.cluster.local:9901/certs
```
Na saída retornada, é possível visualizar pelo menos uma entrada em `certificates[].cert_chain` para o certificado usado no encerramento do TLS.
+ Certifique-se de que o número de conexões de entrada bem-sucedidas com o receptor do proxy seja exatamente o mesmo que o número de handshakes SSL mais o número de sessões SSL reutilizadas, conforme mostrado nos comandos e na saída do exemplo a seguir.
```
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)
```
+ Para o proxy Envoy que executa o TLS de origem:
+ Certifique-se de que o armazenamento confiável do TLS tenha sido inicializado na configuração do Envoy com o comando a seguir.
```
curl http://my-app.default.svc.cluster.local:9901/certs
```
Deve ser visualizada pelo menos uma entrada abaixo `certificates[].ca_certs` para os certificados usados na validação do certificado do back-end durante o TLS de origem.
+ Certifique-se de que o número de conexões de saída bem-sucedidas com o cluster de back-end seja exatamente o mesmo que o número de handshakes SSL mais o número de sessões SSL reutilizadas, conforme mostrado nos seguintes exemplos de comandos e resultados.
```
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)
```
Se o problema ainda não tiver sido resolvido, considere abrir um [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/). Se acredita ter encontrado uma vulnerabilidade de segurança ou se tiver dúvidas sobre a segurança do App Mesh, consulte as [diretrizes do relatório de vulnerabilidade da AWS](https://aws.amazon.com/security/vulnerability-reporting/).
## Solução de problemas do TLS com o Elastic Load Balancing
**Sintomas**
Ao tentar configurar um Application Load Balancer ou Network Load Balancer para criptografar o tráfego em um nó virtual, as verificações de integridade e conectividade do balanceador de carga podem falhar.
**Resolução**
Para determinar a causa raiz do problema, é preciso verificar o seguinte:
+ Para que o proxy Envoy execute o encerramento do TLS, é preciso descartar qualquer configuração incorreta. Siga as etapas fornecidas acima no [Não é possível se conectar a um serviço virtual de back-end com uma política de cliente TLS](#ts-security-tls-client-policy).
+ Para o balanceador de carga, é preciso examinar a configuração do `TargetGroup:`
+ Certifique-se de que a `TargetGroup` porta corresponda à porta do receptor definida pelo nó virtual.
+ Para Application Load Balancers que estão originando conexões TLS via HTTP para seu serviço, verifique se o protocolo `TargetGroup` está definido como `HTTPS`. Se as verificações de integridade estiverem sendo utilizadas, verifique se a `HealthCheckProtocol` está definida como `HTTPS`.
+ Para Network Load Balancers que estão originando conexões TLS via TCP para seu serviço, verifique se o protocolo `TargetGroup` está definido como `TLS`. Se as verificações de integridade estiverem sendo utilizadas, verifique se a `HealthCheckProtocol` está definida como `TCP`.
**nota**
Qualquer atualização do `TargetGroup` exige a alteração do nome do `TargetGroup`.
Com essa configuração correta, seu balanceador de carga deve fornecer uma conexão segura ao seu serviço usando o certificado fornecido ao proxy Envoy.
Se o problema ainda não tiver sido resolvido, considere abrir um [GitHub problema](https://github.com/aws/aws-app-mesh-roadmap/issues/new?assignees=&labels=Bug&template=issue--bug-report.md&title=Bug%3A+describe+bug+here) ou entre em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/). Se acredita ter encontrado uma vulnerabilidade de segurança ou se tiver dúvidas sobre a segurança do App Mesh, consulte as [diretrizes do relatório de vulnerabilidade da AWS](https://aws.amazon.com/security/vulnerability-reporting/).