使ISA的功能和特性得到完全的体现,需要客户端安装FWC。其实原本我都是用sNAT模式,后来因为要做基于AD的身份验证访问,所以需要用到代理方式,为了客户端能够快速的配置,决定分发FWC,但是因为其默认安装后是自动查找ISA服务器,那么就必须开启ISA的WPAD功能。于是经过几番周折终于实现了ISA的WPAD。
其实之前作完配置一直有问题时因为早期作AD迁移遗留下来的一个小问题及我恢复过DHCP保留造成的。后来解决也就正常了,但是考虑了一下还是做一个完整的配置记录比较好!
首先需要了解一下ISA的WPAD的感念(以下是引用微软MVP吕劼专栏中“深入探讨ISA Server的自动发现特性”的文字):
ISA Server是Microsoft开发的用于替代Microsoft Proxy Server2.0的最新代理服务器和防火墙产品,其强大的功能及易用性给不同规模的企业带来的很多显而易见的好处。因此,ISA Server也正在逐步的成为很多企业,特别的基于Microsoft网络的企业的首选代理服务器和防火墙产品。今天,朗月繁星想和大家一起来深入的研究一下ISA Server中的自动发现(AutoDiscovery)特性。
在一个全球性的企业里,网络覆盖全球的很多城市,在每个城市里或者站点里有很多ISA Server或者是ISA Server的阵列(Array)。工作在这个企业的员工有很大一部分是使用笔记本电脑来访问位于公司其他站点或者是Internet上的资源,我们知道如果一台客户机要访问位于ISA Server外端的资源就必须成为ISA Server的三种客户端之一,要么是SNAT客户端,要么是Web代理客户端,要么是Firewall Client客户端(以下简称FWC)。三种客户端的共同之处是要明确自己的代理服务器的位置,也就是要知道代理服务器的IP地址。然而,当一个移动用户从一个城市或者站点出差(漫游)到另外一个城市或者站点的时候,你该如何配置这些客户机使他们无障碍地访问Internet的资源?换句话讲你将做什么样的配置使这些移动的客户机顺利的找到提供代理服务的ISA Server?
我想读到这里的朋友可能已经猜到了,是的,没错!就是利用ISA Server的自动发现(AutoDiscovery)特性!这是一个令人振奋的功能,下面朗月繁星就来谈谈支持自动发现(AutoDiscovery)特性所涉及的一些技术要素。
如果您急于在网络中实现ISA Server的自动发现功能,你或许不需要了解过多的技术细节和讨论。这样,你可以直接参考设置“自动发现”之实施篇。
在此文中说的客户机和客户端是有区别的,客户机指用户使用的计算机,他可能使用Windows9x,Windows NT/2000或者其他Microsoft的操作系统,甚至是Linux;客户端指客户机操作系统上的某种应用程序或某种配置,例如,我们可以给Internet Explorer(以下简称IE)配置一个代理的信息,使之成为Web代理客户端;或者给用户的操作系统配置IP地址,网关以及DNS,这样这个操作系统就可以作为 SNAT客户端;如果您安装的ISA Server光盘中的Firewall Client,则运行在用户的操作系统上的网络应用程序的Winsock请求就会被FWC截获,从而做为ISA Server的FWC客户端。换句话说,客户机上可能存在多种客户端。此外,文中的domainsuffix.net指您的网络的DNS命名空间或者是您网络的域名称。在具体配置“自动发现”时,注意以您网络的所用的名称来代替domainsuffix.net。
自动发现(AutoDiscovery)特性的定义
自动发现是使ISA Server的客户端在不知道ISA Server的具体位置(IP地址)的情况下,通过网络上的其他网络服务来自动的发现ISA Server的IP地址及端口(Web代理客户需要知道提供Web代理服务的端口)的特性。
何种的客户端可以利用自动发现(AutoDiscovery)特性
我们知道ISA Server有三种客户端类型,在这3中客户端类型中,只有Web代理客户端和FWC可以利用自动发现(AutoDiscovery)特性,SNAT客户端不行!而且对于客户机使用的操作系统也有一定要求,客户机的OS必须是下面列表中的一种:
Windows98
Windows ME
Windows 2000
Windows XP
注意:不包含WinNT和Win95(Win95可以利用DHCP服务器发现ISA Server)
自动发现(AutoDiscovery)特性的机制讨论
之所以Microsoft称之为自动发现,足以证明ISA Server 的客户端在不经过“发现”这一过程前,是不知道代理服务器的具体位置的。那么,不难推断,在“发现”这一过程中,客户机肯定不是向ISA Server 来查询,所以就我的知识范围来讲,我想只有2种可以使用的方法来查找代理服务器ISA Server :一个是通过发送广播,另外一个是向某个公共的中心服务器来查找这个信息。最终Microsoft采取了后者,我想这也是明智之选,因为以广播的方式查找,对于网络的利用极其不利。以太网中广播是任何网络管理员应该避免的问题,说广播是网络杀手,我想不会有人有异议!在一个LAN(或者VLAN)中,所有节点都处于一个广播域,所以,当其中一个节点发送广播数据帧时,任何处于这个广播域的所有其他节点都会处理这个帧,尽管这个帧对于很多节点都是毫无意义的。如果在一个包含一个非常的大的冲突域的基于CSMA/CD的以太网中,广播会导致处于这个冲突域的其他节点,无法“抢夺”到传输介质,而导致暂时无法发送和接受其他数据的情况,直到这个广播被所有节点处理完成。
现在我们就来谈谈ISA Server的客户端是如何向中心服务器来查找代理服务器ISA Server的。这个中心服务器的角色可以是DNS,也可以是DHCP,或者是其两者(请放心,两者同时利用不会产生任何冲突,而是会提高发现ISA Server的机率)。Web代理客户端和FWC都可以利用DHCP和DNS来发现ISA Server。没有FWC只能使用其中之一(指DNS和DHCP),或者Web代理客户只能使用其中之一这样的限制。正是由于没有这样的限制,所以最终Web代理客户和FWC究竟是从DNS还是从DHCP来“自动发现”ISA Server的始终是我们困惑的问题。所以,朗月繁星分以下几种情况分析说明。
如果客户机不是DHCP Client,那么不论的Web代理客户还是FWC都是不能通过DHCP服务器“自动发现”ISA Server的,那么就只能利用DNS服务器。向DNS查询的条件就是:客户机配置了DNS。如果DNS服务器上的WPAD记录配置正确,则查询成功;如果DNS服务器没有配置DNS或者错误配置了WPAD记录,则查询失败。如果客户机是DHCP Clinet,这种情况,客户机具备从DNS和DHCP“自动发现”ISA Server,但至于是否可以完成“自动发现”要看DHCP和DNS服务器的设置。执行的过程如下,DHCP Client在引发“发现”这个过程时,它会向自己的DHCP服务器发送Inform消息,当DHCP服务器收到这个信息后,会给客户机发送ACK信息,这个信息告诉客户机到什么位置去得到配置信息的文件,这个配置文件的作用就是把客户机配置成为Web代理客户端或者是FWC,配置成功后,客户机就可以通过ISA Server来访问特定的资源了。如果DHCP服务器上没有配置252记录(也就是用于支持自动发现特性的252记录),但客户机配置了DNS,则客户机就会向DNS服务器查询wpad.domainsuffix.net,如果DNS配置了WPAD记录,则“自动发现”成功,如果DNS服务器没有配置WPAD记录,则“自动发现”失败。若客户机根本没有配置DNS,那么也会失败。这里还有一点要注意,如果DHCP服务器虽然配置了252记录,但是配置有错误,那么客户机也不会在向DNS服务器查询,所以,结果还是会失败!有关上边的论述,我做了一张流程图,如图1,大家可以参考。
接下来就是我的操作步骤:
我的环境:
ISASrv:Windows Server 2003 ST SP1,ISA2004,DCHP,WINS,WAN219.154.154.1,LAN192.168.0.1
ADSrv:Windows Server 2003 ST SP1,AD,DNS
XPClient:Windows XP Pro SP2
备注:之前此环境使用的是sNat方式,在客户端直接配置网关访问,ISA上直接作了条Allow 4 All(嘿嘿比较懒)。后来准备实施基于AD身份验证的访问规则,发现客户端就无法访问了,后来才想起来需要配置代理方式才可以,还是群里的哥们提醒!想了想直接安装FWC又方便又可靠。于是开始实施(之前并不知道WPAD),之后发现自动查找ISA服务器失败,才搜索资料找到了微软MVP吕劼的那篇文章,粗略的浏览了一下,看了主要的细节,其实还是很头大,干脆做着理解着算了!(昨天本来就头脑混乱,没想到下午下班前还试验成功了!)
1、准备工作:
其实也没什么准备工作可言,XPClient的IE默认连接我全部不打勾,直接通过网关访问,DHCP已经配置好了TCP/IP数据。ISA在部署的时候就选择了安装FWC并共享。我所做的就是进入AD管理中为OU建立一个策略,分发FWC。
2、配置DNS和DHCP支持WPAD:
WPAD可以用DNS和DHCP实现,推荐两者都作设置,这样ISA在实现WPAD更加准确有效。
(1)DNS方式:
进入DNS控制台,查找ISA服务器的A记录,如果没有就建立。(废话,我的ISA是成员,所以在DNS中存在它的A记录)。
之后,为这个A记录建立一个CNAME记录,命名为WPAD(注:一定要用这个WPAD名字,别问问什么微软的ISA自动发现就认这个名字)
理论上讲,到这里DNS下WPAD的设置就完成,客户端应该可以自动查询到ISA服务器,但是我这里的一些故障导致查询失败,所以就继续DHCP下WPAD的设置,浏览此文章的朋友可以自己试验一下。
(2)、DHCP方式:
首先进入DHCP控制台,单击DHCP服务器,右键选择“预定义的选项和值”,单击“添加”
之后在“名称”填写“WPAD”,数据类型选择“字符串”,“代码”填写“252”
然后点击“确定”,并为此选型类型定义值为“http://isasrv.office.local:8080/wpad.dat”(注:如果你只有一台ISA,那么这个值完全可以填写为IP方式,毕竟使用域名会增加一次对DNS的查询。另外wpad.dat必须是小写,因为ISA对他的名字大小写敏感。)
最后单击左侧选项中的“服务器选项”,右键选择“配置选项”,找到“252 WPAD”并购选,当完成这一步后,“作用域选项”中就自动添加上了此选择配置(在“服务器选项”上应用这个配置是一个高效的做法)。
3、设置ISA启动WPAD
进入ISA2004控制台,单击ISA服务器,选择“配置”-“网络”-选择网络下的“内部”-右键“属性”
之后切换到“自动发现”购选“发布自动发布信息”
最后切换到“防火墙客户端”,复查配置是否正确。(有网友提到如果将ISA服务器名称添写为IP,更加适合FWC客户端的查找,这里我依旧是用的是完整的FQDN,并且最终测试无错误!)
完成以上的配置,ISA2004的WPAD就完成了。在客户端配置FWC自动查询,你就可以查找到ISA服务器。
结尾,在完成这些配置后我这边的客户端依旧无法找到ISA服务器,最终在DHCP中找到了问题,我设置的保留中出现了错误的MAC绑定,正好影响了AD服务器。修正后我这边才算大功告成!!欣慰啊。
微软MVP吕劼的“深入探讨ISA Server的自动发现特性”这边文章的地址是:
http://www.microsoft.com/china/community/Columns/Lvjie/3.mspx