来源:互联网 时间: 2006-04-11
关于服务发布中请求转发选项的说明
在ISA防火墙中发布任何服务时，发布规则属性到标签中具有一个请求转发选项，如下图所示：
它具有以下两个选项：
使请求显示为来自 ISA 服务器计算机；
使请求显示为来自初始客户端。
那么，它们之间的区别是什么呢？
其实它们的含义可以从选项的字面意思上进行理解：
如果你选择使请求显示为来自 ISA 服务器计算机，那么当其他客户访问ISA防火墙所发布的服务时，ISA防火墙在转发原始客户所发送的请求数据包时，会将IP数据包的源IP地址修改为自己转发此请求IP数据包的网络接口的IP地址。此时，被发布的服务只是认为连接请求是由ISA防火墙发起的，它不会知道发起原始连接请求的原始客户的任何信息，并且被发布的服务器无需知道如何到达原始客户（无需具有到达原始客户的路由），只需要知道如何到达ISA防火墙转发请求IP数据包的网络接口即可。在发布Web服务时，此选项是默认选项。
如果你选择使请求显示为来自初始客户端，那么ISA防火墙在转发原始客户所发送的请求数据包时，不会修改IP数据包中的源IP地址（保留原始数据包中的源IP地址）。此时，被发布的服务认为连接请求是由原始客户发起的，为了响应原始客户的连接请求，被发布的服务器必须知道如何将响应数据包回复至原始客户（具有到达原始客户的路由），并且此响应数据包必须通过ISA防火墙进行转发。这样写起来略显深奥，你可以这样认为：由于原来是通过ISA防火墙将原始客户的请求数据包发送至被发布的服务器，所以当被发布的服务器回复响应数据包到原始客户时，必须同样通过ISA防火墙来进行转发，否则，原始客户和被发布的服务之间的通讯将会失败。大部分情况下，你可以通过将ISA防火墙配置为被发布的服务器的默认网关来实现这些要求；如果不能将ISA防火墙配置为被发布的服务器的默认网关，你必须配置被发布的服务器使用ISA防火墙作为到达原始客户的网关；如果ISA防火墙和被发布的服务器之间还具有多个子网，那么ISA防火墙必须作为被发布的服务器到原始客户之间的路由链上的一个节点。在发布除Web服务外的其他服务时，此选项是默认选项。
有许多朋友在论坛提问，说在发布服务的时候，如果在请求转发选项中选择使请求显示为来自 ISA 服务器计算机，那么外部客户就可以访问发布的服务，如果选择使请求显示为来自初始客户端，则外部客户就不能访问发布的服务了。对于这个问题，就是没有满足上面的条件：被发布的服务器必须知道如何将响应数据包回复至原始客户（具有到达原始客户的路由），并且此响应数据包必须通过ISA防火墙进行转发。
下面我来模拟一下这个现象，我的内部网络是10.2.1.0/24，ISA防火墙Istanbul作为边缘防火墙，在此例中我将发布内部网络服务器Munich上的RDP服务。
Istanbul（ISA防火墙）：
内部接口：
IP地址：10.2.1.1/24
默认网关：None
MAC地址：00-03-FF-0F-5F-C5
外部接口：
IP地址：192.168.1.201/24
默认网关：192.168.1.201
Munich（内部RDP服务器）：
内部接口：
IP地址：10.2.1.8/24
默认网关：None
MAC地址：00-03-FF-43-5F-C5
外部测试RDP客户
外部接口：
IP地址：192.168.1.6/24
默认网关：None
我创建的发布规则如下，但是，我在外部网络却无法访问发布的RDP服务。
不过，如果我修改请求转发选项为使请求显示为来自 ISA 服务器计算机，就可以成功的访问，怎么回事呢？
我在被发布的RDP服务器Munich上使用Etherpeek NX进行Sniffer分析。首先分析请求选项为使请求显示为来自 ISA 服务器计算机时的数据包，如下图所示，你可以看到，全部是ISA防火墙Istanbul和被发布的服务器Munich之间的通讯，不涉及原始外部客户。ISA防火墙和Munich位于相同的网络中，因此通讯正常。
然后，我将请求选项修改为使请求显示为来自初始客户端，捕获的数据包如下图所示，你可以看到，ISA防火墙保留了原始外部客户所发送的请求数据包中的源IP地址，但是Munich接收到请求数据包后，却没有进行回复，为什么呢？
这是因为在Munich上不具有到原始外部客户192.168.1.6的路由（没有配置默认网关），因此无法做出回复。
那么，如果是另外一种情况，被发布的服务器配置了错误的默认网关呢？如下图所示，Munich的默认网关配置错误，本应配置为ISA防火墙的内部网络接口的IP地址10.2.1.1，但是配置时却输入错误，配置为一个未使用的IP地址10.2.1.2；
此时，当ISA防火墙将原始外部客户发送的请求数据包转发至Munich时，由于原始外部客户和自己并不位于相同的网络，因此Munich联系自己的默认网关，但是，由于默认网关配置错误，所以Munich仍然不能将响应数据包回复给原始外部客户，自然原始外部客户又连接失败。
最后，我们将Munich的默认网关修改为正确的值10.2.1.1，此时，原始外部客户就可以正常连接了，Sniffer捕获的数据包如下图所示，你可以看到，Munich是通过自己的默认网关10.2.1.1再将响应数据包回复至原始外部客户。
其实关于在被发布的服务器上配置了错误的默认网关这个问题，Thomas Shinder很早以前就在排除发布的SMTP服务器的故障一文进行了描述，也希望大家有空的时候可以看一下这篇文章。
以上介绍的都是发起连接请求的原始客户和被发布的服务器位于不同的网络中的情况，如果它们位于相同的网络中，则会出现通讯重定向问题，可以参考ISA Server 2004中的通讯重定向一文，这是应当尽量避免发生的。
相关文章