馅饼还是陷阱，TMG2010升级经验谈
从去年年底开始，我开始负责公司的ISA2006服务器升级项目，目标是把ISA2006升级到最新版的TMG2010 SP1。经过三个多月的努力，终于基本达到了预期目标。任务完成之余，回顾项目经历，有一些经验和大家分享一下，供有意升级ISA2006的朋友们参考。
一、TMG升级评估
现有的ISA2006是否需要升级到TMG?工程师只要想升级ISA2006，一定会被领导问这个问题。要回答这个问题，首先要评估升级后的收益。俗话说，无利不起早嘛。相比ISA2006，TMG2010的新增功能大致有下列内容：
1、企业级的安全整合和管理
2、架构变更与提升
3、Web非法软件扫描与过滤
4、路由架构改进
5、网络入侵保护系统
6、邮件安全传输与过滤
7、人性化管理与集成操作
这些功能乍一看都不错，但究竟能用到哪些，这就要结合自己的实际环境好好分析分析了。我们升级TMG主要是基于哪些考虑呢?首先，TMG的架构变更对我们很有吸引力。ISA2006使用X86架构，X86架构管理高性能服务器时有些力不从心。我们ISA2006服务器的硬件很好，4颗4核CPU的刀片服务器，16G内存，但ISA2006只使用了3G内存，让人感觉硬件资源浪费得很严重。ISAf2006升级到TMG之后，TMG2010使用X64架构，管理硬件资源要好上很多。至少内存使用达到8G以上了，感觉硬件利用率提升了不少，小赚了一笔。
其次，TMG提供的ISP冗余功能我们也很感兴趣。ISP冗余支持TMG服务器使用两条ISP链路，而且可以在两条ISP链路上选择故障转移模式或负载平衡模式。我们公司的业务对互联网有很强的依赖性，虽然我们选择的电信运营商可靠性不错，很少掉链子，但毕竟不能把鸡蛋都放到一个篮子里啊。所以对使用单ISP接入方案我们还是有些小小的忐忑不安，现在有了ISP冗余，那就可以选择两家可靠的电信运营商来设计一套高可用的ISP接入环境，这下就可以踏踏实实地把心放到肚子里了。
我们升级还有一个技术之外的原因，那就是我们的领导是微软的骨灰级粉丝，对微软产品的最新版本有非常浓厚的兴趣。一般来说，只要微软服务器出了SP1，基本上领导就要督促我们考虑升级问题了。这些年我们总是第一时间体验微软的服务器产品，积极升级，积极测试，积极排错，给微软产品改进做出了相当大的贡献啊。
看到这儿，有些朋友可能就要问了：“不对啊，TMG还有很多改进功能啊，怎么没听到你提啊，是不是你这家伙偷懒啊”?其实还真不是我偷懒，有些功能不错，但并不适合我们的环境。比如，网络入侵检测保护是个不错的功能，可是这个功能需要专门的许可证，是收费的，现在这年头，一提到钱就容易伤感情…..所以还是算了吧。再举个例子，Web非法软件扫描中包括了一个URL筛选功能，其实就是微软做的一个上网行为管理系统。这个功能看起来也不错，系统可以根据用户的访问地址，自动判断出用户是访问一个正常的商业站点，还是访问一个娱乐站点，甚至是访问非法的×××，×××站点。如果用户访问的目标地址异常，例如在上班时间访问playboy的网站，URL筛选可以自动限制用户的访问行为。这个功能看起来不错，可是我们测试了一下，发现这套系统对国内互联网公司的识别准确率实在是差点意思。在URL筛选中输入我们公司的网址，结果把我们这个金融公司识别成了房地产公司，这也就算了。我们再用www.163.net测试一下，居然把这个老牌的邮件运营商识别成了×××公司(目前这个问题已经被修正)，我们想了又想，实在是不敢启用这个功能。万一哪天这个功能导致用户无法访问正常的业务系统，我们就麻烦了。算了，不求有功，但求无过，还是别折腾了。大家一定要相信一点，稳定是压倒一切的!
说了这么多，其实就一个意思，ISA2006是否需要升级并没有标准答案，应该根据自己的使用环境，因地制宜地进行决策。如果目前使用的产品可以满足需求，新产品的功能又基本使用不上，那我的建议是可以考虑不升级，毕竟升级是有风险的，没有明显的收益就没必要去做了。如果目前的产品无法满足需求，而且我们又拥有升级所需要的资源(往往升级后对硬件资源的需求会提高)，那就不妨积极地体验一下最新版本带来的新功能。
二、TMG升级注意事项
ISA2006是32位的服务器产品，TMG是64位产品。因此，我们不可能从ISA2006就地升级到TMG2010，只能考虑把ISA2006的配置迁移到TMG2010。好在从ISA2006迁移到TMG2010并不困难，微软支持多种场景下的迁移方案。相比较从ISA2004升级到ISA2006，TMG的迁移方案可以设计得更加灵活。TMG的迁移要注意下列事项：
1、 TMG2010标准版可以升级到TMG2010企业版。也就是说，我们可以从ISA2006标准版迁移到TMG2010标准版，然后从TMG2010标准版再升级到TMG2010企业版。在ISA2006中，标准版和企业版差别非常大，企业版的配置存储在配置存储数据库(CSS)中，而标准版根本就没有CSS。因此ISA2006如果想从标准版升级到企业版，只能是先卸载ISA2006标准版，然后重新安装ISA2006企业版。在TMG中，标准版和企业版之间的鸿沟已经消失了，标准版也拥有CSS!从标准版升级到企业版，只需要输入一个序列号就OK了。看起来，TMG标准版和企业版的区别主要体现在版权上，技术上已经没有区别了。这种设计方案对企业其实更加有利，企业完全可以先购买低价的TMG标准版。如果随着企业的发展，标准版产品不堪重负了，企业可以从容地把TMG升级为企业版，完全没有后顾之忧!
2、 从ISA2006导出配置数据时，必须导出机密信息和用户配置数据，如下图所示。如果导出数据中没有包括加密的机密信息，TMG导入时会报错。另外，我们也不能仅仅导出ISA2006的防火墙策略，TMG也不支持这种导入方式。其实我们做TMG项目时最初仅仅想把ISA的防火墙策略迁移到TMG上，因为我们有些担心整体导入ISA2006的配置信息后会对TMG的健康状态产生影响。为什么这样说呢，主要是因为之前的ISA2006服务器上发生过一些莫名其妙的问题，例如只要一启用WPAD，就会影响用户连接WSUS服务器。这个奇怪的问题在微软开了CASE，微软也一直没有搞定，因此我们对ISA2006的健康状况就有些隐隐约约的担心。我们特别害怕ISA2006的这种亚健康状态会随着配置的迁移传染给TMG，这样我们可就没有退路了。以前ISA2006有问题时，大家总是很期盼地说：等到升级TMG就欧了!一旦TMG再有问题，那就要被群众扁死啊。所以啊,我们被迫在TMG上整体导入ISA配置后，立即在TMG上对防火墙策略单独进行了备份，以防万一。好在TMG导入ISA配置后工作得不错，到目前为止状态保持得还是相当稳定的。(图1)
▲
三、TMG新功能
1、ISP-R
ISP-R是TMG中一个非常好用的新增功能，我们对这个功能仰慕已久，可惜ISA一直没有提供这个功能。无数管理员曾经在论坛上无助地询问：ISA服务器能否使用两条ISP链路啊?答案是否定的!四年等一回，TMG终于给我们带来了ISP-R。现在ISP-R既可以利用两条ISP链路实现负载平衡，也可以实现故障转移。如下图所示，TMG服务器上同时使用了两条活动的ISP链路。(图2)
▲
使用ISP-R要特别注意DNS服务器的配置。ISP-R检测链路状态的方法是通过被检测链路随机访问DNS根服务器，如果访问成功，链路状态就是健康的;如果一连三次访问失败，TMG会把链路状态标注为不可用。如果你不想让TMG检测DNS根服务器，希望TMG检测一个国内的DNS服务器，你可以参考下列脚本进行修改。还有一点要注意的是，ISP-R只对NAT数据有效。也就是说，ISP-R对TMG本地主机是不起作用的。如果你希望TMG服务器通过电信的ISP链路访问电信的DNS服务器，通过网通的ISP链路访问网通的DNS服务器，你需要使用route add命令写静态路由。
Configuring verification of link status
In the default setting, TMG checks the status of the ISP link by trying to establish a TCP connection on port 53 (DNS zone transfer) to a list* of root DNS server on a round robin basis. If a connection can be established, TMG will consider the link active.
Although, the IP addresses and the TCP port used for the verification cannot be configured directly from the management console, If you need to modify these settings, e.g. because you setup your TMG server without direct access to the internet, you can do this by using the TMG COM, through simple Visual Basic script like this one:
Note: Please take an export of TMG configuration prior to running the script. To get the original behavior you need to import the original configuration
‘ ==================================================================
‘ we need to get the ISP Redundancy configuration object first:
set oRoot = CreateObject(“FPC.Root”)
set oArray = oRoot.GetContainingArray()
set oExternalNetwork = oArray.NetworkConfiguration.Networks(“External”)
set oISPRCfg = oExternalNetwork.ISPRedundancyConfig
‘ ===================================================================
‘ if you want to remove the complete list of connectivity verification
‘addresses:
oISPRCfg.ConnectivityVerificationRemoteIpAddresses.RemoveAll()
‘ To add a new address (in this case 192.168.1.1) to check the connectivity:
oISPRCfg.ConnectivityVerificationRemoteIpAddresses.Add “192.168.1.1”
‘ To change the TCP port for connectivity verification (default: 53)
oISPRCfg.ConnectivityVerificationRemotePort = 53
‘ To save the changes
oISPRCfg.Save
2、监控
TMG的报表功能得到了增强，我们可以在TMG中针对重要用户输出单独的访问报表。如下图所示，我们可以在TMG中创建用户活动报告，访问报告中将输出用户的访问内容，访问时间，访问类别等参数。我们既可以输出单个用户的访问报告，也可以针对多个用户进行输出。(图3)
▲
报告输出的效果如下图所示。通过这种报告，我们可以很容易地针对用户进行上网行为监控，辅导用户在上班时间合理使用互联网链路。(图4)
▲
四、TMG产品缺陷
微软的服务器产品以补丁总多而著称，因此大家在使用过程中慢慢有了这样一个习惯，如果一个服务器产品没有出SP1，一般不会考虑在生产环境中应用。但这次我发现即使有了SP1也不一定包打天下，SP1仍然会有一些缺陷，下面是我使用TMG2010 SP1的经历。
TMG2010安装完成后，我马上在第一时间安装TMG2010 SP1。SP1安装完成后，立刻发现重启服务器后10多分钟还没能进入系统，我的冷汗立刻就流下来了。额的娘啊，不会刚打完SP1就崩溃了吧。还好，又等了几分钟，终于进入系统了，最奇怪的是，查看一下还没有发现有什么错误，难道TMG要休息一下?感觉去微软论坛看看，这才发现有类似问题的还大有人在，看来这是TMG2010 SP1的通病。解决方法微软也提供了，TMG2010 SP1 Update1就可以解决这个问题，打了Update1之后，TMG算是恢复正常了。只能感叹这个TMG2010 SP1是怎么测试的，难道测试时没有重启过系统?
TMG服务器安装完成后，我们使用两个TMG服务器组成了一个阵列，然后又配置了负载平衡。负载平衡的效果非常好，1500个用户，分布在两台服务器上的人数分别是740和760。但是，在TMG的控制台上观察，发现目前只使用了第一台TMG服务器的Web缓存，第二台TMG服务器的Web缓存利用率为零。Web缓存非常重要，这可不是闹着玩的，我赶紧对TMG服务器上的缓存内容进行检测。如果想检测TMG的缓存内容，可以去微软下载TMG Tools。TMG Tools中有一个名为Cachedir的工具，可以实时查看TMG服务器的缓存内容。我用Cachedir检查了两台服务器，发现内容很正常，而且两台服务器缓存都有用户访问。那TMG控制台上又怎么解释呢?查了半天，也没有结果，算了，去微软开个CASE吧。还好，微软很快就在测试环境中复现了这个故障。过了几天，微软工程师正式答复：这是个产品Bug，这个CASE我们免费。现在我们只能等产品组出Hotfix，但什么时候能提供hotfix，就没有具体的时间表了，请您耐心等待…我又奇怪了，这个现象非常明显啊，难道一直没有针对阵列进行测试?这微软到底是怎么做产品测试的!
过了一段时间，SCOM服务器也开始来找麻烦了。SCOM服务器基本每天都会报几个TMG Web缓存的错误，大致内容是这样的：
警报: Forefront TMG 服务器 - 缓存： “当前每个请求的缓存提取平均毫秒数”错误
来源: Caching - HQ-TMG2
路径: HQ-TMG2.chamc.com.cn
上次修改者: 系统
上次修改时间: 2011/1/19 19:04:18
警报描述: 800.375927734375
这个警报并不复杂，意思是SCOM服务器三分钟内随机统计了5个客户机向TMG服务器发起一个Web请求后所需要的平均响应时间，TMG服务器发现客户机平均需要经过800豪秒才能从TMG服务器收到回应。这就有些不对了，SCOM服务器认为这个平均值应该在300毫秒以下。考虑到客户机发起请求后，如果请求的内容在TMG的Web缓存中，那响应速度应该在10毫秒以内。因此，看到这个警报，我就考虑是否TMG的缓存性能出现了问题。可是，我很快就发现一个难以自圆其说的现象。SCOM服务器发起这个警报的时间，基本都是在夜间或双休日，工作时间内反而没有警报。那就不对了， TMG服务器应该在工作时段负载重啊，怎么反而在工作时段没有这个警报呢?没辙了，再去微软开个CASE吧。微软工程师的水平还是挺高的，查了一番资料后给了我一个挺好的解释：是这样的，如果用户访问的内容在TMG的缓存中，那TMG的响应速度是很快的;如果用户访问的内容不在TMG的缓存中，例如用户下载文件，或者用户使用视频点播，这种情况下TMG就得先从互联网服务器下载数据，然后才能响应用户，这样响应时间就会很长，需要上千甚至上万毫秒都有可能。在工作时间内，很多用户提交的Web请求都可以在TMG缓存中得到响应，因此缓存的利用率高。平均一下，每个用户提交Web请求所需要的平均响应时间就会非常短，SCOM就不容易报警。非工作时间呢，使用TMG服务器的用户少了，TMG的Web缓存利用率就低了，用户的Web请求就不容易从TMG缓存中获得响应(你可以想象一下，非工作时间用户访问的是神马内容)，因此统计出来的平均响应时间就长，这时就有可能触发SCOM警告了。
听了微软的解释，我觉得豁然开朗。哦，原来TMG服务器的缓存性能没问题，这时好事，值得高兴啊。但是，但是，仔细一想就不对了，TMG服务器没问题，你SCOM报什么警啊!存心骚扰是不是?我向微软的工程师咨询：既然如此，SCOM的这个警报到底有什么意义呢?这回轮到微软的工程师张口结舌了，只能推说要和产品组反映这个问题，然后给我答复。过了几天，微软工程师来电话了：经过和产品组确认，确定这又是一个产品Bug!解决方法是等待产品组的Hotfix，Hotfix没出来之前建议先把SCOM的这个警报禁用，免得收到无意义的警报。既然是Bug，那这个CASE还是免费的…
五、TMG升级总结
虽然TMG产品还存在一些小缺陷，但不能否认TMG相比之前的ISA2006还是有很大进步的。至少在产品稳定性方面，TMG比ISA2006强大了很多。以前我们使用ISA2006时，隔上一段时间就会出现ISA2006不堪重负，不工作了，必须重启服务器才能恢复正常。×××用户也经常抱怨ISA的稳定性不佳，时常掉线。升级到TMG之后，这些问题再也没有出现过。三个月以来TMG坚如磐石地提供着Web代理，服务器发布，×××接入等服务，尽情地显示着64位系统的优越性。总体来看，TMG2010做为新一代的企业级路由防火墙，在产品架构，防火墙核心性能，安全防护，稳定性方面比前一代产品都有了本质上的提高。如果硬件条件许可，我们建议还是尽可能把ISA2006升级到TMG2010，TMG不会令你失望的!
