![使用 HTTPS 将同一域上的子站点重定向到其他 IIS](https://linux22.com/image/528252/%E4%BD%BF%E7%94%A8%20HTTPS%20%E5%B0%86%E5%90%8C%E4%B8%80%E5%9F%9F%E4%B8%8A%E7%9A%84%E5%AD%90%E7%AB%99%E7%82%B9%E9%87%8D%E5%AE%9A%E5%90%91%E5%88%B0%E5%85%B6%E4%BB%96%20IIS.png)
我见过很多类似的问题(和答案),但似乎没有一个与我面临的情况完全相同。这很奇怪,因为我觉得这没什么特别的,所以如果我没有搜索到足够的信息,请原谅我。
无论如何。我有两个网站,分别位于两个 IIS7 上,一个面向 WAN,一个位于 LAN。面向 WAN 的已经是仅 HTTPS。我想添加第二个网站,但使用相同的 HTTPS 域和 SSL 证书,以便它成为一个子网站,如下所示:https://www.domain.com/subsite 我该如何在第一个 IIS 上重定向或重写到第二个 IIS 以使其正常工作?我认为没有标准 IIS 功能可以做到这一点。ISA 服务器目前不是一个选项。但也许存在另一个 IIS 扩展?
在 Apache 上做过很多次这样的事,并且准备放弃 IIS 而使用 Apache。
答案1
这可以在 IIS 中使用受支持的插件 ARR 和 URLrewrite 来实现。它们作为集成工具安装在 IIS 管理器 GUI 中。
如果您安装最新的 ARR 包,您将获得捆绑的 URLrewrite。在线文档有些欠缺,但只要稍加修改,就可以毫不费力地实现您想要的功能。
即使 GUI 非常友好,我的建议是确保在测试时定期保存 applicationHost.config,因为 GUI 偶尔会出现错误。至少对于 ARR v2.5 来说是这样,这是我在执行此操作时使用的版本。然后,您就有了可用的文本配置,每次您决定清理配置时都可以从中复制/粘贴。这将为您节省大量时间。
在 applicationHost.Config 中特别查找这些 XML 元素:
<rewrite>
...
</rewrite>
<webFarms>
...
</webFarms>
webfarms 部分是您在 gui 中定义的内容位置的最终位置,它本质上是反向代理负载平衡器的配置,其中 farm 是与一个或多个后端节点的虚拟服务连接。同样,rewrite 部分是您找到从哪个 farm 获取哪些内容的条件的地方。
下面是一个实际配置摘录,它并不完全符合您的用例,但无论如何都可以作为灵感。可能您只需要编辑第二个重写规则以匹配您的场景。所介绍的用例是当 IIS 用作两个后端农场的直通代理时,动态内容由“htmlFarm”提供,而对预定义静态内容(如图像)的请求则来自“imageFarm”。选择是基于 URI 的开头完成的。如果 URI 以 /images/ 开头,则将其视为静态内容并路由到“imageFarm”,否则将路由到“htmlFarm”。无论哪种情况,IIS 都将自己作为唯一的 Web 服务器呈现给客户端。简单的健康检查也以两种不同的方式进行,每个农场一种。这只是通过实验,我只是将其作为残余噪音包括在内,但仍然可能对您有用。
<rewrite>
<globalRules>
<clear />
<rule name="Route all to htmlFarm" patternSyntax="ECMAScript">
<match url=".*" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{HTTP_HOST}" pattern="(.*\.)?site01.com" />
</conditions>
<action type="Rewrite" url="http://htmlFarm/{R:0}" />
</rule>
<rule name="Route /images/* to imageFarm" stopProcessing="false">
<match url="images/.*" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
<action type="Rewrite" url="http://imageFarm/{R:0}" />
</rule>
</globalRules>
</rewrite>
....
<webFarms>
<webFarm name="htmlFarm" enabled="true">
<server address="192.168.50.77" enabled="true">
<applicationRequestRouting weight="100" />
</server>
<server address="192.168.50.78" enabled="true" />
<applicationRequestRouting>
<loadBalancing algorithm="WeightedRoundRobin" />
<healthCheck url="http://site01.com" responseMatch="Testing" />
</applicationRequestRouting>
</webFarm>
<webFarm name="imageFarm" enabled="true">
<server address="192.168.50.81" enabled="true">
<applicationRequestRouting weight="100" />
</server>
<server address="192.168.50.82" enabled="true">
<applicationRequestRouting weight="100" />
</server>
<applicationRequestRouting>
<healthCheck url="http://site01.com/images/test.txt" responseMatch="WillTest" />
<loadBalancing algorithm="WeightedRoundRobin" />
</applicationRequestRouting>
</webFarm>
<applicationRequestRouting>
<hostAffinityProviderList>
<add name="Microsoft.Web.Arr.HostNameRoundRobin" />
<add name="Microsoft.Web.Arr.HostNameMemory" />
</hostAffinityProviderList>
</applicationRequestRouting>
</webFarms>
同样,这不适用于您的用例,但无论如何:ARR 的一个限制是,即使具有 ARR 的 IIS 节点可以为后端提供冗余,但它本身也会成为单点故障。您需要两个或更多具有 NLB 的相同配置的 IIS/ARR 节点,或者在前面有一个单独的负载平衡器,才能克服这个问题。换句话说,Web 前端一如既往 :-)
我们最终放弃了 IIS/ARR,转而使用 Apache,但更多的是因为政治意外,这导致了办公室幽默的爆发。我真的不喜欢其中任何一个,因为我发现它们功能和性能都非常非常好。然而,与 IIS 相比,Apache 中的监控非常糟糕,我绝不希望这条评论会激起任何争论。这只是我的直接经验,尊重其他可能对这个问题的不同意见。
祝你好运!