我正在通过 ARM 模板部署 Azure Front Door,并尝试在自定义域上启用 HTTPS。
根据Front Door的Azure 文档,有一个快速入门模板“将自定义域添加到您的 Front Door 并使用通过 DigiCert 生成的 Front Door 托管证书为其启用 HTTPS 流量”。但是,虽然这会添加自定义域,但它不会启用 HTTPS。
查看 Front Door的ARM 模板参考,我看不到任何明显的启用 HTTPS 的方法,但也许我遗漏了什么?
尽管有以下附加信息,我还是希望能够通过 ARM 模板部署在 Front Door 自定义域上启用 HTTPS。这在这个时候可能吗?
请注意,有一个启用 HTTPS的REST 操作,但这似乎不适用于 Front Door 托管证书 -
POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/frontDoors/{frontDoorName}/frontendEndpoints/{frontendEndpointName}/enableHttps?api-version=2019-05-01
{
"certificateSource": "FrontDoor",
"protocolType": "ServerNameIndication",
"minimumTLSVersion": "1.2"
}
Run Code Online (Sandbox Code Playgroud)
还有一个Az
PowerShell cmdlet 来启用 HTTP,它确实有效。
Enable-AzFrontDoorCustomDomainHttps -ResourceGroupName "lmk-bvt-accounts-front-door" -FrontDoorName "my-front-door" -FrontendEndpointName "my-front-door-rg"
Run Code Online (Sandbox Code Playgroud) 上个月,我注意到由于传出带宽,我的 Azure 账单大幅增加。我使用了 1800GB 的传出数据,而之前使用了大约 200GB。经过一些研究,我发现这是由我上个月启用的 Azure Front Door 服务引起的,我不知道与该服务相关的额外间接成本。
我将在下面提供我对“问题”的分析,希望能避免其他人犯我犯的错误。
这是关于 Azure 前门缓存和 Azure CDN 的使用。我有一个 Azure 静态网站,将显示 Azure blob 存储中的数据(主要是办公文件和视频)。Blob 存储中的文件很少会更改。我正在寻找缓存这些文件的最佳方法和最便宜的方法,以便可以快速获取文件。
推荐或支持链接将会有所帮助。
提前致谢。
azure azure-cdn azure-blob-storage azure-front-door azure-static-web-app
我希望能够仅使用 Azure Front Door / 而不是 Azure CDN 来提供 SPA。看起来 Front Door 提供了 CDN 将提供的缓存,我可以向其中添加多个区域存储帐户,使其在规模上成为全球性的。
问题是,我无法匹配index.html
文件的路径。找到了这个反馈,看起来可以使用 URL 重写和重定向来解决这个问题,但不知道如何解决。
我必须/test/
与/test
下面的路由匹配,所以它应该匹配 /test 并将请求指向,/test/index.html
但这不起作用。我们不能做基于文件的转发吗?
我已阅读下面的链接并延长了超时时间,禁用了 Origin/Azure Front Door 上的压缩,并使用规则集规则从字节范围请求的请求中删除接受编码。但是,我仍然收到这些随机 503 错误或空白页。
https://learn.microsoft.com/en-us/azure/frontdoor/front-door-troubleshoot-routing
在我的 Web 应用程序中,我使用自己的证书添加了自定义域 (app.contoso.com)。
在我的前门中,我使用自己的证书添加了自定义域 (app.contoso.com),并设置了后端池和路由规则。
在更新后端中,我将后端主机标头留空,因为我希望它能够重定向到自定义域而不是显示 Web 应用程序 URL。
在我的路由规则中,我设置了以下内容
我已严格遵循 Azure 提供的说明,但仍然从 Azure Front Door 收到随机 503 错误或空白页。当我从前门的自定义域收到 503 错误或空白页时,我可以确认我的 Web 应用程序 (contoso.azurewebsites.net) 正在运行。我还确保在 Web 应用程序和前门自定义域上使用相同的 SSL 证书。
在我的 DNS 中,我映射了以下内容
app.contoso.com CNAME contoso.azurefd.net
有什么我错过的或者有人有解决方案吗?
跟进
我尝试启用和禁用证书主题名称验证并将发送/接收超时从 30 更改为 240 或从 240 更改为 30,但仍然遇到相同的问题。
更新:它给出空白页或 503 错误(参见下面的屏幕截图)
我在多个后端 Web 应用程序前面设置了 FrontDoor。我注意到每天都会出现一些随机的 503 错误。请求本身是有效的,并且重试通常有效,但是失败的初始请求没有到达后端 Web 应用程序。发生错误时的后端运行状况也是 100%,并且不可能超时,因为错误是立即发生的(超时也延长到 240 秒)。FrontDoor 本身似乎存在某种健康问题,但没有提到健康问题。
我有一个使用 Angular 8 和 Asp.net Core Web API 开发的 SaaS Web 应用程序。我已将 web api 部署到 azure web 应用程序,并将 angular 前端 web 应用程序部署到另一个 azure web 应用程序。
用户来自中国和澳大利亚等国家。我想要区域负载平衡,就像中国用户在 china azure 区域使用 web 应用程序,澳大利亚用户使用澳大利亚 azure 区域 web 应用程序一样,以便它具有最佳性能。Azure SQL DB 将位于一处(在澳大利亚)。
此外,我想防止对 Web 前端应用程序和 Web api 的攻击,例如 d-dos、Web 抓取和 SQL 注入。对于网页抓取,我想从一个 ip 添加访问速率限制。
你能告诉我应该使用什么服务吗?我在博客上看到了关于 azure 应用程序网关、azure 负载均衡器、azure 前门和 azure 流量管理器的内容。这对我来说有点混乱。我需要一个基于我这个真实世界场景的最佳实践。我应该使用其中一项服务还是应该使用多项服务?
azure-web-app-service azure-application-gateway azure-load-balancer azure-front-door
我已经使用应用程序服务设置了 Frontdoor,并且还在两个不同的子目录中部署了 ReactJsapp 和 Asp.net API,例如 site\wwwroot\webapp 和 site\wwwroot\api。问题是,当我使用 azure frontdoor url example.azurewebfd.net/webapp 时,它会直接指向 example.azurewebsite.net/webapp。它适用于 api,它不会重定向到 example.azurewebsite.net/api 并保留 example.azurefd.net/api。
如何解决这个问题?
我有一个 Azure FrontDoor 设置作为在端口 5443 上运行的容器和自定义域之间的反向代理/负载均衡器。这样做的目的是为用户提供一个标准的地址。即https://oursite3.example.com指向container.azurecontainer.io:3443 。
同一个 aci 正在运行多个容器:
container.azurecontainer.io:443
container.azurecontainer.io:2443
container.azurecontainer.io:3443
Run Code Online (Sandbox Code Playgroud)
https://oursite1.example.com
https://oursite2.example.com
https://oursite3.example.com
Run Code Online (Sandbox Code Playgroud)
然后,我们在全球不同区域部署了多个 aci(因此使用 Frontdoor 在不同实例之间进行负载平衡)。
在此示例中,container.azurecontainer.io:3443 安装了 MS AD 身份验证。单击链接后,用户会重定向到登录,并生成一个链接并将浏览器重定向到该链接。该链接中包含redirect_uri。类似于: https: //login.microsoftonline.com/00000000-0000-0000-0000-000000000001/oauth2/authorize ?client_id=00000000-0000-0000-0000-000000000002&redirect_uri=https%3A%2F%2Foursite3.example.com %3A3443%2Fsignin-oidc&response_type=id_token&scope=openid%20profile&response_mode=form_post&nonce=jkalksdfj alskdjflkjalksdfjalkjA&x-client-SKU=ID_NETSTANDARD2_0&x-client-ver=5.5.0.0
但是,登录后,用户会在网站上看到以下内容:
AADSTS50011:请求中指定的回复 URL 与为应用程序配置的回复 URL 不匹配:“00000000-0000-0000-0000-000000000003”
原因是 AD 应用程序的回复 url 设置为:
https://oursite3.example.com/signin-oidc
Run Code Online (Sandbox Code Playgroud)
但是,仔细检查后,用户登录时重定向到的 url 包含此作为 redirect_uri:
https://oursite3.example.com:5443/signin-oidc
Run Code Online (Sandbox Code Playgroud)
即端口 5443 已添加到主机名的末尾。
本质上,它包括了redirect_uri 中的底层原始端口,这是我不希望看到的。
我尝试在我们的网站中使用 ForwardedOptions 。例如,我们的startup.cs文件包含以下内容(ConfigureServices):
services.Configure<ForwardedHeadersOptions>(options =>
{
options.ForwardedHeaders = ForwardedHeaders.XForwardedFor |
ForwardedHeaders.XForwardedProto;
// Only loopback proxies are allowed by default.
// Clear that restriction …
Run Code Online (Sandbox Code Playgroud) 使用 Terraform 创建 Azure Front Door 实例时遇到问题。设置应该是非常基本的,但无法找出问题所在。
这是地形脚本
resource "azurerm_frontdoor" "b2cfrontdoor" {
name = "fd-adpb2c-westeurope-dev"
resource_group_name = azurerm_resource_group.b2c.name
enforce_backend_pools_certificate_name_check = true
routing_rule {
name = "routingrule"
accepted_protocols = ["Http", "Https"]
patterns_to_match = ["/*"]
frontend_endpoints = ["b2c-frontdoor-endpoint-dev"]
forwarding_configuration {
forwarding_protocol = "MatchRequest"
backend_pool_name = "b2-backend-pool-dev"
}
}
backend_pool_load_balancing {
name = "loadbalancingsettings"
}
backend_pool_health_probe {
name = "healthprobesettings"
enabled = false
probe_method = "HEAD"
}
backend_pool {
name = "b2-backend-pool-dev"
backend {
host_header = "xyz.b2clogin.com"
address = "xyz.b2clogin.com"
http_port = 80 …
Run Code Online (Sandbox Code Playgroud) 我们有 2 个应用程序服务:foo.azurewebsites.net
和bar.azurewebsites.net
并为两个站点配置了源组。我们希望前门进行基于路径的路由:即:
myfd.z01.azurefd.net/foo -> foo.azurewebsites.net
myfd.z01.azurefd.net/bar -> bar.azurewebsites.net
Run Code Online (Sandbox Code Playgroud)
Patterns to match
我们可以将其配置为分别在路由 as/foo/*
和上使用/bar/*
。这按预期工作。
接下来,我们要重写 URL,以便我们不会将初始值/foo
或/bar
路径发送到 Web 应用程序。换句话说,当前设置会产生以下结果:
myfd.z01.azurefd.net/foo/abc -> foo.azurewebsites.net/foo/abc
myfd.z01.azurefd.net/bar/def -> bar.azurewebsites.net/bar/def
Run Code Online (Sandbox Code Playgroud)
我们想要的是:
myfd.z01.azurefd.net/foo/abc -> foo.azurewebsites.net/abc
myfd.z01.azurefd.net/bar/def -> bar.azurewebsites.net/def
Run Code Online (Sandbox Code Playgroud)
所以我们设置一个重写URL规则如下:
环境 | 价值 |
---|---|
行动 | 网址重写 |
源模式 | /foo/ |
目的地 | / |
保留不匹配的路径 | Yes |
然而,这似乎不起作用。在AzureDiagnostics
日志中我们可以看到规则正在触发,但 URL 没有被重写 - 它仍然包含/foo/
. 我们还缺少什么吗?