我需要澄清Linux上的ASP.NET Core应用程序的设置过程 . 我有Apache作为服务器,我想将它用作反向代理 . 在我的ASP.NET核心应用程序上,我有这样的设置:
services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1);
services.Configure<ForwardedHeadersOptions>(options =>
{
options.ForwardedHeaders =
ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
});
app.UseForwardedHeaders(new ForwardedHeadersOptions
{
ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});
转发标头 - 这些是在“如何在Linux上运行ASP.NET Core”的文档中 .
在Program.cs中,我有:
var host = WebHost.CreateDefaultBuilder(args)
.UseKestrel()
.UseUrls("https://*:5001")
.UseIISIntegration()
.UseStartup<Startup>()
.Build();
我有的问题:
-
我是否需要这些转发 Headers ?
-
我是否需要在项目中添加
app.UseHttpsRedirection();
? -
我是否需要在此行中指定
UseUrls("https://*:5001")
https,否则它可以是http? -
我是否需要在我的Kestrel(我的应用程序)上使用https,或者如果我有反向代理我可以使用http和Apache将负责ssl?
-
我是否需要在我的ASP.NET核心应用程序中使用任何其他代码才能使其与反向代理一起使用?
1 回答
一般来说,是的 . 反向代理的工作方式是它们基本上接收最终用户的请求,然后通过发出新请求将请求转发给您的应用程序 . 来自反向代理的新请求有自己的标头,对于您的应用程序,就好像从未有过公共请求一样 .
这意味着您的应用只知道内部请求,因此例如也可以只生成内部URL . 为了向您的应用讲授外部URL,您可以使用反向代理提供的转发标头,以便您的应用可以恢复原始请求的外观 . 这样,您的应用就会知道公开请求,并且可以正确回应它 .
不必要 . HTTPS重定向基本上是一种功能,可以通过重定向到HTTPS自动响应HTTP请求 . 通常,应用程序前面的反向代理会处理这个问题,因此在使用直接暴露的Kestrel时,此功能最有意义 .
但是,如果您希望在应用程序中使用此功能,而不是在反向代理内部,则仍可以使用该功能 . 如果您的反向代理在HTTP和HTTPS上为您的应用程序提供服务,并且它还在Forwarded标头中正确转发该方案,那么您的应用程序可以正确检测到并重定向到HTTPS .
从安全的角度来看,反向代理可能更好(也可能更简单),不会将任何HTTP请求转发到您的应用程序,只是自己重定向到HTTPS .
这还取决于您希望如何在内部设置应用程序 . 通常,由于您的反向代理是公开可见的代理,因此您不需要在内部使用HTTPS,这通常也会带来更好的性能和更少的开销(并且它会降低证书的配置复杂性) . 但是,在某些情况下,您甚至可能希望在内部使用HTTPS,以使您的应用程序更安全并更好地保护其传输的数据 . 这完全取决于你 .
我通常建议您不要使用
UseUrl()
调用,只需使用ASPNETCORE_URLS
环境变量来指定内部托管URL和端口 . 这样,您可以更灵活地进行环境更改,并且可以在部署应用程序时选择系统上的端口,并且您不必仅为了切换内部端口而重新编译应用程序 .如上所述,设置通常是您的反向代理托管在HTTPS上,反向代理与您的应用程序之间的内部通信可以通过HTTP进行 . 您也可以完全选择在内部使用HTTPS .
不,为了让应用程序允许它在反向代理之后运行,您通常需要的只是激活转发的头文件中间件(如果您在IIS后面运行,则激活IISIntegration) . 其余设置发生在反向代理上,您需要确保转发的标头也已正确设置 .