Erros 502 / 504 GATEWAY_TIMEOUT ao navegar para determinados sites

Se o servidor da Web não responder aos pacotes SYN do WSA, após uma certa quantidade de tentativas, o cliente receberá um erro de 502 Gateway Timeout.

As causas típicas são:
 1. O servidor Web ou a rede do servidor Web está tendo problemas.
 2. Um problema de rede na rede WSA está impedindo que os pacotes SYN cheguem à Internet.
 3. Um firewall ou dispositivo similar está descartando os pacotes SYN do WSA ou o SYN/ACK do servidor Web
 4. O spoofing de IP está habilitado no WSA, mas não está configurado corretamente (sem redirecionamento de caminho de retorno)

Passos de Troubleshooting:

A primeira etapa é verificar se o WSA pode fazer ping ICMP no servidor Web. Isso pode ser feito usando o seguinte comando CLI:

WSA> ping www.example.com

Se o ping falhar, isso não significa que o servidor está inoperante. Isso pode significar que os pacotes ICMP estão sendo bloqueados em algum lugar no caminho. Se o ping for bem-sucedido, poderemos ter certeza de que o WSA tem um nível básico de conectividade da camada 3 com o servidor Web.

Um teste telnet verificará se o WSA tem a capacidade de estabelecer uma conexão TCP na porta 80 para o servidor Web. Consulte as instruções neste artigo para executar um teste de telnet.

Problemas de rede ou bloqueio de firewall

Se o ping tiver êxito, mas o telnet falhar, há uma boa possibilidade de que um dispositivo de filtragem, como um firewall, esteja impedindo que esse tráfego passe pela rede. Recomenda-se que os registros de firewall e/ou as capturas de pacotes do firewall sejam analisados para obter mais detalhes.

IP Spoofing habilitado, mas não configurado corretamente

Se o proxy explicitamente através do WSA ou o teste telnet for bem-sucedido, isso mostra que o WSA pode se comunicar diretamente com o servidor Web, mas quando um cliente faz proxy através do WSA com falsificação de IP, há um problema.

Sem falsificação de IP de cliente:

• O WSA envia um SYN ao servidor Web usando seu próprio endereço IP como origem. Quando o pacote volta, ele vai diretamente para o WSA.

Com falsificação de IP de cliente:

• O WSA envia o SYN, mas, em vez disso, usa o IP do cliente como origem. Sem uma configuração de rede especial, o pacote de retorno será enviado ao cliente em vez do WSA.
• Para usar o spoofing do IP do cliente, a rede deve ser configurada de uma maneira muito específica para facilitar que os pacotes sejam redirecionados corretamente. Se os pacotes de caminho de retorno do servidor Web estiverem sendo enviados ao cliente em vez do WSA, o WSA nunca verá os servidores SYN/ACK e enviará um erro de 502 Gateway Timeout de volta ao cliente.

 Se o WSA receber um pacote de redefinição de TCP em sua conexão upstream com o servidor Web, o WSA enviará um erro 504 Gateway Timeout ao cliente.
 

As causas típicas são:
 1. O Cisco Layer 4 Traffic Monitor (L4TM) está impedindo o proxy WSA de se conectar ao servidor Web.
 2. Um firewall, IDS, IPS ou outro dispositivo de inspeção de pacotes está bloqueando o WSA. 
 
Passos de Troubleshooting:

Primeiro determine se o TCP RST está vindo do L4TM ou de outro dispositivo.

Se o L4TM estiver bloqueando esse tráfego, o tráfego será exibido nos relatórios de GUI em "Monitor -> L4 Traffic Monitor". Caso contrário, o RST virá de um dispositivo diferente.

Bloqueio de L4TM:

É recomendável que, se o L4TM estiver bloqueando, não bloqueie as portas nas quais o proxy WSA também está sendo executado. Há vários motivos para isso:

1. O proxy WSA fornece uma mensagem de erro amigável em caso de problema, em vez de apenas TCP redefinindo a conexão. Isso ajudará a limitar a confusão dos usuários finais quando eles forem bloqueados.
2. O proxy WSA tem a capacidade de digitalizar e bloquear conteúdo específico, enquanto o L4TM bloqueia todo o tráfego correspondente a um endereço IP na lista negra.

Para configurar o L4TM para não bloquear portas proxy, vá para "GUI -> Security Services -> L4 Traffic Monitor".

Se o site for um site da Web reconhecidamente ruim, mas houver motivos pelos quais o tráfego deve ser permitido, o site poderá ficar branco listado em:
"GUI -> Web Security Manager -> L4 Traffic Monitor -> Lista de permissões"

Bloqueio de firewall / IDS / IPS:

Se outro dispositivo na rede estiver bloqueando a conexão do WSA ao servidor Web, é recomendável analisar o seguinte:

1. Logs de bloqueio do firewall
2. Capturas de pacotes de entrada/saída durante o problema

Os registros de bloqueio podem confirmar rapidamente se o dispositivo está bloqueando o WSA. Às vezes, um firewall, IPS ou IDS bloquearão o tráfego e NÃO o registrarão adequadamente. Se esse for o caso, a única maneira de provar de onde o TCP RST está vindo é obter capturas de entrada e saída do dispositivo. Se um RST estiver sendo enviado para fora da interface de entrada e nenhum pacote trafegar pelo lado de saída, o dispositivo de segurança é definitivamente a causa.

Se o WSA enviar um HTTP GET, mas nunca receber uma resposta, ele enviará um erro 504 Gateway Timeout ao cliente.

As causas típicas são:

• Um firewall, IDS, IPS ou outro dispositivo de inspeção de pacotes permite a conexão TCP, mas impede que o conteúdo HTTP acesse o servidor Web. Nesse caso, o teste telnet pode ajudar a isolar que tipo de dados HTTP está sendo bloqueado.

Os logs de bloqueio do firewall podem confirmar rapidamente se / por que o dispositivo está bloqueando o WSA. Às vezes, um firewall, IPS ou IDS bloquearão o tráfego e NÃO o registrarão adequadamente. Se esse for o caso, a única maneira de provar de onde o TCP RST está vindo é obter capturas de entrada e saída do dispositivo. Se um RST estiver sendo enviado para fora da interface de entrada e nenhum pacote trafegar pelo lado de saída, o dispositivo de segurança é definitivamente a causa.

 Na CLI do WSA, execute o comando telnet:

WSA>telnet

Selecione de qual interface você deseja executar telnet.
1. Automático
2. Gerenciamento (192.168.15.200/24: wsa.hostname.com)
3. P1 (192.168.113.199/24: data.com)
[1]> 3

Digite o nome do host remoto ou o endereço IP.
[]> www.example.com

Insira a porta remota.
[25]> 80

Tentando 10.3.2.99...
Conectado a www.example.com.
O caractere de escape é '^]'.

Nota: A mensagem "Connected" em vermelho indica que o TCP foi estabelecido com êxito entre o WSA e o servidor Web.

Uma solicitação HTTP também pode ser enviada manualmente por meio dessa sessão telnet. Veja a seguir um exemplo de solicitação que pode ser digitada após a mensagem "Conectado":

-------------------------------------------------------------------------------------

OBTENHA http://www.example.com HTTP/1.1
HOST: www.example.com
{Insira}
-------------------------------------------------------------------------------------

Observação: certifique-se de adicionar o retorno de carro extra no final, caso contrário o servidor não responderá à solicitação.