最近在运维过程中,遇到了两个历史悠久而且截然不同的疑难问题。但巧合的是,两个问题殊途同归,最后居然使用了同样的解决方法。为了庆祝送别这两个问题,也为了和大家共同学习,共同进步,现在把解决问题的详细过程献出来和大家分享。
先对问题进行一下描述啊。第一个问题就是MSN无法登录!估计很多朋友看到这个题目就要暗自点头,大有一见如故的感觉。这个问题非常普遍,在我们公司更是由来已久。无论用户的级别高低,无论使用的MSN版本新旧,总有一部分不和谐的用户会跑来反映自己的MSN无法登录。按理说,即时通讯软件很不受网管待见,应该学会在夹缝里求生存,登录方式应该手段繁多,花样翻新。什么封装成HTTP,HTTPS,什么通过Web代理,Socks代理,加密代理登录等等,应该让网管觉得MSN登录真是防不胜防,堵不胜堵才好。可MSN倒好,我们还没想限制呢,它先自己顶不住了。
为了解决这个问题,劳动人民可是想了不少主意,大家上网搜了不少办法。什么导入证书法,什么在浏览器中勾选自动检测设置啊,这些方法倒也不是一无是处,可奇怪的是有些办法在张三的机器上行,在李四的机器上就不行,搞来搞去,也没有一个通用的解决办法。最可气的是有些用户第一天能登录,第二天就不能登录了,搞得大家每次登录MSN时心情都忐忑不安,充满了憧憬和期待。以前在MSN中配置代理服务器登录还是比较靠谱的一招,我们在TMG服务器上也配置了防火墙策略,希望用户通过HTTPS协议登录MSN服务器。可后来配置Web代理基本上就毫无作用了。很长一段时间以来,遇到用户无法登录MSN,大家都很头疼去进行技术支持。对比一下吃苦耐劳,从不挑肥拣瘦的QQ,这MSN跟别人的差距可真不是一星半点。
第二个问题也是一个老问题了,WPAD和WSUS之间有冲突。这个问题听起来挺匪夷所思的,WSUS是干嘛的,WSUS是用于给客户机自动更新微软补丁的;WPAD是干嘛的,WPAD是自动在客户机的Web代理或防火墙客户端上配置代理服务器的。咋一看这两者之间没什么关联,可奇怪的是只要一启用WPAD,客户机能自动发现代理服务器的同时会立即和WSUS服务器失去联系。为了解决这个奇怪的问题,我们在微软特意开了CASE,可微软抓了不少包进行分析,最后也没分析出什么结果。结果呢,这个CASE就一直挂在那了。问题没解决,我们只能在WPAD和WSUS之间选择Kill一个了,WSUS是负责更新补丁的,安全问题应该优先保证,所以只能委屈一下WPAD了。
介绍完现有的问题后,再来介绍一下是怎么解决问题的。我们先在MSN问题上找到了突破口,查询微软Technet三月份的安全博客时,忽然发现有篇文章介绍MSN登录原理,文章提到如何希望MSN通过代理服务器登录服务器,仅仅配置Web代理是不够的,MSN只是在完成登录的部分工作时使用到Web代理!注意,这也就意味着如果仅仅在MSN中配置下图所示的Web代理,是无法完成MSN登录的。
通过在客户机上抓包分析,发现MSN登录时要做很多工作,要联系一些*.microsoft.com的服务器,要联系一些*.hotmail.com的服务器,还要联系一些*.live.com和*.msn.com的服务器。当MSN访问这些服务器时,有部分工作可以由Web代理完成,但有些工作是不能通过Web代理的。那剩下的登录工作应该交给谁呢?答案是Winhttp代理!
Winhttp代理和Web代理是两套不同的代理机制,我们在浏览器中配置的代理服务器属于Web代理,那Winhttp代理应该如何配置呢?其实在Win7计算机中使用Netsh就可以轻松配置,如下图所示,我们在Win7客户机中以管理员身份运行一个命令提示符,然后输入:Netsh Winhttp Set Proxy proxy.chamc.com.cn:80。这条指令的目的就是把我们当前使用的代理服务器proxy.chamc.com.cn设置为Winhttp的代理服务器。
设置了Winhttp代理后,果然效果不凡,大家的MSN纷纷能够成功登录了!真是不容易啊,这个该死的微软,居然画蛇添足地设计什么Winhttp代理!群众中有几个人懂这个啊,都使用Web代理不就完事了嘛,这些程序员到底有木有脑子啊!大家正在义愤填膺地谴责微软,忽然有同事发现新问题了。只要在计算机上配置了Winhttp代理,就无法访问WSUS服务器了!
检查一下计算机c:\windows\windowsupdate.log文件,可以发现客户机访问WSUS服务器时的日志内容,日志中有这样的语句DownloadFileInternal failed for http://hq-sus/selfupdate/wuident.cab: error 0x801901f6。这种错误提示和配置WPAD后的错误提示完全相同,这种情况下我们就提高警惕了,为什么WSUS和Winhttp代理之间也有这种兼容性问题呢?
通过查阅资料,发现原来WSUS客户端在访问WSUS服务器时,也是要调用Winhttp代理进行通讯的。由于WSUS客户机和WSUS服务器同在TMG的内网,因此WSUS客户机应该直接访问WSUS服务器,根本不应该客户机先访问到TMG服务器,然后再通过TMG服务器访问WSUS服务器!找到问题之后,怎么解决呢?其实解决方法也很简单,在netsh Winhttp中设置旁路列表,告诉Winhttp代理,访问WSUS服务器不用经过Winhttp代理,这样就可以了。例如WSUS服务器是hq-sus,那么我们就可以在客户机上输入如下图所示命令:Netsh Winhttp set proxy proxy.chamc.com.cn:80 “hq-sus”。这条指令就是通知Winhttp代理,访问hq-sus服务器可以直接访问,不用经过Winhttp代理了。如果有内网其他的服务器要排除,可以用分号隔开。
在客户机上配置完Netsh Winhttp后,问题解决了。用户可以登录MSN,也不会和WSUS有冲突了,问题貌似圆满解决啊!但是,但是,问题好像还留了一个小尾巴。为什么WSUS和WPAD当初会有冲突呢?难道也是类似原因导致的。在微软网站找资料!找啊找,找啊找,嘿嘿,功夫不负有心人啊,真的被俺找到了。原来Winhttp代理除了可以通过Netsh Winhttp进行配置,还可以通过WPAD进行自动配置。但是,当Winhttp代理通过WPAD下载wpad.dat文件进行自动配置时,由于wpad.dat文件中没有对wsus服务器进行排除,因此WSUS客户端通过Winhttp代理就不会直接访问WSUS服务器。而是需要通过TMG代理服务器去访问WSUS服务器,这样当然是不行的!
搞清楚道理,问题就好解决了。只要在配置WPAD时把内网的WSUS服务器排除之外就OK了。在TMG服务器上打开管理控制台,找到“网络连接”-“内部”-“属性”中的“Web浏览器”标签,如下图所示,把WSUS服务器hq-sus添加到直接访问的列表中,这样WPAD就会通知使用Web代理或Winhttp代理不要通过代理服务器访问WSUS服务器,如果还有其他的服务器要排除,参考这种操作就可以。
排除的服务器可以通过TMG服务器上的wpad.dat文件体现出来,我们可以使用浏览器从TMG服务器上下载wpad.dat文件查看排除服务器列表。如下图所示,我们使用记事本打开TMG服务器上的wpad.dat,可以看到WSUS服务器hq-sus已经被排除使用代理服务器访问了。
现在,通过在WPAD中设置排除服务器,WPAD可以启用了。用户的Winhttp代理可以通过WPAD自动获取配置,不需要通过Netsh Winhttp进行配置。现在,用户登录MSN,访问WSUS服务器都没有问题了,非常和谐。从这个问题中,我们可以得出两个结论:第一是不要迷信微软,微软的产品之间也会有兼容性问题;第二是一定要相信微软,问题最终还是可以解决的。
本文来源:不详 作者:佚名