Eu tenho um gateway de aplicativo para o qual minhas configurações de back-end são configuradas com sondagens de integridade, permitindo o status 200-499 como íntegro (incluí os 4xxcódigos da série, pois algumas soluções têm raízes de site que retornam 404, embora tenham conteúdo em outros caminhos, e alguns sites retornam um 403 automaticamente para um usuário não autorizado / Não quero que isso afete o status de integridade do back-end / Queria que minha solução fosse o mais genérica possível para que eu pudesse reutilizar as mesmas configurações em uma série de sites para minimizar o esforço ao integrar novos sites ).
No entanto, minha integridade de back-end mostra um dos meus sites retornando HTTP 463códigos de status (portanto, o back-end ainda está íntegro, mas essa resposta é inesperada). Além disso, se eu navegar até o URI do ouvinte associado a esse back-end, ficarei preso em um redirecionamento 301 de/para o mesmo site. Eu tenho redirecionamentos configurados:
- O backend redireciona de
/para/login.aspxpara um usuário não autenticado. Isso usa caminhos relativos, portanto, não é afetado pelo nome do host do AppGW ou pelo protocolo front-end versus back-end. - O AppGW possui ouvintes HTTP e HTTPS, a regra HTTP redireciona para o ouvinte HTTPS, enquanto a regra HTTPS está associada ao backend.
No entanto, mesmo se eu remover esses recursos, obtenho o mesmo comportamento.
Outros sites no mesmo AppGW são configurados da mesma maneira, mas não apresentam esse problema.
Eu tenho um script do PowerShell para testar redirecionamentos: Get-HttpUrlRedirects . Se assumirmos que a configuração foi para example.com, a saída ESPERADA da execução Get-HttpUrlRedirects -Url 'http://example.com' -Verboseseria:
VERBOSE: Redirecting to [https://example.com/]
VERBOSE: Redirecting to [https://example.com/login.aspx]
Url StatusCode
--- ----------
http://example.com/ 301
https://example.com/ 302
https://example/login.aspx 200
Embora a saída REAL seja:
VERBOSE: Redirecting to [https://example.com/]
VERBOSE: Redirecting to [https://example.com/]
VERBOSE: Redirecting to [https://example.com/]
VERBOSE: Redirecting to [https://example.com/]
Url StatusCode
--- ----------
http://example.com/ 301
https://example.com/ 301
VERBOSE: Redirecting to [https://example.com/]
https://example.com/ 301
VERBOSE: Redirecting to [https://example.com/]
https://example.com/ 301
VERBOSE: Redirecting to [https://example.com/]
# etc - I hit ctrl + C to terminate when I see this loop occurring
O problema aqui foi nosso firewall bloqueando o tráfego entre o AppGW e o back-end relacionado. Adicionar uma regra de permissão resolveu o problema.
Detalhe
Nosso gateway de aplicativo é configurado em uma sub-rede que possui uma tabela de rotas associada,
0.0.0.0/0direcionada paranext hop: internet, enquanto os vários intervalos de IP privados (por exemplo,172.16.0.0/12) têm seu tipo de próximo saltovirtual appliancee o destino como IP interno do nosso Firewall. Ou seja, isso garante que o tráfego que atinge o IP público do AppGW tenha respostas retornadas do mesmo IP público (em vez das respostas saírem através do IP público do FW), mas todo o tráfego interno passa pelo nosso firewall antes de atingir os servidores backend.O firewall tinha uma regra que restringia o acesso do CIDR do nosso AppGW ao CIDR da VNet do backend (ou melhor, não tinha uma regra permitindo isso; e nega por padrão).
Ao verificar os logs do firewall, caso esse fosse o problema, nada apareceu (ou seja, o seguinte Kusto retornou apenas back-ends que estavam funcionando, sem mostrar um
Action=Denyback-end com falhaAZFWNetworkLog | where ipv4_is_in_range(SourceIp, '172.12.0.0/28') /* CIDR for our AppGW Subnet */ and DestinationPort == 80 | distinct DestinationIp:), então parecia que o tráfego não estava alcançando o firewall , pois não estava sendo registrado. Como os códigos HTTP463e301estavam sendo retornados, isso implicava que algo estava respondendo, em vez de algo ser bloqueado (como poderíamos esperar se víssemos um503); então demorou um pouco para descobrir, pois a evidência parecia estar apontando para longe do FW.