本站域名：http://goxia.maytide.net or http://sufan.maytide.net
移动设备请访问：http://goxia.maytide.net/m转载文章，请务必保留出处与作者信息，未经许可严禁用于商业用途！
[TMG] 经验分享：因操作系统与TMG网络适配器配置信息未同步引发的网络访问故障
经验分享：因操作系统与TMG网络适配器配置信息未同步引发的网络访问故障
前段时间在协助一家企业进行 TMG 的评估工作，大致的环境是在位于两个城市的中心机房各部署一套 TMG，并使用 PPTP 实现了 Site-to-Site VPN，从而将两地的 IT 环境相联。但是遇到了一系列的诡异问题，特与大家分享一下。
初期的测试都是非常顺利的，但是在运行一段时间后，评估环境内的用户反应有某银行的网上银行站点无法访问，通过 Live Log 以及 Network Capture 对一系列访问数据进行分析发现 Live Log 中记录的都是 RST对方银行使用了某种网络优化手段，对子站点实施了线路优化，但是又有违常规，简单说当用户访问“http://www.xxxbank.com”时对应的是一个 IP 地址，但是当通过该站点页面访问二级目录“http://www.xxxbank.com/enterprise”时却会被重定向到另外一个 IP 地址上。
利用 ping 等命令也做了简单的测试，发现“www.xxxbank.com”是别名解析，对应的是“www.lc.xxxbank.com”，而这个域名会自动识别用户 IP 来重定向到对应的另一个主机域名->网络 IP。这一系列的访问过程却让评估环境下的 TMG 用户出现了无法访问的故障，而这一故障并不是一直会重现，偶尔能够正常访问。当错误发生时在 Live Log 中能看到是因为 RST 相关的错误，此外在 TMG 本机访问银行是没有问题的，如果将客户端配置为 Web Proxy 便能恢复正常。
而在另外一个城市的 TMG 环境下测试发现均未出现此类的故障。但是两地解析域名所得到的 IP 会有所不同，问题出在了哪里呢？！曾经与银行方面也联系过，未果！后来在微软技术支持工程师的帮助下了解到，TMG 在创建 Site-to-Site VPN 后，会将对端网络中的 DNS 作为本机的主 DNS，那么就会出现 TMG 本机上访问网站时得到的解析结果是 VPN 对端网络里的 DNS Server 给出的，而本地 TMG 后端的用户解析则是本地 DNS Server 给出的，其结果将会得到两个解析数据。
之后在“路由和远程访问”中对 VPN 拨号连接进行了设置，将 TCP/IP 下的 DNS 手动改为 TMG 本地网中的 DNS Server 地址，随后的一段时间里访问看起来是“正常了”。
果然，好景不长！评估环境的用户又反应访问某市公安局网站（也实施了线路优化）时无法访问，这次即使为客户端配置 Web Proxy 也无济于事，同时在 TMG 本机测试也无法访问，问题到底出在哪里了呢？！从早期检测到的 RST 未返回数据包到 FIN 三次握手失败等一系列的故障看，TMG 自身一定是存在问题。先后在多个 TMG 环境下对比测试，排除了 TMG 软件设计方面可能存在的不兼容问题，那么就要将注意力集中到这台 TMG 配置上。
最后发现，在 TMG 网络适配器中，当前外网的网卡默认 IP 与操作系统的外网网卡默认 IP 不同（注：TMG 外网绑定了多个 IP 地址），问题可能就出在这里。当 TMG 访问外部时，可能使用系统配置的 IP 作为宿主，但是客户端访问时却使用了 TMG 配置的 IP，这有可能就是引发 RST 和 FIN 问题的最终原因。随后将两个配置信息重新修改一致后，所有的访问都恢复了正常，之前的故障未在出现！
但是，引发数据不同步的原因一直不明，回忆之前的部署过程，有过两个管理员同时配置 TMG，而服务器也因为内存问题出现过故障，还导致 TMG 缓存配置与数据库不一致的问题。目前评估工作一直在进行着，最近又接到通知 TMG 在华停止销售，因为销售许可到期，不过听闻也许在五月底就能恢复销售！
总之，TMG 作为一款受青睐的企业级的网络安全和加速产品，在华业务任重道远……
[TMG] 解决 TMG 服务器日志报 ADWS ID1202 错误的问题
解决 TMG 服务器日志报 ADWS ID1202 错误的问题
Forefront Threat Management Gateway（TMG）2010 需要 ADAM 支持，因为它将配置信息都存储在 ADAM 中！所以在正式安装前需要执行“运行准备工具”，而这个阶段会根据用户的选择（安装”Forefront TMG 服务和管理”） 安装必须要的组件支持，如“Active Directory 轻型目录服务”即：AD LDS，用于存储 TMG 配置数据。
但是，在部署完 TMG 之后，我们会在“应用程序和服务日志”下的“Active Directory Web Services”中看到产生了很多的错误日志，如下图所示：
仔细查看日志，来源“ADWS”，事件ID“1202”，大致内容“现在该计算机正在托管指定的目录实例，但 Active Directory Web 服务无法为其服务。Active Directory Web 服务将定期重试该操作。……”
搜索了 Microsoft Support 未找到任何线索，考虑到本机未安装有 Web 服务，所以果断在“服务”管理器中将 Active Directory Web Services 服务禁用（sc config adws start= disabled）。重新启动 TMG 错误日志消失，系统和应用程序工作正常，未发现不良影响！至此问题解决！
[TMG] 解决因 TMG 配置数据不完整引发的 MMC 操作故障
解决因 TMG 配置数据不完整引发的 MMC 操作故障
最近遇到一个 TMG 故障，在使用 TMG 控制器进行配置操作时没有问题，但是保存时提示错误，仔细查看发现在规则列表中竟然有两个规则只有名称而没有其他配置信息，当去操作或查看时会报下面的错误截图，导致无法对 TMG 进行操作和修改。
回忆一下之前的操作，极有可能是因为两个管理员同时配置 TMG 在保存时，配置数据未能同步，从而引发了此故障问题。之后给微软开了 Case，提出了两个解决办法：
- 使用 TMG 光盘对安装进行修复。（PS：感觉这个解决办法风险太大，首先要暂停网络访问，而且可能会导致之前的规则丢失。）
- 直接操作 TMG 配置数据库，从数据库中删除不完整的规则。（PS：我个人认为这是一种可行的办法，但是直接修改 TMG 数据库的风险也很大，而且要找到规则对应的 GUID。）
最终选择了第二种解决方法，现在要解决两个问题：如何访问到 TMG 配置数据库；如何确认规则所对应的 GUID。前者，微软工程师给了连接到 TMG 配置数据库的方法，可参考 gOxiA 之前些的日志《使用 ADSI 访问 TMG 的配置数据库》。而后者，gOxiA 尝试导出 TMG 的规则，进行查看果然找到了规则对应的 GUID，如下图所示：
其中“StorageName”便是规则所对应的 GUID，而且知道规则隶属于“PolicyRule”，接下来参考《使用 ADSI 访问 TMG 的配置数据库》去操作 TMG 的配置数据库（ADAM），如下图所示：
展开 CN=FPC2，CN=Array-Root，CN-Arrays，CN=GUID，CN=ArrayPolicy，CN=PolicyRules。从字面上不难理解这些项的意思，但是其中 FPC2 表示 TMG 的配置数据库，而导出的规则文件中则为 FPC4，gOxiA 个人认为可能是微软为了区分数据等级，将 FPC2 认定为本机配置，FPC4 为备份配置。
由于 TMG 的 ADAM 无法查询或筛选，要从 PolicyRules 下找到其 GUID 也确实是件难事，gOxiA 用了一个比较笨的办法，就是先导出列表，然后使用带有标注行号的编辑器打开导出的列表文件进行搜索。一旦找到对应的 GUID 便根据位置靠上从上数的原则确定在第几行，然后再到 ADSI 中去定位！
最终结果当然是令人满意，未使用修复安装便解决了此故障！ 如果有遇到同样问题的朋友，可以借鉴一下，希望会有帮助！此外，建议对 TMG 有兴趣的朋友可以看一下《TMG Storage》这篇文章，有介绍 TMG 的配置存储机制。其中就讲到了 TMG 还会在注册表中缓存一份配置信息，如果要重建注册表中的配置缓存，可以使用下面的办法：
- 首先在 CMD 中执行如下命令行：reg add HKLM＼SOFTWARE＼Microsoft＼RAT＼Stingray＼Debug＼ISACTRL /v CTRL_MIXER_CACHE_BUILD_NEW_IN_NEXT_UPDATE /t REG_DWORD /d 1 /f
- 然后重启 TMG 服务
- 最后再在 CMD 中执行如下命令行：reg add HKLM＼SOFTWARE＼Microsoft＼RAT＼Stingray＼Debug＼ISACTRL /v CTRL_MIXER_CACHE_BUILD_NEW_IN_NEXT_UPDATE /t REG_DWORD /d 0 /f
