Laboratório de Troubleshooting: Configure rewrite rule sets
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações relata que requisições enviadas para uma aplicação exposta via Application Gateway v2 estão chegando ao backend com o cabeçalho X-Forwarded-Host incorreto. O ambiente usa SKU Standard_v2 e o WAF está habilitado no modo de detecção. O time de segurança recentemente ajustou as regras do WAF para detectar injeção de cabeçalho, mas não alterou nenhuma outra configuração.
O engenheiro responsável verifica o rewrite rule set e encontra a seguinte configuração:
Rewrite Rule Set: rrs-headers
Rule: fix-forwarded-host
Condition:
Variable: http_req_header_host
Pattern: .*
Action:
Type: set
Header type: request header
Header name: X-Forwarded-Host
Header value: {http_req_header_host}
O rule set está listado na configuração do gateway, e o listener está ativo. Testes com curl mostram que o valor de X-Forwarded-Host que chega ao backend é o IP interno do gateway, não o hostname do cliente.
Qual é a causa raiz do problema?
A) O WAF em modo de detecção está alterando o valor do cabeçalho X-Forwarded-Host antes que a rewrite rule seja aplicada
B) O rewrite rule set não está associado a nenhuma request routing rule, portanto a regra não é executada
C) A variável {http_req_header_host} resolve para o hostname do backend pool, não para o cabeçalho Host original da requisição
D) A Condition com pattern .* invalida a Action, pois esse pattern corresponde a qualquer valor e é ignorado pelo motor de reescrita
Cenário 2 — Decisão de Ação
O time de plataforma identificou que um Application Gateway em produção está encaminhando ao backend URLs com o parâmetro de query string debug=true em todas as requisições, mesmo nas que partem de usuários finais. A causa foi confirmada: uma rewrite rule configurada incorretamente está inserindo esse parâmetro em todas as requisições, sem Condition.
O ambiente tem as seguintes restrições:
- O gateway atende 100% do tráfego de produção de uma aplicação financeira
- Há uma janela de manutenção disponível em 6 horas
- Existe um ambiente de staging com configuração idêntica ao de produção
- A equipe tem permissão para modificar o gateway fora da janela, desde que o impacto seja validado antes
Qual é a ação correta a tomar neste momento?
A) Remover imediatamente a rewrite rule incorreta do gateway de produção, pois o impacto está em curso e cada requisição expõe o parâmetro indesejado
B) Validar a correção no ambiente de staging, documentar o resultado e aplicar a mudança em produção dentro da janela de manutenção
C) Validar a correção no ambiente de staging e, confirmado o resultado, aplicar a mudança em produção agora, sem aguardar a janela
D) Desabilitar o rewrite rule set inteiro em produção imediatamente para cessar o problema, e recriar apenas as regras corretas durante a janela de manutenção
Cenário 3 — Causa Raiz
Uma aplicação web recebe requisições via Application Gateway v2. O time de desenvolvimento configurou uma rewrite rule para redirecionar internamente paths com prefixo /legacy/ para /v2/. Após a implantação, páginas com path /legacy/reports funcionam, mas páginas com path /legacy/reports/monthly retornam HTTP 404 no backend.
Logs do backend mostram:
GET /v2/reports HTTP/1.1 -> 200 OK
GET /v2/reports HTTP/1.1 -> 200 OK
GET /v2/reports HTTP/1.1 -> 200 OK
O backend está saudável e responde normalmente a /v2/reports/monthly quando testado diretamente. A configuração da rewrite rule é:
Condition:
Variable: uri_path
Pattern: /legacy/reports
Case-sensitive: true
Action:
URL rewrite
Modified path: /v2/reports
Reevaluate backend pool: false
O Application Gateway tem SKU Standard_v2. O certificado TLS do listener foi renovado na semana anterior, mas a cadeia de certificação não foi alterada.
Qual é a causa raiz do problema?
A) A renovação do certificado TLS corrompeu o estado do listener, fazendo com que apenas paths curtos sejam roteados corretamente
B) A flag Reevaluate backend pool: false impede que paths com subníveis sejam enviados ao backend correto
C) O pattern /legacy/reports corresponde como substring a qualquer path que contenha essa sequência, e a Action substitui o path inteiro pelo valor fixo /v2/reports, descartando o restante do path original
D) A Condition com Case-sensitive: true impede a correspondência de paths que contenham letras maiúsculas após /legacy/reports
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe um chamado: o Application Gateway não está inserindo o cabeçalho Cache-Control: no-store nas respostas HTTP, conforme exigido pela política de segurança. O rewrite rule set foi criado e aparentemente configurado. Nenhuma alteração foi feita no backend ou no listener nas últimas 48 horas.
Os passos de investigação disponíveis são:
- Verificar se o rewrite rule set está associado à request routing rule correta
- Confirmar no portal ou via ARM que o tipo de Action está configurado como
setemhttp_res_header - Inspecionar as respostas HTTP reais com
curl -Ipara confirmar a ausência do cabeçalho - Verificar se a Condition da regra, caso exista, está sendo satisfeita pelas requisições de teste
- Confirmar que o nome do cabeçalho na Action está escrito exatamente como
Cache-Control, sem variações de capitalização ou espaços
Qual é a sequência correta de investigação?
A) 3 -> 1 -> 2 -> 4 -> 5
B) 1 -> 2 -> 3 -> 4 -> 5
C) 3 -> 2 -> 1 -> 5 -> 4
D) 2 -> 1 -> 4 -> 3 -> 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está no enunciado: o rule set está "listado na configuração do gateway", mas isso não significa que está associado a uma request routing rule. No Application Gateway, a existência do rewrite rule set como objeto de configuração não produz nenhum efeito enquanto ele não for vinculado a uma ou mais request routing rules. O tráfego flui pelo listener e pela routing rule sem aplicar nenhuma reescrita.
O valor que o backend recebe, o IP interno do gateway, é o comportamento padrão do Application Gateway quando nenhuma reescrita de cabeçalho está ativa: o gateway age como proxy e o X-Forwarded-Host reflete o endereço do próprio gateway, não o host original.
A informação sobre o WAF em modo de detecção é propositalmente irrelevante: o modo de detecção registra, mas não bloqueia nem modifica cabeçalhos. O distrator mais perigoso é C, pois a variável {http_req_header_host} resolve corretamente para o cabeçalho Host da requisição do cliente, não para o backend. Agir com base em C levaria o engenheiro a alterar a variável incorretamente, sem resolver o problema real.
Gabarito — Cenário 2
Resposta: C
A causa está identificada e confirmada. As restrições do cenário autorizam mudanças fora da janela desde que validadas previamente. O ambiente de staging existe exatamente para isso. A sequência correta é: validar em staging e aplicar imediatamente em produção após a confirmação, sem esperar a janela.
A resposta B é tecnicamente segura, mas ignora a restrição explícita que permite agir antes da janela, e prolonga desnecessariamente um problema ativo que expõe o parâmetro debug=true a usuários finais de uma aplicação financeira. A resposta A ignora o princípio de validar antes de agir em produção. A resposta D é a mais perigosa: desabilitar o rewrite rule set inteiro pode remover outras regras corretas e em uso, causando impacto colateral em funcionalidades que dependem das demais reescritas configuradas.
Gabarito — Cenário 3
Resposta: C
Os logs do backend confirmam o diagnóstico: todas as requisições chegam como GET /v2/reports, independentemente do path original. Isso revela que a Action substitui o path inteiro pelo valor literal /v2/reports, sem preservar nenhuma parte do path original além do que está na regex.
O problema está em dois fatores combinados: o pattern /legacy/reports age como correspondência de substring, portanto /legacy/reports/monthly também é correspondido. Mas a Action define um path fixo /v2/reports, sem nenhum grupo de captura que preserve /monthly. O resultado é que toda variação de path após o prefixo é descartada.
A informação sobre a renovação do certificado TLS é irrelevante e foi incluída propositalmente para desviar o diagnóstico. A flag Reevaluate backend pool controla se o gateway reavalia qual backend pool usar após a reescrita, mas não afeta a construção do path reescrito. O distrator D, sobre case-sensitivity, não se aplica porque todos os paths no cenário estão em minúsculas.
Gabarito — Cenário 4
Resposta: A
A sequência correta começa pela confirmação do sintoma real (passo 3): antes de investigar configurações, o engenheiro precisa confirmar com evidência objetiva que o cabeçalho realmente está ausente nas respostas. Sem essa confirmação, o diagnóstico pode estar perseguindo um problema que não existe ou já foi resolvido.
Em seguida, o passo 1 verifica se o rule set está associado à routing rule, pois essa é a causa mais comum e mais fácil de verificar. O passo 2 confirma se a Action está corretamente tipada como resposta e não requisição. O passo 4 verifica se uma Condition existente está sendo satisfeita. O passo 5 verifica detalhes de escrita do nome do cabeçalho, que é o erro mais pontual e improvável, portanto deve ser investigado por último.
A sequência B parece lógica, mas começa pela configuração sem confirmar o sintoma, o que é um erro de método diagnóstico: o engenheiro pode passar horas ajustando configurações que já estão corretas enquanto o problema real é outro.
Árvore de Troubleshooting: Configure rewrite rule sets
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma e responda cada pergunta com base no que você pode observar ou verificar diretamente no portal, via ARM ou com ferramentas como curl. Siga o caminho que corresponde ao que você encontra em cada etapa. Quando o caminho levar a um nó vermelho, você identificou a causa; quando levar a um nó verde, você tem a ação correta a executar. Se a rewrite estiver sendo aplicada mas o resultado ainda for incorreto, retome a partir do nó de validação laranja para investigar a lógica da Action.