反向代理WEB站点的步骤

由于在公司的IDC（因特网）上开发了几个分析/统计工具软件用WEB发布，所以安全性特别地被美国的经理提起（特别从被某大公司收购后，公司对安全性要求越来越高，越来越严格）。基本上在软件层面上，需要授权的地址域，公司办公域用户，软件内建的用户数据库几层保护。并且最好不要对IT管理员提什么要求，尽量在应用层上解决。

一开始，被建议的思路是在内网建一个IIS服务器作为转发/代理IDC里WEB服务器的请求。IIS集成NT域，但是在转发/代理时，发现只能作跳转，无法KEEP连接的SESSION/COOKIE等，不是真正的代理机制。不知是MS的软件总是太在意易用性，而忽略这么实在的功能了，还是我没有研究透（也没有花时间去研究，在网上找了例子试验后没成功就放弃）。

想到APACHE的开放性设计，用其作代理应该不需要太多的设置。结果一下子在APACHE配置文档上就找到转发代理/反向代理的配置（ [url]http://httpd.apache.org/docs/2.0/mod/mod_proxy.html[/url]）。所以问题就变成在代理APACHE服务器上实现NT域认证机制了， 这个可是很多实例的了，同样的APACHE配置文档也提到，我还是用CGI的模块（ [url]http://search.cpan.org/~chansen/Authen-Simple-LDAP-0.2/lib/Authen/Simple/ActiveDirectory.pm[/url]）来实现了。

接下来的问题是，SSL连接存在证书问题无法代理，域用户和软件内建用户库的对接问题。第二个问题用代码来实现估计不难，第一个问题不知是不是需在代理LINUX上安装证书？还是需其他的设置，正在进行中。。。

 

关于转发代理/反向代理的概念，在此说两句，提醒自己不要混淆：转发代理是客户浏览器上所设代理的响应服务器。也就是代WEB CLIENT转发请求（请求是真实的URL，但其无法直接到达）来实现隔离/连接的方法；反向代理则是把所有客户端发往自己的请求转到受保护的服务器来处理，并把响应结果再转发给CLIENT端。其实两种代理都可以解决上述问题，只是转发代理需要客户端来回配置代理（防止代理服务器太忙），没有反向代理来得直观。

本文转自 dannyy1026 51CTO博客，原文链接:

http://blog.51cto.com/dannyyuan/38560