利用IP别名托管多个SSL站点

    人们对于结合使用 SSL 和基于名称的虚拟主机的兴趣与日俱增。有些人认为这是不可能的，但是在 Apache 中，您可以通过基于 IP 的虚拟主机实现虚拟主机。在这篇文章中，John Liao 和 Jim Miles 将为您介绍具体做法。

    在以前的 developerWorks 文章 “Secure remote data access for Domino®” 中，我们讨论了如何利用 Apache Web 服务器以节约预算的方式解决企业问题。（参见 参考资料 中的链接。）在本文中，我们继续讨论这个主题，解释在一台通过一块物理网卡连接到网络的服务器上，如何使用 Apache Web 服务器提供多个 Secure Sockets Layer（SSL）Web 站点。

    为什么需要在一台服务器上安置多个 SSL 站点？确实有企业需要在一台服务器上托管多个 SSL 站点吗？我们将通过一个真实的场景来解释这些问题。有创新精神的用户肯定会为这种思想找到更新颖的用途。

案例研究：两个应用程序，一台服务器

    在我们公司早期的一个项目中，人力资源（HR）部门希望为一个基于 Web 的福利应用程序提供外部互联网访问。用户大多是从公司网络内部访问这个 Web 应用程序的，但是偶尔也会通过外部互联网访问它。为了满足安全需求，我们决定将这个应用程序放在公司网络内部的一台服务器上，使用 Apache 的 HTTP 服务器构建一个反向代理服务器。反向代理服务器会终止 SSL 连接，再重新打开另外一个到托管 HR 应用程序的 Web 应用服务器的 SSL 连接。通过在 Apache Web 服务器中添加 mod_security 模块，即可将反向代理服务器改为应用网关，并为 Web 应用程序提供更高的安全性。HR 部门精心挑选了一个完全限定域名（FQDN），这个域名是用户友好的，易于记忆。随后，我们继续向前推进，获得了 SSL 证书，我们认为一切就这样圆满结束了。

    一年的时间很快就过去了。另一个企业 Web 应用程序出现了，它的需求与 HR 应用程序极为相似。它也需要为外部用户提供访问能力。外部用户的数量非常少。大多数访问都是在公司网络中进行的。我们立刻想到使用反向代理服务器为这个新的 Web 应用程序提供外部访问。

    但是，这个新的应用程序有点儿麻烦。首先，我们很关心数据中心的物理空间，竭力在一切应用程序的部署中寻求整合服务器的机会。其次，我们必须证明购买额外的反向代理服务器是值得的。这两个因素结合在一起，促使我们仔细研究如何使用现有的反向代理服务器满足新 Web 应用程序的需求。惟一的问题是，这个应用程序需要一个与现有 HR 应用程序不同的 FQDN。

    我们研究了几种为新的 Web 应用程序使用现有反向代理服务器的方法。第一种想法是，将新旧两个应用程序的域名都改为某个通用域名，比如 rp.company.com，并用上下文路径区分这两个应用程序。但是，原来的反向代理服务器用户强烈反对改变域名。如果改变域名，他们必须将域名变更情况通知公司中的所有人，还要修改所有印刷资料，以反映新的 URL。改变域名的成本非常高，而且可能会影响客户支持部门，他们不可避免地会收到大量用户投诉。另外，两个应用程序组都希望保留自己的 FQDN，他们认为自己精心选择的 FQDN 比这种一般化的 URL 更醒目，而且也是宣传推广这些 Web 应用程序的有效手段。

    另一个想法是：为什么不注册一个 DNS 入口，让它将新的域名指向现有的服务器？这个想法很快就被否决了。在 SSL 应用程序中，SSL 证书必须与用户请求的 URL 匹配，否则会弹出一个警告消息，指出所请求的 URL 与 SSL 证书的域名不匹配。由于弹出式广告和恶意软件日益猖獗，公司中每个训练有素的人都会取消产生弹出警告框的 Web 交互。根据公司架构标准的要求，生产性 Web 应用程序严禁生成弹出警告消息。

    另一个建议是：使第二个 SSL 站点驻留在运行第一个站点的服务器的不同端口上。但是，我们觉得这会给用户带来过多的困扰，用户很难同时记住站点 URL 和端口号。如果用户只输入 URL 而没有输入端口号，他们就会被重定向到 HR 应用程序。这会导致很多问题。

解决方案：IP 别名

    最终敲定的解决方案是 IP 别名（IP aliasing）。在寻找这个解决方案时，最需要技巧的部分就是确定正确的术语。最初引入这个概念时，我们听到了虚拟接口（virtual interface） 和虚拟 IP（virtual IP） 等术语。我们艰难地寻找着关于这些概念的信息；但我们最终意识到，我们正在寻找的东西是通常被称为 IP 别名功能的概念，这帮助我们找到了关于该主题的更多文献。