截至今天,这种诡异的问题已经是第二次发生了!

上次的随笔,我描述了在内网环境中,由于修改Forefront
TMG防火墙默认的访问规则,导致内网用户无法访问OWA的问题,非常的抱歉由于测试的不够仔细,得出的结论是错误的!虽然测试的过程和方法没有变化,但是最终导致问题解决的并不是Exehange
RPC server,在这里有必要详细描述一下:

问题描述:自从在Forefront TMG成功发布了Exchange
OWA后,邮件系统一直在正常使用,直道上月的某一天,分公司的员工突然告诉我登不上了,我检查一下后发现在内网同样如此。仔细检查了服务器上的邮件队列,发现其实邮件的接收和发送没有问题,只是OWA无法访问,找了N久,根据防火墙日志提供的一点点线索,找到了OWA连接的SSL证书这块儿,在OWA的站点绑定上一检查,惊异的发现443端口竟然没有绑定证书,重新绑定后一切正常。昨天下午,又出现了OWA不能登陆的问题,检查一下,果然又是这儿出了问题,上一次我还以为自己做了什么错误的操作,可是两次同样的问题,就显得诡异!事情到此还不算完,今天上午,分公司电话又来了,财务系统不能登陆了,我的财务系统使用了windows
2008中的TS Gateway,来实现C/S架构的系统的远程访问,结果是TS
Gateway的服务器找不到了,检查的结果,竟然同样是443端口绑定的证书不见了,变成了没有绑定任何的证书!我可以确认的是我没有对IIS做过任何的操作。我的所有的服务器使用的是Hyper-V的虚机,环境的唯一的改变是把原来系统自带的Hyper-V的管理工具,换成了SCVMM2008,也就是说,我在SCVM2008中将这些正在运行的虚拟机添加到了管理环境中,总不会因为这个就会导致绑定的证书丢失吧?况且上次我也没有搞这个SCVM2008。

导致内网用户无法访问OWA的真正的原因,是应为我的OWA并没有使用标准的443端口,因为外网网卡上用于TS
Gateway的侦听器已经使用了这个端口。TS
Gateway又不可能和Exchange是同一台服务器,因此为了同时发布两个SSL,我只能在ISA上扩展了SSL通道,把OWA的链接定义为侦听4433端口。外网的访问自然没有问题,但是我修改了默认的访问规则后,
只允许HTTP的流量通过到指定的目标URL集,结果就是来自本地的4433端口的SSL链接并不被接受,页面提示的总是链接有问题,也没有提示防火墙阻止,害的我一通好找。

明白了真正的原因,就有相应的办法:我创建了一个用户定义的协议SSL-Tunnel,指定端口范围为4433(从4433到4433),方向为出站,协议类型为TCP,然后在上次就讲过的允许DNS流量通过的访问规则中添加上这个协议,于是就能够打开OWA的页面了!

图片 1

相关文章