O chamado chega com duas informações que parecem contraditórias: os usuários não conseguem acessar a aplicação, mas o pool está verde.
As duas coisas podem estar corretas. O monitor pode estabelecer uma conexão com o servidor enquanto a requisição do usuário falha no TLS, recebe um redirecionamento incorreto ou chega a um backend que não consegue concluir a operação.
O estado do pool é uma evidência útil. O problema começa quando ele passa a ser tratado como prova de funcionamento da aplicação.
A investigação precisa acompanhar uma requisição e identificar em qual ponto o comportamento deixa de ser o esperado.
Primeiro, defina o que está falhando
“Não funciona” pode significar timeout, reset, erro de certificado, HTTP 403, HTTP 503 ou uma página que abre, mas não permite autenticação. Cada sintoma pede uma investigação diferente.
Antes de alterar qualquer configuração, registre:
- FQDN, caminho e método HTTP afetados.
- IP de origem observado e horário do teste, incluindo o fuso.
- Resultado esperado e resultado recebido.
- Se a falha ocorre sempre, com determinados usuários ou apenas em algumas operações.
- Se existe CDN, proxy ou outro equipamento entre o cliente e o BIG-IP.
Uma página inicial funcionando não comprova que login, upload ou chamadas de API estejam funcionando.
Confirme o virtual server e a configuração aplicada
Os exemplos abaixo consideram BIG-IP clássico com TMOS, um virtual server Standard e objetos na partição /Common. Ajuste nomes, endereços e route domains ao ambiente.
Execute no Bash do BIG-IP:
tmsh show ltm virtual /Common/vs_app
tmsh list ltm virtual /Common/vs_app all-properties
tmsh show ltm pool /Common/pool_app members
tmsh list ltm pool /Common/pool_app all-properties
Observe as estatísticas antes e depois de uma requisição controlada. Em ambientes movimentados, o crescimento dos contadores sozinho não identifica o seu teste; confirme com uma captura filtrada.
Na configuração, confira destino, porta, VLANs permitidas, perfis, persistência e tradução de origem. Leia também as iRules e as LTM policies associadas.
O pool padrão do virtual server pode não ser aquele utilizado pela requisição. Uma regra pode selecionar outro pool, devolver uma resposta ou emitir um redirecionamento.
Reproduza a requisição mantendo o hostname
Testar https://IP_DO_VIP pode produzir um resultado diferente do acesso pelo nome da aplicação. O hostname participa tanto da validação do certificado quanto do SNI e do cabeçalho HTTP Host.
De uma estação de teste com acesso ao VIP:
curl -sv \
--connect-timeout 5 \
--max-time 20 \
--resolve app.example.com:443:192.0.2.10 \
https://app.example.com/health \
-o /dev/null
O --resolve direciona a conexão para o endereço escolhido sem substituir o hostname da URL. Isso permite testar um VIP específico mantendo o nome esperado pela aplicação.
Esse teste ignora a resolução DNS normal e pode contornar componentes anteriores ao VIP. Compare com o acesso habitual; ele não substitui a reprodução do caminho completo do usuário.
Evite começar com -k: ignorar a validação do certificado pode esconder justamente a falha investigada. Para uma CA privada, utilize o certificado de confiança adequado com --cacert.
O caminho /health é apenas um exemplo. Se a falha acontece em outra operação, reproduza essa operação com uma conta de teste e sem expor credenciais nos registros.
Descubra o que o monitor realmente comprova
Consulte o monitor efetivamente associado ao pool ou ao membro:
tmsh list ltm monitor http /Common/mon_app_http all-properties
Para um monitor HTTPS, utilize o componente ltm monitor https.
Confira tipo, destino, porta, send, recv e eventuais configurações herdadas. Verifique também se a expressão de associação exige todos os monitores ou apenas uma quantidade mínima.
Um monitor TCP sem validação de conteúdo não demonstra que a aplicação consegue atender uma transação HTTP. Um monitor HTTP que consulta uma página genérica também pode continuar passando durante uma falha funcional.
Considere este cenário ilustrativo:
O backend atende vários sites na mesma porta. Uma consulta sem o Host esperado recebe a página padrão. O monitor aceita essa resposta, mas o site utilizado pelos usuários está indisponível.
De uma estação autorizada com acesso ao backend, compare:
curl -sv \
--connect-timeout 5 \
--max-time 20 \
http://198.51.100.20:8080/health
curl -sv \
--connect-timeout 5 \
--max-time 20 \
-H 'Host: app.example.com' \
http://198.51.100.20:8080/health
Se as respostas diferirem, investigue a seleção do site no backend e a representatividade do monitor.
Um exemplo de conteúdo para o campo Send String seria:
GET /health HTTP/1.1\r\nHost: app.example.com\r\nConnection: close\r\n\r\n
O Receive String poderia procurar um marcador específico, como:
app_ready
Esse marcador precisa ter um significado definido pela aplicação. Se aparecer em uma página estática enquanto o serviço está quebrado, continuará gerando uma falsa sensação de disponibilidade.
Também é preciso cuidado ao incluir dependências compartilhadas no health check. Uma falha de banco de dados, por exemplo, pode retirar todos os membros simultaneamente. O comportamento desejado deve ser combinado com a equipe da aplicação.
Observe os dois lados da conexão
Em um virtual server Standard com processamento full proxy, investigue separadamente o trecho cliente–BIG-IP e o trecho BIG-IP–backend.
Uma captura curta durante uma reprodução ajuda a localizar a interrupção:
tcpdump -nni 0.0:nnn -s0 -c 500 \
-w /var/tmp/app-test.pcap \
'((host 192.0.2.50 and tcp port 443) or
(host 198.51.100.20 and tcp port 8080))'
Nesse exemplo, 192.0.2.50 representa o cliente observado pelo BIG-IP e 198.51.100.20 representa um backend. Inclua outros membros quando necessário.
O limite é de pacotes, não de tempo. Encerre a captura ao concluir a reprodução se ela não atingir esse limite. O arquivo pode conter dados sensíveis; restrinja acesso e retenção.
Procure evidências concretas:
- O SYN do cliente chega ao BIG-IP?
- O BIG-IP responde?
- Existe uma conexão ou tráfego correspondente no lado servidor?
- O backend responde?
- Em qual trecho aparecem retransmissões ou resets?
Conexões com o backend podem ser reutilizadas; não espere necessariamente um novo handshake TCP para cada requisição HTTP.
O modificador :nnn acrescenta informações específicas do BIG-IP à captura. Ele não descriptografa TLS.
Verifique o retorno antes de alterar SNAT
Quando o backend recebe a conexão, mas o fluxo não se completa, confirme o endereço de origem utilizado no lado servidor e a rota de retorno.
Sem SNAT, o servidor pode precisar de uma rota que devolva o tráfego pelo BIG-IP. Se a resposta seguir por outro caminho, a conexão pode falhar mesmo com o monitor funcionando.
O tráfego do monitor pode ter uma origem diferente da utilizada pelas conexões de aplicação. Portanto, monitor funcionando não elimina problemas de roteamento ou ACL no tráfego real.
Ativar Automap indiscriminadamente pode mudar o sintoma, mas também altera a origem vista pelo backend. Antes de qualquer mudança, avalie rastreabilidade, controles de acesso e capacidade de tradução.
Separe TLS de HTTP
Quando há terminação e nova criptografia no BIG-IP, existem duas negociações TLS a verificar.
No lado cliente, investigue o Client SSL profile, certificado, cadeia apresentada, hostname e eventuais exigências de certificado do cliente.
No lado servidor, examine o Server SSL profile, compatibilidade TLS, SNI exigido pelo backend e a política configurada de autenticação do certificado remoto.
Receber o certificado correto no navegador não comprova que a conexão TLS com o backend foi estabelecida.
Da mesma forma, corrigir o cabeçalho HTTP Host não resolve uma negociação TLS que falha antes de qualquer HTTP ser transmitido.
Só atribua a falha ao WAF quando houver evidência
Se houver Advanced WAF no caminho, procure o evento correspondente à requisição: horário, URL, método, política, violação e ação aplicada. Utilize o Support ID quando estiver disponível.
Um HTTP 403 sozinho não identifica quem bloqueou. A resposta pode vir do backend, de uma iRule, de uma política de acesso ou de outro componente.
A ausência de evento também não comprova ausência de inspeção. Confirme a configuração de logging e se a requisição chegou ao ponto esperado.
Se houver um falso positivo confirmado, ajuste o elemento específico da política e repita o teste. Desativar a proteção inteira prejudica tanto a segurança quanto a investigação.
Encerre com a transação que falhava
Depois da correção, repita a mesma operação, pelo mesmo caminho e com as mesmas condições relevantes. Confira a resposta, o conteúdo e o comportamento da aplicação.
Em falhas intermitentes, valide os membros envolvidos e o efeito da persistência. Uma única resposta correta pode ter vindo de outro servidor.
Para registrar a solução, vale mais uma sequência curta de evidências do que uma lista extensa de alterações: requisição afetada, ponto da falha, causa confirmada, ajuste realizado e resultado do teste.
Qual foi a causa mais inesperada que você encontrou em um ambiente com o pool verde e a aplicação indisponível?
Documentação para consulta