查看單個文章
舊 2003-07-07, 03:11 AM   #1
psac
榮譽會員
 
psac 的頭像
榮譽勳章
UID - 3662
在線等級: 級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時
註冊日期: 2002-12-07
住址: 木柵市立動物園
文章: 17381
現金: 5253 金幣
資產: 33853 金幣
預設 Windows XP 中的Windows Messenger:在防火牆和NAT環境中的使用和執行

本文內容包括:

NAT和防火牆問題
NAT和Windows Messenger
防火牆和Windows Messenger
配置:有效和無效的配置方法
解決方案
ISA Server環境下的音瀕和視瀕
總結和相關連接

本文對Windows Messenger的幾種使用情境進行了討論,並且介紹了在這些情境下,您需要如何操作才能使用Windows Messenger的全部功能特性,同時為問題的發現和解決提供了幾種可能的解決方案。

Windows Messenger為用戶帶來了激動人心的全新實時通信體驗,它將為人類的通信溝通方式帶來一場徹底的變革。通過使用Windows Messenger,您可以通過即時消息(IM)。語音、視瀕、應用程式和資料共享、以及遠端協助同您的朋友、家人和同事展開交流。在很多網路環境下,您無需對網路結構進行任何的改變即可使用所有這些功能特性。但是某些特殊的網路(例如企業或家庭網路)可能還會佈署一些防火牆和(或)網路位址轉換(NAT)元件。

通過阻止外部用戶直接訪問內部電腦,防火牆可以網路上的電腦免受非法訪問的侵害。位於防火牆後方的電腦使用NAT元件共享有限的公共 IP(Internet Protocol,Internet傳輸協定)位址。在當前使用IPv4位址分配架構的Internet中,共享IP位址是一種有限的資源。因為IPv4位址分配架構不能提供足夠的IP位址,信息技術行業被迫對NAT技術進行了標準化,並且佈署了許多NAT產品,以便對IP位址和TCP(Transmission Control Protoco)/UDP(User Datagram Protocol)連接阜進行共享。 所以,在這些特定的網路環境下,某些Windows Messenger功能(主要是即時語音和視瀕通信功能)在功能上可能會大打折扣。

如果通信雙方使用的是具有通用即插即用(UpnP)能力的防火牆或者NAT元件,所有的Windows Messenger新特性都可以正常使用。但是, features work as intended. However, there are netw有些網路則需要進行特別的配置,以便所有的Windows Messenger新特性都能夠正常工作。

說明: Microsoft承諾同業界領先廠商以及標準化組織(例如Internet工程組IETF)密切合作,確保這些強大的通信和協作功能能夠在安裝了防火牆和NAT元件的網路上得到使用。


本節內容介紹了對受NAT和防火牆問題影響的Windows Messenger功能,這些功能包括:即時消息和出席(Presence) 、音瀕和視瀕、應用程式共享和白板、文件傳輸以及遠端協助。

Windows Messenger提供了使用文字、語音和視瀕進行溝通交流的能力;它也可以通過文件傳輸開展協作;或者共享應用程式和使用白板繪圖。

在很多配置情況下,所有的Windows Messenger功能都可以直接正常工作。但是在某些配置情況下,某些特定的功能可能會受到某些限制或者根本無法工作。為了解決這些問題,Windows Messenger使用了Windows XP及較早期Windows版本中的UPnP架構。隨著越來越多的Internet網關設備開始為UPnP提供支持,這種解決方案的可用性將變得越來越強。

說明:Microsoft將在Windows XP的Internet連接共享(ICS)和Internet連接防火牆(ICF)中提供對UPnP的支持。(同Internet連接共享和Internet連接防火牆有關的更詳細資料,請閱讀: Windows XP在安全性方面的新增特性。

受NAT和防火牆問題影響的Windows Messenger功能包括:

即時消息和出席(Presence)功能
一般來說,防火牆和NAT設備對IM和出席功能不會有任何的影響。如果Windows XP客戶端機可以新增並維護一條到伺服器的連接,那麼其它的IM和出席也能夠沿著相同的途徑進行通信。例如,Microsoft Exchange IM使用HTTP(超文本傳輸傳輸協定)傳送它的出席(Presence)和IM消息,並且擁有能夠確保這些消息通過防火牆和NAT設備的傳輸機制。這些機制包括:通過輪詢維護一條能夠進行雙向通信的伺服器連接,以及在一側設定一個固定的連接阜用於回叫傳輸。

在使用會話啟始化傳輸協定(SIP)解決方案的時候,資料可能使用TCP、UDP或者安全套接字層(SSL)進行傳送。此外,SIP資料傳輸還需要使用動態連接阜,所以您可能需要開放防火牆上的所有連接阜。如果在SIP客戶端與伺服器間存在一個NAT設備,那麼,反映在SIP消息中的連接阜和位址可能會與實際的連接阜和位址有所不同。Windows Messenger擁有的某些機制可以解決這些問題,我們將在以後的文章中對它進行討論。

音瀕和視瀕
在協商進行一個音瀕-視瀕會話的時候,音瀕-視瀕流會選項使用動態連接阜。在使用動態連接阜時,應用程式無需考慮系統中還執行了哪些其它的應用程式以及這些程序都使用哪些連接阜資源即可正常工作。對於.NET Messenger,來自B站的會話邀請會被傳送到B站所接收到的A站位址處。

如果網路環境中存在防火牆或者NAT設備,可能會發生以下問題:

無論是在會話邀請還是在接受會話的程序中,由A提供的位址都可能是一個經過NAT設備轉換的內部位址 —— 一個無效(或虛假)位址,B無法使用這個位址同A聯繫。在使用4.5版本的客戶端程序的情況下,A可能會對會話進行啟始化,但是相同或者類似的位址問題仍然存在。
當B向A傳送會話邀請的時候,該邀請所使用的IP位址和連接阜是由A傳遞給B的。要想使會話能夠順利進行,A和B之間的所有防火牆都必須開放該連接阜。
實時傳輸傳輸協定(Real–time Transport Protocol,RTP)資料流使用動態分配的UDP連接阜進行傳送,連接阜範圍在5004 – 65535之間。如果傳輸路徑上有任何一個防火牆沒有開放這些UDP連接阜,那麼這些流資料將不能到達它們的目的地。
應用程式共享和白板
當您在一個安裝了防火牆或者NAT設備的網路環境中使用應用程式共享和白板功能的時候,可能會發生以下問題。(前兩個問題與音瀕和視瀕功能遇到的問題相同)

由會話發起站點提供的位址可能是一個經過NAT設備轉換的內部位址。這是一個無效的位址,外部客戶端不能夠使用該位址開始SIP會話或者同A建立TCP連接。
外部客戶端傳送SIP邀請所使用的連接阜(由內部客戶端傳遞給外部客戶端)必須使SIP邀請能夠通過這兩個客戶端之間的所有防火牆。
用來傳輸應用程式共享(AS)和白板(WB)資料的TCP連接使用1503連接阜,您需要啟用該連接阜,以便資料能夠通過所有的防火牆。在一個具有UPnP能力的網關上,您無需啟用該連接阜,因為它會將內部的靜態連接阜映射到其它連接阜上。
因為TCP資料連接使用一個特定的連接阜(1503),如果客戶端位於一個不具備UPnP能力的NAT設備之後,該連接阜必須被映射到該客戶端上。以確保能夠通過最一般的NAT設備進行通信。這還意味著:該連接阜一般不能被NAT設備後面的其它客戶端所使用;在一個時間中,只有位於相同NAT設備後面的一個客戶端能夠擁有一個AS或WB會話。
文件傳輸
文件傳輸(FT)需要會話發起站點將它的位址通過伺服器傳遞給FT會話的另一方。所以,它所遇到的第一個問題與使用應用程式共享和白板功能時遇到的問題相同:

由會話發起站點提供的位址可能是一個經過NAT設備轉換的內部位址。這是一個無效的位址,另一方無法使用該位址建立TCP連接。
針對文件傳輸的TCP連接可以由外部客戶端發起,但是存在另外一個問題。

外來和外出的TCP連接都使用6891到6900間的連接阜。這使得每個傳送方最多只能建立10條文件傳輸連接。在通信雙方之間的所有防火牆上,這些連接阜都必須被開放。如果您僅僅開放6891連接阜,用戶每次只能建立起一條文件傳輸連接。
遠端協助
遠端協助使用遠端桌面傳輸協定(Remote Desktop Protocol,RDP);與Microsoft Terminal Services使用同一個傳輸協定。RDP建立在TCP連接之上。Windows Messenger使用關於伺服器的會話邀請邏輯(與FT類似)建立遠端協助會話。所以,它同樣會因為NAT產生與FT同樣的問題。

遠端協助包括了一個附加邏輯,以應對可能遇到的NAT環境。該邏輯會簡單地嘗試從會話雙方兩個方向上建立TCP連接。如果只有一個客戶端位於NAT設備之後,那麼連接仍然可以建立,遠端協助會話也依然可以進行。如果兩個客戶端都位於(不具備UPnP能力)NAT設備的後面,那麼連接將不能建立。只有在遠端協助中加入了語音會話時,這個附加的SIP邀請邏輯才會被加入。

除了由NAT位址轉換產生的問題(只有在通信路徑中存在多個NAT設備才會出現問題)之外,遠端協助傳輸協定需要使用3389連接阜建立TCP連接。這意味著,通信雙方之間的所有防火牆都必須開放3389連接阜。
本部分內容介紹了Windows Messenger在NAT環境下可能產生的問題以及相關配置方法。

由NAT設備引起的問題

NAT設備會在以下方面對Windows Messenger功能的使用造成不良影響:

位於某台NAT設備後面的客戶端通常會被分配一個私有的IP位址。在收發資料時,該位址會被NAT設備轉換成某個公共IP位址和連接阜。在一些情況下,這個私有位址會被包括在Windows Messenger消息中傳送給另一個用戶,以便該用戶能夠同消息傳送方進行聯繫。但是,消息接收方並不能使用這個私有位址同傳送方建立連接,該位址必須經過轉換,被一個公共位址所替代。
在一些情況下,NAT設備必須進行連接阜映射,以便將一個位址和連接阜傳送給外部客戶,並且將該位址同相應的內部客戶進行映射。
有時,我們必須為某個特殊的功能使用靜態連接阜,這種情況下,在同一時間內,NAT設備後只有一個客戶端能夠使用該功能。
在不同的NAT配置環境中工作

下面,我們將對不同的NAT配置環境進行討論:

支持UPnP的NAT設備
UPnP論壇包含數個工作委員會,其中有一個專門為Internet網關設備而設立的工作委員會。該委員會主要負責為這些設備(例如NAT和防火牆設備)制訂UPnP支持規範,並且已經為使用ICS和NAT網路轉換定義出了一個標準。 支持該標準的NAT和防火牆設備可以使用UPnP傳輸協定進行檢測和控制。客戶端程序可以使用UPnP讀取和配置連接阜映射。Windows XP ICS 和ICF 支持該標準。其它網關設備廠商也已經宣佈將為該標準提供支持,這些廠商包括:ARESCOM Inc.、Buffalo Technologies Corp.、D–Link Systems Inc.、Intel Corp.、Linksys Group Inc.以及NetGear Inc.

此外,Windows XP還為UPnP提供了客戶端支持和應用程式編程接頭(API),以便應用程式能夠檢測出網路中具備UpnP能力的NAT和防火牆設備並對其加以利用。Windows XP中的Windows Messenger 可以使用這些API完成以下工作:

檢測Windows Messenger客戶端程序是否位於NAT設備之後,並且在程序位於NAT設備之後的情況下,返回經過轉換的位址,然後將該位址傳送給會話方。這就有效解決了我們上面提到過的幾個問題。
獲得動態分配連接阜的連接阜映射,並且使用它進行資料傳輸,對於一個SIP會話配置來說,這信息是必需獲得的。這樣,外部客戶端的資料就可以順利到達目的地。
獲得針對媒體流的動態連接阜映射 —— 包括AV、AS和WB使用的連接阜。
檢測Windows Messenger的通信雙方是否位於同一個NAT設備之後。如果是,則使用真實的IP位址在雙方間直接進行通信。
註:現在,您還可以為Windows的以前版本(Windows 98、98SE、ME)增加對NAT轉換的UPnP客戶端支持。您可以通過在上述版本的Windows系統中執行Windows XP附帶的網路安裝嚮導(Network Setup Wizard)獲得這種支持能力。

不支持UPnP的NAT設備
如果使用Windows Messenger進行通話的雙方不位於同一個NAT設備之後,並且該NAT設備不能被Windows Messenger檢測到,那麼他們應該仍然可以使用IM和Presence(在線顯示)功能。無論您使用的是.NET Messenger、Exchange IM或者是一個SIP解決方案,情況均是如此。使用SIP伺服器的客戶同樣能夠工作,因為相關邏輯已經被增加到了客戶端程序上,以確保在伺服器執行期間通信能夠正常進行。

我們在本文的前面部分曾經提到,NAT設備會給Windows Messenger部分功能的使用帶來一些問題。下面,我們將就這些問題進行討論:

在使用.NET Messenger或者Exchange IM時,IM 和Presence功能可以通過一台中間伺服器得以實現,該伺服器具有一條由客戶端程序發起的直接TCP連接。這樣應該不會產生任何NAT或防火牆問題。由位於NAT設備外部的客戶端程序發起的會話或連接不會取得成功,因為內部的客戶端程序無法向對方提供經過NAT轉換的位址。AV會話的情況即是如此,由內部客戶端向外部客戶端發起的呼叫可以取得成功,因為外部客戶端是SIP會話的發起方。但是如果由外部客戶端呼叫內部客戶端,呼叫程序將失敗。因為雖然內部客戶端可以向外部客戶端傳送SIP邀請,但是在會話邀請中夾帶的位址是一個錯誤的位址。
位於NAT設備同一側的雙方能夠正常進行會話。
SIP的套用層網關(ALG)可能會對這些問題有所緩和。用戶可以將ALG用作一個套用層過濾器,使用它對特定的應用程式和傳輸協定進行過濾。
級聯式NAT設備
在級聯式的NAT環境中,既使您的網路中沒有使用NAT設備,或者使用了一個支持UPnP的NAT設備,Windows Messenger的AV通信可能仍然不會取得成功。因為在這種配置環境下,通話雙方之間的會話路徑中可能存在其它NAT設備,而這些NAT設備是不受會話雙方控制的。例如,您的Internet服務提供商(ISP)也在它的網路中使用了NAT技術,但是這種情況並不一般。如果您懷疑通信問題是由這種情況引起的,請同您的ISP聯繫,以確定問題原因並找出相應的解決辦法。


縮略術語表

ALG–應用程式層網關
AS–應用程式共享
AV–音瀕和視瀕
FT–文件傳輸
ICF–Internet連接防火牆
ICS–Internet連接共享
IM–即時消息
ISA–Internet Security and Acceleration
ISP–Internet 服務提供商 NAT–網路位址轉換
RDP–遠端桌面傳輸協定
RTC–實時通信
RTP–實時傳輸傳輸協定
SDP–會話描述傳輸協定
SIP–會話啟始化傳輸協定
SSL–安全套接字層
TCP–傳輸控制傳輸協定
UDP–用戶資料報傳輸協定
UPnP–通用即插即用
WB–白板(共享)

LAN 區域網路
WAN 廣域網
UTP 非遮閉的雙絞線
STP 遮閉的雙絞線
ATM 異步傳輸模式
FDDI 光纖分佈式資料接頭
CSMA/CD 載波偵聽多路訪問方法
MSAU 多站訪問單元
ATM 異部傳輸模式
PVC 永久虛擬回路
Hub 集線器
PSTN 公共交換電話網
ISDN 綜合業務數字網
ADSL 非對稱數字用戶線路
Bridge 網路橋接
Switch 交換機
Router 路由器
Gateway 網關
VPN 虛擬專用網路
PRI 主數率接頭
BRI 基本數率接頭
MAC 媒體訪問控制
OSI 開放式系統互連
TCP/IP 傳輸控制傳輸協定/網際傳輸協定
IPX/SPX 網際資料包交換/系列資料包交換
FTP 文件傳輸傳輸協定
SMTP 簡單郵件傳輸傳輸協定
TCP 傳輸傳輸協定
IP 網際傳輸協定
AppleTalk 可路由傳輸協定組
IrDA 紅外線資料傳輸協定
SLIP 串行線路網際傳輸協定
PPP 點到點傳輸協定
PPTP 點到點隧道傳輸協定
L2TP 第二層隧道傳輸協定
IPsec Internet傳輸協定安全
NetBEUI NetBIOS增強型用戶接頭
HTTP 超文本傳輸傳輸協定
UDP 用戶報文傳輸協定
ARP 位址解析傳輸協定
ICMP Internet控制報文傳輸協定
IGMP Internet組管理傳輸協定
DNS 域名系統
WINS Windows Internet名稱服務
UDP 用戶資料報傳輸協定
CRC 循環冗余碼校驗
DHCP 動態主機配置傳輸協定
APIPA 自動私有IP位址
CIDR 無類域內路由選項
URL 統一資源定位符
NAT 網路位址翻譯器
IANA Internet分配資料機構
WWW 萬維網
NCSA 國家電腦安全協會
ITSEC 信息技術安全評價標準
CSE 通信安全機構
OUs 目錄林的組織單元
PKI 公用密鑰基礎結構
ACE 訪問控制條目
EFS 加密文件系統
S/MIME 安全的多目標郵件擴展
TLS 傳輸層安全
PAP 密碼認證傳輸協定
GPO 群組原則對像





psac 目前離線  
送花文章: 3, 收花文章: 1630 篇, 收花: 3204 次