503 Serviço indisponível - Falha na criação do túnel do proxy com 403

Você está lendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. info

Sintoma

O aplicativo cliente recebe um código de status HTTP de 503 Service Unavailable com o código de erro protocol.http.ProxyTunnelCreationFailed como resposta para chamadas de API.

Mensagem de erro

O aplicativo cliente recebe o seguinte código de resposta:

HTTP/1.1 503 Service Unavailable

Além disso, você pode observar a seguinte mensagem de erro:

{
   "fault":{
      "faultstring":"Proxy refused to create tunnel with response status 403",
      "detail":{
         "errorcode":"protocol.http.ProxyTunnelCreationFailed"
      }
   }
}

Proxy de encaminhamento e tunelamento

O Apigee Edge permite que os proxies de API se comuniquem com o servidor de back-end por meio de um servidor proxy, conforme explicado em Configurar proxy de encaminhamento. O servidor proxy abre uma conexão segura (HTTPS) ou não segura (HTTP) com o servidor de back-end, dependendo do tipo de proxy (indicado pela propriedade HTTPClient.proxy.type) usado e transfere os dados nas duas direções. Isso é conhecido como tunelamento.

Por padrão, o Apigee Edge usa tunelamento para todo o tráfego. Para desativar o tunelamento, a propriedade HTTPClient.use.tunneling precisa ser definida como false.

Código de erro: protocol.http.ProxyTunnelCreationFailed

O Apigee Edge retorna o código de erro protocol.http.ProxyTunnelCreationFailed se o servidor proxy não conseguir criar um túnel entre o Apigee Edge e o servidor de back-end devido a problemas como firewall, restrições de ACL (lista de controle de acesso), problemas de DNS, indisponibilidade do servidor de back-end, tempos limite etc.

O código de status no faultstring da resposta do Apigee Edge normalmente indica uma possível causa de alto nível que levou a esse erro.

Modelo de faultstring:

Proxy refused to create tunnel with response status STATUS_CODE

Possíveis causas de alguns dos códigos de status observados na faultstring:

A tabela a seguir descreve as possíveis causas, dependendo do código de status indicado na faultstring:

Dependendo do código de status observado na faultstring, é necessário usar técnicas adequadas para resolver o problema. Este manual explica como resolver o problema se você observar o código de status 403 na faultstring para o código de erro protocol.http.ProxyTunnelCreationFailed.

Causas possíveis

Esse erro (código de status 403) ocorre se houver restrições de firewall ou ACL (lista de controle de acesso) configuradas no servidor de back-end que impedem a criação do túnel entre o Apigee Edge e o servidor de back-end pelo servidor proxy.

Etapas comuns do diagnóstico

Use uma das seguintes ferramentas/técnicas para diagnosticar esse erro:

Causa: o proxy se recusou a criar um túnel com o status de resposta 403

Diagnóstico

1. Determine o código de falha e a origem da falha para 503 Service Unavailable usando a ferramenta Trace ou os registros de acesso do NGINX, conforme explicado em Etapas comuns do diagnóstico.
2. Analise a mensagem de erro e determine o código de status indicado na faultstring para falha na criação do túnel.
3. Nesse cenário, o código de status é 403, o que significa Proibido.
4. Isso significa que não há direitos ou privilégios suficientes para criar o túnel. Isso pode acontecer normalmente se houver restrições de firewall ou ACL (lista de controle de acesso) que impeçam a criação do túnel.
5. Analise as restrições de firewall e/ou ACL configuradas no servidor de back-end que podem impedir a criação do túnel.
6. Dependendo do tipo de restrições de firewall e/ou ACL, é necessário corrigir o problema de maneira adequada.

7. Vamos usar um exemplo de restrição de firewall para explicar como solucionar e resolver esse problema:

   Cenário: a restrição de firewall no servidor de back-end espera que o cabeçalho do host sempre contenha o nome do host do servidor de back-end

   Você pode usar uma das seguintes maneiras para determinar o cabeçalho do host transmitido pelo Apigee Edge:

   Trace

   Para determinar o cabeçalho do host usando o Trace:

   1. Verifique se o faultstring contém Proxy refused to create tunnel with response status 403 usando o trace, conforme explicado em Etapas comuns do diagnóstico.
   2. Navegue até a fase Fluxo de solicitação de destino iniciado e analise os cabeçalhos de solicitação
   3. Verifique o valor do nome do host especificado no cabeçalho do host na seção Cabeçalhos de solicitação.
   4. Se o cabeçalho Host contiver o nome do host do proxy, essa será a causa do erro.
   5. Isso ocorre porque o firewall está configurado no servidor de back-end para aceitar as solicitações somente se o cabeçalho do host contiver o nome do servidor de back-end.
   6. Assim, quando o servidor proxy tenta criar o túnel com o servidor de back-end, ele falha com o erro

      Proxy refused to create tunnel with response status 403.

      Exemplo de trace mostrando o cabeçalho do host com o nome do host do proxy

      ( ver imagem maior)

      

      No exemplo de trace mostrado acima, mostra que o cabeçalho do host contém o nome do host do proxy www.proxyserver.com. Como há uma restrição de firewall configurada no servidor de back-end que espera que apenas o nome do host do servidor de back-end seja contido no cabeçalho do host, você recebe o erro Proxy refused to create tunnel with response status 403.

   tcpdump

   Para determinar o cabeçalho do host usando o tcpdump

   1. Capture um tcpdump no servidor proxy para as solicitações provenientes do componente do processador de mensagens do Apigee Edge com o seguinte comando:

      tcpdump -i any -s 0 host MP_IP_ADDRESS -w FILE_NAME
      

      Para mais informações sobre como usar o comando tcpdump, consulte tcpdump.

   2. Analise os dados tcpdump usando a ferramenta Wireshark ou uma ferramenta semelhante.

   3. Confira um exemplo de análise do tcpdump usando o Wireshark:

      ( ver imagem maior)

      
   4. Os números de pacote 13, 14 e 15 mostram que o processador de mensagens está estabelecendo conexão com o servidor proxy por meio de um processo de handshake TCP de três vias.
   5. No pacote 16, o processador de mensagens se conectou ao host do proxy httpbin.org (mostrado no exemplo acima).

   6. Selecione o pacote 16 e examine o conteúdo do pacote em detalhes e, especificamente, o cabeçalho do host transmitido ao servidor proxy pelo processador de mensagens.

      
   7. O exemplo acima mostra cabeçalho do host httpin.org, que é o nome do host do servidor proxy. Portanto, quando o servidor proxy tenta criar o túnel com o servidor de back-end transmitindo o cabeçalho do host httpin.org, ele falha com o erro Proxy refused to create tunnel with response status 403.

Resolução

Cenário: a restrição de firewall no servidor proxy espera que o cabeçalho do host sempre contenha o nome do host do servidor de back-end

Se você tiver verificado que esse erro é causado porque o firewall no servidor de back-end está configurado de modo que espera que o cabeçalho do host sempre contenha o nome do host do servidor de back-end, enquanto o processador de mensagens está enviando o nome do host do servidor proxy, siga estas etapas para resolver o problema:

1. Defina a propriedade use.proxy.host.header.with.target.uri como verdadeira no TargetEndpoint, conforme mostrado no exemplo a seguir:

   Exemplo de configuração do TargetEndpoint:

   <TargetEndpoint name="default">
     <HTTPTargetConnection>
       <URL>https://mocktarget.apigee.net/json</URL>
       <Properties>
         <Property name="use.proxy.host.header.with.target.uri">true</Property>
       </Properties>
     </HTTPTargetConnection>
   </TargetEndpoint>

2. Verifique se as outras propriedades relacionadas ao proxy de encaminhamento estão configuradas no processador de mensagens da seguinte maneira:

   1. Analise o arquivo /opt/apigee/customer/application/message-processor.properties em cada um dos processadores de mensagens.

   2. Verifique se as seguintes propriedades estão definidas de acordo com seu caso de uso ou requisitos:

      Exemplo de valores para propriedades:

      conf_http_HTTPClient.use.proxy=true
      conf/http.properties+HTTPClient.proxy.type=HTTP
      conf/http.properties+HTTPClient.proxy.host=PROXY_SERVER_HOST_NAME
      conf/http.properties+HTTPClient.proxy.port=PORT_#
      conf/http.properties+HTTPClient.proxy.user=USERNAME
      conf/http.properties+HTTPClient.proxy.password=PASSWORD

É necessário coletar informações de diagnóstico

Se o problema persistir mesmo depois de seguir as instruções acima, reúna as seguintes informações de diagnóstico e entre em contato com o suporte do Apigee Edge:

Se você for um usuário da nuvem privada, forneça as seguintes informações:

• Mensagem de erro completa observada para as solicitações com falha
• Nome do ambiente
• Pacote de proxy de API
• Arquivo de trace para as solicitações de API

• Registros de acesso do NGINX

  /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  Em que: ORG, ENV e PORT# são substituídos por valores reais.

• Registros do sistema do processador de mensagens

  /opt/apigee/var/log/edge-message-processor/logs/system.log

Referências

• Configurar proxy de encaminhamento
• Tunelamento SSL