防火墙基础：ISA Server 防火墙客户端和Forefront TMG 客户端介绍

      前两天看一篇关于“Server 防火墙客户端和Forefront TMG 客户端介绍”的英文介绍，在学习的同时也翻译了一下，把翻译好的也上传上来分享给大家一起学习下；

      原文是 http://technet.microsoft.com/en-us/library/ee291341.aspx ，翻译的不好的还请大家谅解。

 

介绍

从互联网早期开始，内网主机中基于HTTP的应用程序就被定义可以通过代理机制来访问公网资源。这些应用程序侦听本地代理连接端口（8080是默认被允许的）和以特定的形式发出请求以便代理能够正确处理它。代理会根据代理服务器管理员定义的需求和策略对内部客户和外部服务器之间的通信进行处理，这种机制也被称之为CERN代理；相关组织也定义了HTTP协议和HTTP代理机制。现在，通常被称作HTTP代理或Web代理，但它们的含义是相同的，是处理HTTP客户端和服务器的一种机制，这种工作机制是非常不错的，甚至包含用特定的HTTP请求/响应来对用户进行身份验证的能力，图01中说明了客户端直接连接客户端的过程；

图02阐释了CERN代理请求的过程；

不幸地是，这种代理机制通常局限于HTTP代理，应用程序如果使用非HTTP协议那就需要其它解决方案了，对于这些应用程序，另外一种称之为Socks代理的机制被设计出来，最初被称为Socks4，它能为几乎任何应用程序（包括像FTP、SMTP、POP3，甚至是HTTP）提供TCP代理服务。这种机制除增加了对应用程序协议的代理，其它的功能机制类似于CERN。Socks客户端应用程序使用Socks代理（10801是被默认允许的）同Socks代理服务器协商，以建立与远程服务器的连接。一旦此连接建立成功，Socks代理服务器将在客户端和服务器之间建立会话协议中承担基本NAT路由功能；Socks4之后扩展到支持名称解析（Socks4a）和 UDP传输，用户认证和IPV6 （SOCKS5和扩展名），尽管SOCKS提供大量CERN代理所不能提供的功能，但是如果要与远端主机成功建立连接，它还是需要应用程序在开发时使用SOCKS协议。图03阐释了基本的SOCKS代理行为。

不管是CERN还是SOCKS代理方式，应用程序数据都需要通过代理端口来建立连接。除了SOCKS5中UDP代理机制，客户端与远端服务器之间没有其他的连接。

（PS：此处补充非翻译原文内容仅供扩展了解：http代理：主要代理客户端的HTTP访问，端口常见的为80和8080，而Socks代理与此则不同，只是简单地进行数据包的传递并不关心你采用何种协议，是一种传输层的协议代理，就Socks来说分为了Socks4和Socks5 两者不同点是Socks4仅支持TCP（传输控制协议），而Sock5代理不仅支持TCP还支持UDP（用户数据包协议）而且还支持像身份验证机制、服务器域名解析等功能，更简单来说，Socks4能做到的Socks5都能实现，但是Socks5能实现的Socks就不一定能全部实现。）

从1996年开始，微软就提供了一种机制来保证不使用代理的应用程序可以通过代理服务器来访问公网信息。代理服务器1和代理服务器2所实现的这种机制被称为Winsock代理（ WSP）。如果是ISA 服务器，它的客户端被称为防火墙客户端 (FWC)， 而如果是Forefront TMG，它的客户端被称之为TMG客户端 (TMGC)或是不同版本的防火墙客户端。当然，我们也可将他们统称为是“防火墙客户端（FWC）”以及作为防火墙的各种各样的防火墙版本。尽管这些年名称和功能方面有所改变，但是防火墙的首要目标仍保持不变，即保证不使用代理的应用程序按照管理员设置的策略通过微软代理/防火墙；

Winsock 101

为了理解FWC如何运作，你需要开始对Windows应用程序网络信息流量产生和使用了解。尽管应用程序可以自己去构建IP包，但这是非常低效的，这将导致一系列的问题，很少应用程序开会人员会原意这样做，很多Windows网络应用程序开发人员发现通过将Windows AIP集成到Winsock中是非常有效的。

Winsock是伯克利软件套件中的UNIX sockets API（伯克利套接字或BSD套接字）在Windows下的实现（补充引用非原文内容：九十年代初，由Microsoft联合了其他几家公司共同制定了一套WINDOWS下的网络编程接口，即Windows Sockets规范。它是Berkeley Sockets的重要扩充，主要是增加了一些异步函数，并增加了符合 Windows 消息驱动特性的网络事件异步选择机制。 Windows Sockets规范是一套开放的、支持多种协议的 Windows下的网络编程接口。目前，在实际应用中的Windows Sockets规范主要有1.1版和2.0版。两者的最重要区别是1.1版只支持TCP/IP协议，而2.0版可以支持多协议，2.0版有良好的向后兼容性，目前，Windows下的Internet软件都是基于WinSock开发的）；在伯克利和BSD这两种情况中，API为网络应用程序开发人员只需要提供使用的网络协议，而不需要去对每个协议和数据包做具体细节进行了解。

虽然Winsock API定义的函数有几十个，但是我将仅讨论以下列表中所提到的函数项；

bind() — — 将网络地址与套接字绑定

connect() — — 创建到远程主机的连接

getaddrinfo() — — 分别获取 IP 地址或主机名的主机名或 IP 地址

listen() — — 创建一个套接口并监听申请的连接

recv() — — 从一个连接或绑定套接口接收数据

send() — — 向一个已连接的套接口上发送的数据

socket() — — 创建套接口

正如你所发现的，所有的这些功能除getaddrinfo() 外都有一个共同的点-他们都同套接字有关，套接字是对网络资源的一种编程方式的引用，并向应用程序的提供Winsock功能的一种方式。

几乎所有的应用程序通过套接字来实现Winsock功能的。很重要的一点是因为套接字在防火墙环境中提供非常多的作用。为了更好地对比 FWC 行为，我们将先了解在没有防火墙的环境中FTP客户端与服务器之间的会话连接方式。图 04提供了简单的模型来说明没有防火墙时的会话过程的说明；

以下过程中，将介绍到当用户在命令行方式通过ftp.exe向FTP服务器发送ftp.contoso.com的过程以及抓包信息：

1. Ftp.exe 将ftp.contoso.com 传递给 Winsock getaddrinfo()函数。Winsock 将调用 Windows 名称解析机制，并返回"131.107.0.21"到 ftp.exe程序

2. Ftp.exe 从 Winsock socket() 函数获取 IPv4 TCP 套接字

3. Ftp.exe 调用 Winsock connect() 函数，使得Winsock连接至目标IP 131.107.0.21 的TCP 21端口。服务器响应 ftp.exe 的并提示"成功"。这样就在FTP服务器与FTP客户端之间建立一条会话连接；

4. 将用户和 FTP 服务器进行 FTP 控制通道的以下对话：

a) FTP 服务器发送220告知已经准备好提供服务；

b) ftp.exe将用户在FTP窗口中键入的“anonymous”发送至FTP服务器；

c) FTP 服务器回复“331 Anonymous允许访问”，发送身份（邮件名）作为密码。

d) 用户在 ftp.exe 窗口中键入"[email protected]"，并按回车键。

e) ftp.exe 将" [email protected]"发送到 FTP 服务器。

f) FTP 服务器向客户端反回代码230，提示匿名用户已登录完成。

g) 此时用户可以在 ftp.exe 窗口中的执行“dir”命令。

注意：Ftp.exe通过套接字方式从FTP服务器上接收数据。

5、Ftp.exe 通过getaddrinfo() 函数传递空的主机名给Winsock。WinSock将此理解为将自己的IP地址分配给这台电脑；

6. ftp.exe通过调用Winsock的套接字()API再次获得一个新的IPv4 TCP套接字。Winsock根据此返回套接字给到ftp.exe

7、Ftp.exe 告知Winsock 需要将新获取的套接字绑定到131.107.0.19的动态端口上，Winsock将此套接字字绑定至1234端口，并返回绑定成功

8、Ftp.exe 指示 Winsock 用于侦听传入的连接，在绑定套接字上。Winsock 返回到 ftp.exe 的"成功"。

9、Ftp.exe 和 FTP 服务器将建立如下FTP会话连接：

a) ftp.exe 将"端口 131,107,0,19,4,210"发送到 FTP 服务器。

b) FTP 服务器响应回应200状态码，宣告此命令已成功"。

c) ftp.exe发送“LIST”至FTP服务器。

d) FTP 服务器返回状态代码150 表明文件状态良好，打开数据连接；

10、FTP服务器与FTP.exe之间建立会话时，因为ftp.exe需要通过winsock建立的套接字侦听从IP地址131.107.0.21 TCP端口20到131.107.0.19 TCP端口1234传入的连接。

10. FTP 服务器通与 ftp.exe 建立的会话连接返回目录信息。

Winsock 服务提供商

Winsock 提供了两种基本服务类型 ；传输服务和名称服务（IP地址和名称之间的转换）在图 04 中所示的示例中，getaddrinfo() 利用 Winsock 名称服务和套接字 Winsock 调用利用传输服务。虽然这个服务在Winsock创建之初就有，但是它是不可扩展的，直到Windows 98和更高版本的Windows 操作系统中发布Winsock 2.0，此传输和命名空间的可扩展性被统称为服务提供程序接口 (SPI)，传输服务提供商也称为分层服务供应商 (LSP) 因为 Winsock 允许多个 TSP 以连续的方式链接在一起。

LSP用于向特定的LSP供应商提供额外的Winsock功能。在某些情况下，这可能包括用于无线连接创建的pseudo-network接口，专用的打印机驱动程序或可能是最新的恶意软件，这些扩展性允许SP制作者将功能添加至Winsock和保证通过FWC是正常的。图05描述了关于Winsock和SP（移动互联网服务内容应用服务的直接提供者）的一个简化关系图；

当SP （移动互联网服务内容应用服务的直接提供者）安装时，它将更新 Winsock 相关类型的功能，它提供了如：

l 类型的 SP ；名称或运输服务提供商

l 级别的服务提供商

l 运输协议，它支持 (TSP)

l 在长期服务金链 (TSP) 中的首选的地位

这样一来，Winsock就知道何时以及如何调用LSP中对应指定的应用程序的请求。并在系统注册表中保存Winsock LSP列表，并可以被看作是使用Windows提供的Netsh实用程序，例如Winsock提供了查看：netsh winsock show catalog。输入结果如下：

在此示例中，TMG 客户端已经注册为两个传输服务提供（TCP/IP 和 UDP/IP） 和名称服务提供程序。您可能已经注意到有两个条目，微软 TMG 客户端与 TCP/IP，UDP/IP 和名称服务。这是因为在此示例中的主机正在运行 64 位版本的 Windows。在这种环境，TMG 客户端注册 Winsock分为32位和64位 SP，以保证Winsock正确调用32 位和 64 位的组件。由于LSP在调用时64位的客户端时只能调用64位的Winsock，而不能调用32位的Winsock。

虽然我们不打算深入介绍 Winsock LSP(分层服务提供商)，它值得一提的 LSP 可能执行其任务，并将请求转发到其他 SP 并作进一步处理链或它可能通知 Winsock 处理其发来的请求。例如，NSP1 可能不希望 Winsock 到名称解析请求任何进一步所以当它返回 Winsock 调用时，它发出信号 Winsock 不应给任何其他 NSP 通过请求的进程。同样地，TSP 可以执行该请求的处理和信号 Winsock 停止进一步的处理，并返回此 TSP 所提供的响应。这点存在一定的冲突性。

防火墙客户端 Winsock概念

在FWC中，有如下三个额外的功能需要介绍：

1. Winsock 应用程序可以连接到如ISA 服务器或TMG服务器在不附加任何特殊的功能情况下；

2. 防火墙管理员可对无法进行代理身份验证如(SMTP、POP3、F2FP 等)进行身份验证

3. 防火墙管理员可以控制Winsock 应用程序通过防火墙时使用特定行为

图 06 和下面的列表汇总了之前FTP会话方式在通过FWC时基本过程

说明：由于客户端工作在内网，返回的信息将通过NAT转入内部，此时IP也将转为内网IP 192.168.0.2，因为此时防火墙内网地址为192.168.0.1

此过程开始时，用户打开一个命令窗口和键入ftp ftp.contoso.com，然后按回车键。

1. Ftp.exe 将ftp.contoso.com传递给Winsock getaddrinfo() 函数。

a) 因为 FWC 注册为 NSP（网络服务协议），Winsock 会将此请求通过防火墙传递至ftp.contoso.com

b) FWC客户端连接至防火墙的1745端口，以进行身份验证；

c) FWC 向gethostbyname()向防火墙所在FWC控制通道中发送ftp.contoso.com 请求

d) 防火墙使用 Windows 名称解析机制，将响应结果"131.107.0.21"通过Winsock返回给ftp.exe

2. Ftp.exe 获得通过的 Winsock socket() 函数调用的 IPv4 TCP 套接字。

3. Ftp.exe 调用 Winsock connect() 函数，查找到连接目标IP为131.107.0.21，端口21；

a) 因为 FWC 注册为 TSP，Winsock 传递 FWC 将此向 FWC 控制通道通过防火墙的请求转发到此调用。

b) 防火墙创建一个至FTP服务器21端口的连接并且回复连接成功。

c) FWC 通过6789端口与防火墙建立连接

d) FWC通过Winsock转发至ftp.exe 的成功状态。这样就建立 ftp.exe 和 FTP 服务器之间的会话通道。

4. Ftp.exe 和 FTP 服务器从事以下对话通过 FTP 控制通道上的防火墙的连接：

5. FTP 服务器发送220告知已经准备好提供服务；

6. ftp.exe将用户在FTP窗口中键入的“anonymous”发送至FTP服务器；

7. FTP 服务器回复“331 Anonymous允许访问”，发送身份（邮件名）作为密码。

8. 用户在 ftp.exe 窗口中键入"[email protected]"，并按回车键。

9. ftp.exe 将" [email protected]"发送到 FTP 服务器。

10. FTP 服务器向客户端反回代码230，提示匿名用户已登录完成。

a) 用户在ftp.exe 窗口中的"dir"命令；

5. Ftp.exe 向 Winsock getaddrinfo() 函数传递空主机名，并且回复192.168.0.2。

6. Ftp.exe 通过再一次调用 Winsock socket() API 获取新的 IPv4 TCP 套接字。Winsock向ftp.exe返回套接字。

7. Ftp.exe 要求Winsock 要将新的套接字绑定到 192.168.0.2 动态端口上。Winsock将该请求转发到 FWC。

a) FWC 创建套接字和自己要接受传入的连接从防火墙在其上的绑定。在此示例中，此端口是 1234。

b) FWC 绑定请求，它将发送到防火墙中包括此套接字信息。防火墙将使用此套接字发送到 FWC 从 FTP 服务器收到的数据

c) 防火墙在防火墙服务器以获取动态分配的端口面临 FTP 服务器的网络上执行 Winsock bind() 请求。

d) 防火墙返回这对上的 FWC 控制通道，它通过 Winsock 返回到 ftp.exe 的端口 1234 FWC 端口 （在此示例中的 2345)。

a) 防火墙在防火墙服务器以获取动态分配的端口面临 FTP 服务器的网络上执行 Winsock bind() 请求。

b) 防火墙返回这对上的 FWC 控制通道，它通过 Winsock 返回到 ftp.exe 的端口 1234 FWC 端口 （在此示例中的 2345)。

8、Ftp.exe 指示 Winsock 用于侦听传入的连接，在绑定套接字上。Winsock 将这传递到将它转发给防火墙的 FWC。防火墙侦听此套接字，并返回"成功"通过 FWC 控制通道。FWC 传递这给 ftp.exe 通过 Winsock。

9. Ftp.exe 和 FTP 服务器将建立如下FTP会话连接：

a) ftp.exe 将"端口 131,107,0,19,4,210"发送到 FTP 服务器。

b) FTP 服务器响应回应200状态码，宣告此命令已成功"。

c) ftp.exe发送“LIST”至FTP服务器。

d) FTP 服务器返回状态代码150 表明文件状态良好，打开数据连接；

10、FTP 服务器建立 FTP 从 131.107.0.21 的数据连接端口 20 到 131.107.0.19 端口 2345。

a) 防火墙将传入的连接的 FWC 通知通过 FWC 控制通道上发送新映射的消息。

b) FWC 响应防火墙。此消息包含完整连接地图所理解的 FWC。

c) 防火墙创建一个连接从指定的端口向FWC的1234添加映射命令；

11. FTP 服务器将目录信息发送到端口 2345上的防火墙。防火墙将此转发到通过连接到端口 1234年上 FWC ftp.exe。

12、2345 端口上的防火墙和 FTP 服务器的端口 20 之间的对话被镜像端口 1999上的防火墙和端口 1234上的 FTP 客户端之间。

摘要

在网络层,直连的FTP会话不同于FWC-connect会话在一些非常基本的方式:

直接连接

FWC 连接

虽然这两个表包含特定端口的许多连接,这些端口实际上是动态分配通过Winsock bind()调用的。这个方法是用来确保Windows网络组件管理网络资源分配的唯一性，这种方法得在跨越2个防火强时使用1024以上端口。

这篇文章涵盖只有最基本 Winsock 机制，大多数应用程序使用与所述的 FWC 和防火墙如何一起工作来使此过程透明、策略驱动和验证 ；所有不涉及客户端应用程序或软件的开发者。在以后的文章中我们将讨论更多复杂的情况和 FWC 应用程序设置做些什么来改变应用程序的 FWC 行为。