主页 / server / 问题 / 1163371
Accepted
JohnLBevan
Asked: 2024-08-02 00:32:34 +0800 CST

Azure 应用程序网关：后端运行状况返回 HTTP 463，用户获得 301 循环

  • 772

我有一个应用程序网关，我的后端设置配置了健康探测，允许状态 200-499 为健康（我之所以包含4xx系列代码，是因为某些解决方案的站点根目录返回 404，而其他路径下有内容，而某些站点会自动为未经授权的用户返回 403 / 我不希望这些影响后端健康状态 / 我希望我的解决方案尽可能通用，这样我就可以重复使用一系列站点上的相同设置，以尽量减少新站点加入时的工作量）。

但是，我的后端健康状况显示我的一个站点正在返回HTTP 463状态代码（因此后端仍然健康，但此响应是意外的）。此外，如果我导航到与此后端关联的侦听器的 URI，我会陷入 301 重定向到/来自同一站点。我确实配置了重定向：

  • 对于未经身份验证的用户，后端会从 重定向/到/login.aspx。这使用相对路径，因此不受 AppGW 的主机名或前端与后端协议的影响。
  • AppGW 有 HTTP 和 HTTPS 监听器，HTTP 规则重定向到 HTTPS 监听器，而 HTTPS 规则与后端相关联。

然而，即使我删除这些功能，仍然会得到相同的行为。

同一 AppGW 上的其他站点以相同的方式设置，但没有这个问题。

我有一个用于测试重定向的 PowerShell 脚本：Get-HttpUrlRedirects。如果我们假设配置为example.com，则运行的预期输出Get-HttpUrlRedirects -Url 'http://example.com' -Verbose将是：

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

而实际输出是：


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
azure

1 个回答

  1. Best Answer

    这里的问题是我们的防火墙阻止了 AppGW 和相关后端之间的流量。添加允许规则解决了这个问题。

    细节

    我们的应用程序网关设置在子网上，该子网具有关联的路由表，例如0.0.0.0/0指向next hop: internet，而各个私有 IP 范围（例如172.16.0.0/12）的下一跳类型为virtual appliance，目标为我们的防火墙的内部 IP。即，这可确保到达 AppGW 的公共 IP 的流量具有从同一公共 IP 返回的响应（而不是通过 FW 的公共 IP 发出的响应），但所有内部流量在到达后端服务器之前都会通过我们的防火墙。

    防火墙有一条规则，限制从我们的 AppGW 的 CIDR 到后端的 VNet 的 CIDR 的访问（或者更确切地说，它没有允许这样做的规则；并且默认拒绝）。

    如果问题出在防火墙日志上，则什么都没出现（例如，以下 Kusto 仅返回了正常运行的后端，而没有显示Action=Deny故障后端AZFWNetworkLog | where ipv4_is_in_range(SourceIp, '172.12.0.0/28') /* CIDR for our AppGW Subnet */ and DestinationPort == 80 | distinct DestinationIp：），因此看起来好像流量没有到达防火墙，因为它没有被记录下来。由于 HTTP 代码463和301被返回，这意味着有东西在响应，而不是有东西被阻止（如果我们看到，我们可能会预料到503）；因此花了一段时间才发现，因为证据似乎指向了 FW 之外的地方。

    • 0

相关问题