專利名稱：用于具有多個客戶端的網(wǎng)絡(luò)的修復管理的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通過交換機對多個所服務的客戶端設(shè)備進行修復管理和控制。如此處 所使用的，修復是指客戶端設(shè)備對接收軟件更新或瓦解病毒感染等的需要。本發(fā)明特別地 但不是排他地適合于對例如在公司或大學客戶端局域網(wǎng)(LAN)中的隔離客戶端組進行修
復管理。
背景技術(shù)：
已利用各種方式向網(wǎng)絡(luò)中的客戶端提供修復。在典型例子中，公司LAN中的一組 客戶端擁有包括對互聯(lián)網(wǎng)的訪問的各種服務。不管盡量減少客戶端感染病毒或其他感染代 理的風險的安全措施如何，一個客戶端或客戶端的子組也會受感染。負責管理公司LAN的 人員可以在交換機手動輸入每一個受感染客戶端的身份，通過該交換機，客戶端的TCP/IP 通信被處理，以便將受感染客戶端通信限制到指定的服務器，所述指定的服務器可以協(xié)助 瓦解感染。不過，這種方案要求管理員干預。進一步，考慮到必須篩選訪問請求來確定請求 是否是由受感染客戶端做出的給其添加的額外處理負擔，在控制交換節(jié)點處處理受感染客 戶端的身份(各客戶端地址)負面影響它的處理能力。而且，由于負責交換單元的內(nèi)存容 量，在控制交換節(jié)點處存儲受感染客戶端的客戶端地址的每一個可能會受到限制。由于特 定客戶端的身份必須被輸入到控制通信交換機中并且被以類似方式處理，對特定客戶端下 載軟件更新的要求導致類似的負擔和不利。因而，需要改進修復過程。

發(fā)明內(nèi)容
本發(fā)明的目的是滿足該需求。提供了一種示例性方法，所述方法在計算網(wǎng)絡(luò)中將客戶端設(shè)備定向到修復節(jié)點。 以單個共同標簽標識所述客戶端設(shè)備中要接收修復服務的子集。當確定所述客戶端設(shè)備中 發(fā)起通信請求分組的一個客戶端設(shè)備是由所述單個共同標簽標識時，通過將所述通信請求 分組路由到重定向服務器來處理所述通信請求分組，并且從所述重定向服務器向所述一個 客戶端設(shè)備傳輸超文本傳輸協(xié)議(HTTP)命令，所述超文本傳輸協(xié)議(HTTP)命令指定所述 一個客戶端設(shè)備將通信重定向到所述修復節(jié)點，以便修復服務可以經(jīng)由所述修復節(jié)點被提 供到所述一個客戶端設(shè)備。根據(jù)本發(fā)明的示例性交換機實現(xiàn)以上方法。


本發(fā)明的示例性實現(xiàn)的特征通過說明書、權(quán)利要求書和附圖將變得顯而易見，在 所述附圖中圖1是適合于并入本發(fā)明實施例的示意性通信網(wǎng)絡(luò)的框圖；圖2是諸如圖1中所示的示例性交換機的框圖；以及圖3和圖4 一起形成根據(jù)本發(fā)明的方法的示意性實施例的流程圖。
具體實施例方式本發(fā)明一方面在于識別已知的用于提供修復服務的方法不是可擴展的。也就是， 要接收修復服務的每一個客戶端必須由提供對修復服務的管理的交換機逐個標識，從而， 添加要接收修復服務的客戶端造成計算負載和交換機存儲各客戶端身份所使用的存儲資 源的成比例增加。向要求修復服務的一組客戶端應用單個標簽的能力使得交換機能夠基于 該單個組標簽識別這些客戶端，并且提供了一種可擴展方案，所述可擴展方案使交換機在 提供修復管理中所要求的資源和處理最小化。本發(fā)明另一方面在于將客戶端自動重定向到修復服務器，已知的現(xiàn)有方法未提供 這種能力。本發(fā)明的進一步方面在于自動通知客戶端它已被檢疫(quarantine)。圖1示出虛線12左側(cè)的子組10的示例性框圖。多個通信終端14、16和18，在該 例子中是個人計算機(PC)，支持作為子組10的成員的相應用戶。所述通信終端的每一個包 括瀏覽器20，瀏覽器20與網(wǎng)絡(luò)接口一起促進TCP/IP通信。本領(lǐng)域的技術(shù)人員將理解，通 信終端可以包括不同類型的有線和無線通信設(shè)備。網(wǎng)絡(luò)交換機22耦合于所述通信終端，并 且為所述通信終端的每一個與其他設(shè)備之間的通信提供網(wǎng)關(guān)，所述其他設(shè)備可以包括其他 通信終端、該子組內(nèi)的服務器和/或經(jīng)由互聯(lián)網(wǎng)28訪問的設(shè)備。該子組包括連接到交換機 22的輕量級目錄訪問協(xié)議(LDAP)服務器24。該子組還包括修復服務器26，修復服務器26 耦合于交換機22并且還可以被通信終端訪問。作為對根據(jù)本發(fā)明的方法的示例性實施例 的解釋的一部分，下文將更詳細地解釋以上描述的這些單元的使用和交互。圖2是可用于圖1的網(wǎng)絡(luò)中的示例性交換機22的框圖。微處理單元(微處理 器)50被只讀存儲器(ROM) 52、隨機存取存儲器(RAM) 54以及可以是硬盤的非易失性數(shù)據(jù)存 儲設(shè)備56支持。輸入/輸出模塊58耦合于微處理器50，并且支持與外部設(shè)備的入站和出 站通信。諸如鍵盤或鼠標的輸入設(shè)備(I.D.)60允許管理員向微處理器以及其上運行的程 序提供數(shù)據(jù)和輸入。由微處理器生成的輸出可以通過諸如監(jiān)控器的輸出設(shè)備(O.D.)62向 管理員顯示。初始存儲在ROM 52和存儲設(shè)備56中的程序指令典型地被傳送到RAM 54中， 以促進由微處理器50實現(xiàn)的應用的運行時操作。三元內(nèi)容尋址存儲器(TCAM)64耦合于微處理器50，并且提供特定類型的存儲操 作。通過諸如RAM的正常計算機存儲器，操作系統(tǒng)提供地址并且反過來接收存儲在所提供 的地址處的數(shù)據(jù)。通過內(nèi)容尋址存儲器，操作系統(tǒng)提供數(shù)據(jù)并且反過來接收該數(shù)據(jù)被存儲 的地址的列表，如果它找到的話。它一般在一個操作中搜索整個存儲器，因而比常規(guī)RAM 快。三元類型的CAM允許輸入請求匹配第三狀態(tài)，S卩，可以具有諸如下文描述的單個共同標 簽的任何期望值/內(nèi)容，其中，所述第三狀態(tài)可以包括掩碼。下文將關(guān)于示例性方法更詳細 地描述交換機22的功能。圖2中，在微處理單元50上方以虛線格式示出的單元表示與交換機22的操作相 關(guān)聯(lián)的功能方面。微處理單元50與其支持單元一起可以實現(xiàn)多個應用程序(AP) 70，所述多 個應用程序(AP) 70被用于促進對提供到客戶端，即PC 14、16和18的修復服務的管理。示 例性表72可以包含已被確定為要求修復服務的相應客戶端的列表。另一示例性表74，可 以被用作2層(L2)交換表，它包含可以發(fā)起流量的客戶端的媒體訪問控制(MAC)地址的列 表，并且包括與要求修復服務的那些客戶端相關(guān)聯(lián)的單個共同組標簽。表72和74可以被存儲在RAM 54和/或存儲設(shè)備56中。概述將有助于理解對根據(jù)本發(fā)明的方法的示例性實施例的詳細描述。預先標識的 要求修復服務的客戶端的列表通過MAC地址標識這些客戶端。這些被標識的客戶端的每一 個被指派共同組標簽，即，檢疫組標簽“Q”。檢疫組的成員被阻止訪問除預定的修復服務器 或修復網(wǎng)站外的網(wǎng)絡(luò)資源。當檢疫組的成員試圖訪問另一網(wǎng)絡(luò)服務時，流量被交換機截取， 該交換機促使向發(fā)起成員的PC發(fā)送HTTP重定向命令。該重定向命令促使該成員的PC的 客戶端瀏覽器訪問預定的修復網(wǎng)站/服務器。該成員然后可以接收適當?shù)男迯头?，諸如 通過采取動作來瓦解影響該成員的PC的病毒或者下載更新該成員的PC上駐留的程序所要 求的軟件補丁。優(yōu)選地，如果需要通過該客戶端的任何手動干預的話，修復網(wǎng)站/服務器促 使該客戶端的PC顯示對該客戶端為何被重定向到修復站點的解釋和如何繼續(xù)修復動作的 指令。在成功完成修復后，檢疫組標簽與該成員的MAC地址的關(guān)聯(lián)被消除，由此修復該成員 的一般網(wǎng)絡(luò)訪問，即，由該成員的PC發(fā)起的后續(xù)流量將被正常路由(或橋接)到預期目的 地。這種機制通知客戶端它已被檢疫，并且允許該客戶端完成修復服務，而不要求管理員手 動輔助或干預。以下是示例性L2表，該表可以由圖2中的MAC組列表74表示，它示出了組標簽 的使用，所述組標簽可以與所選擇的由MAC地址標識的客戶端相關(guān)聯(lián)。在第一行中，源MAC 地址與端口 1/1相關(guān)聯(lián)，并且具有指派的組標識“Q”，表示該客戶端是要求修復服務的檢疫 組的一部分。在第二行中，另一源MAC地址與端口 1/2相關(guān)聯(lián)，并且具有所指派的組標識 “0”(零或空)，表示該客戶端不是檢疫組的一部分。L2表將包含用于發(fā)起流量的每一個客 戶端的MAC地址的條目。在出現(xiàn)具有新MAC地址的新客戶端時，該客戶端發(fā)起要由交換機 處理的流量，該表將被更新為包括該客戶端的MAC地址和相關(guān)聯(lián)的端口號，并且將缺省指 派組ID為0。只有確定該客戶端要求修復服務時，客戶端的組ID才被改變?yōu)镼。已知的入 侵檢測系統(tǒng)軟件或其他已知應用可以被用于生成要求修復服務的客戶端的列表。該列表可 以被存儲在LDAP服務器24處的由交換機周期性下載并且被存儲為表72的表中。L2 表 以下示出對客戶端發(fā)起請求的TCAM分組處理的表，將有助于理解隨后的示例性 方法。在該例子中，TCAM 64負責處理來自客戶端的進入分組。該表中的三行示出TCAM將 如何基于三個指定條件處理從需要修復服務的客戶端發(fā)起的分組，即，組ID = Q。從不要 求修復服務的客戶端發(fā)起的分組，即，組ID = 0，將被以常規(guī)方式處理，例如，TCAM允許該分 組被定向到轉(zhuǎn)發(fā)引擎確定的端口 /節(jié)點，即，TCAM將不覆蓋由該轉(zhuǎn)發(fā)引擎做出的轉(zhuǎn)發(fā)決定。 將結(jié)合示例性方法進一步解釋TCAM分組處理表。TCAM分組處理指令 圖3和圖4示出一種示例性方法的步驟，在概方法中，很多步驟由交換機或者被促 使由交換機實現(xiàn)，所述交換機諸如圖1中的交換機22。該方法從START(開始)100開始。 在步驟105，由TCAM確定來自所服務客戶端的流入(進入)分組是否具有組標識，所述組標 識指示要求修復服務，例如，組ID = Q0如果步驟105確定為否，表明不要求修復服務，則正 常處理分組，例如，路由到與該分組的目的地相關(guān)聯(lián)的端口 /節(jié)點，如步驟110中所示。如 果步驟105確定為是，表明要求修復服務，則在步驟115由TCAM進一步確定該TCAM表中第 二行的條件是否為真，即，所指示的目的地是否是修復服務器、DNS服務器或DHCP服務器中 的一個。如果步驟115確定為否，則在步驟120通過TCAM進一步確定該TCAM表中第一行 的條件是否為真，即，是否存在HTTP請求。如果步驟120確定為否，則在步驟125放棄或丟 棄該問題分組。這有效地限制了被標識為要求修復服務的客戶端到與修復服務的實現(xiàn)相關(guān) 聯(lián)的通信的能力。如果步驟115確定為是，則允許如步驟110中所示以正常方式完成該分 組，因為該分組請求僅需要來自DNS或DHCP服務器或修復服務器自身的服務。要理解，還 可以包括如根據(jù)步驟110處理的其他服務，例如，ARP請求和應答。如果步驟120確定為是，表明該問題分組不是要發(fā)往修復服務器并且是HTTP分 組，則TCAM復制/轉(zhuǎn)發(fā)該分組到交換機的微處理單元用于處理，如步驟130中所示。在步 驟135，交換機確定該問題分組是否是序列中的第一分組，例如，是否設(shè)置了 TCP連接中的 發(fā)起SYN標記。如果步驟135確定為否，則使用來自NAT表的現(xiàn)有條目。如果該NAT表中 沒有現(xiàn)有條目，則該分組被放棄/丟棄?？蛻舳撕徒粨Q機之間的每一個分組需要被NAT轉(zhuǎn) 換，直至修復服務器關(guān)閉該TCP連接。如果步驟135確定為是，則在步驟145開始在NAT表 中以其創(chuàng)建條目的目的地IP地址和交換機內(nèi)部的TCP端口地址的網(wǎng)絡(luò)地址轉(zhuǎn)換(NAT)過 程，并且保存該信息用于反向流量以及該流的后續(xù)分組。在步驟150，交換機在該交換機內(nèi) 部的TCP端口處將該NAT轉(zhuǎn)換的分組發(fā)送到它的用于連接客戶端和內(nèi)部實現(xiàn)的重定向服務 器的TCP/IP處理堆棧。在步驟155，重定向服務器向客戶端發(fā)送例如HTTP重定向代碼301 的HTTP重定向命令，并且關(guān)閉與重定向服務器的TCP連接，其中，所述HTTP重定向命令使 用在步驟145保存的信息被反向NAT轉(zhuǎn)換到該客戶端。替代地，如果修復服務器不可用或 者還未被配置為提供所要求的修復服務，重定向服務器可以在關(guān)閉連接前向客戶端提供指 示該客戶端的檢疫狀態(tài)的網(wǎng)頁。在步驟160，客戶端的PC的瀏覽器從交換機接收被偽造(通過NAT過程)為來自 HTTP請求的原始目的地的重定向分組，并且將它重定向到修復服務器。要注意，根據(jù)TCAM 表中第二行的條件，TCAM將允許客戶端的PC訪問修復服務器。在步驟165，客戶端已完成 所要求的修復服務的實現(xiàn)，例如，病毒檢測和根除或軟件更新的下載。取決于所要求的修復服務的性質(zhì)，可以完成修復過程，而不需來自客戶端的任何手動干預或輸入。在步驟170，在 客戶端完成修復過程后，L2表被更新，將問題客戶端從檢疫狀態(tài)消除。在更新L2表后，組 標簽將不把問題客戶端顯示為要求修復服務，并且因此將促使TCAM和交換機的微處理器 以正常方式向預期目的地路由該客戶端發(fā)起的分組。盡管此處已詳細示出和描述了本發(fā)明的示例性實現(xiàn)，對本領(lǐng)域的技術(shù)人員將顯而 易見的是，在不背離本發(fā)明精神的情況下，可以做出各種修改、添加、替換等。例如，TCAM對 于實踐本發(fā)明實施例來說不是必需的。能夠標識可應用于多個客戶端的單個標簽的任何架 構(gòu)都可以被使用。取決于系統(tǒng)設(shè)計架構(gòu)，圖1的單元的功能可以在其他單元中被實現(xiàn)或者 被集成到更少的單元中。例如，可以設(shè)計單個節(jié)點來實現(xiàn)交換機22、LDAP服務器24和修復 服務器26的功能。本發(fā)明的范圍在以下權(quán)利要求書中定義。
權(quán)利要求
一種在計算網(wǎng)絡(luò)中將客戶端設(shè)備定向到修復節(jié)點的交換機，所述交換機包括微處理單元支持裝置，用于以單個共同標簽標識所述客戶端設(shè)備中要接收修復服務的子集；微處理單元支持裝置，用于確定所述客戶端設(shè)備中發(fā)起通信請求分組的一個客戶端設(shè)備是否由所述單個共同標簽標識；微處理單元支持裝置，在微處理單元支持確定裝置確定所述一個客戶端設(shè)備是由所述單個共同標簽標識時，處理所述通信請求分組，以便所述通信請求分組被定向到重定向服務器，以及超文本傳輸協(xié)議(HTTP)命令從所述重定向服務器被傳輸?shù)剿鲆粋€客戶端設(shè)備，其中，所述HTTP命令指定所述一個客戶端設(shè)備將通信重定向到所述修復節(jié)點，以便修復服務可以經(jīng)由所述修復節(jié)點被提供到所述一個客戶端設(shè)備。
2.根據(jù)權(quán)利要求1所述的交換機，其中，用于標識的所述微處理單元支持裝置包括用 于在三元內(nèi)容尋址存儲器(TCAM)中指派所述單個共同標簽作為所述子集客戶端中的每一 個的標識的一部分的微處理單元支持裝置。
3.根據(jù)權(quán)利要求2所述的交換機，其中，所述子集客戶端中的每一個還具有相關(guān)聯(lián)的 地址，所述地址對于所述子集客戶端設(shè)備中的每一個是唯一的，其中，所述地址是以下中的 一個所述客戶端的媒體訪問控制(MAC)地址、與所述客戶端相關(guān)聯(lián)的實際物理端口地址 以及所述客戶端的IP地址。
4.根據(jù)權(quán)利要求2所述的交換機，其中，所述用于確定的微處理單元支持裝置包括確 定與所述一個客戶端設(shè)備相關(guān)聯(lián)的所述地址是否包含所述單個共同標簽的所述TCAM。
5.根據(jù)權(quán)利要求1所述的交換機，其中，所述用于處理的微處理單元支持裝置包括用 于在所述通信請求分組的目的地地址和重定向服務器的地址之間實施網(wǎng)絡(luò)地址轉(zhuǎn)換(NAT) 以便所述通信請求分組被轉(zhuǎn)發(fā)到所述重定向服務器的微處理單元支持裝置。
6.根據(jù)權(quán)利要求5所述的交換機，其進一步包括用于從所述重定向服務器向所述客戶 端設(shè)備傳輸命令的微處理單元支持裝置，所述命令指導所述客戶端設(shè)備將它的通信請求重 定向到所述修復節(jié)點，在所述命令的傳輸中包含后者的地址。
7.根據(jù)權(quán)利要求6所述的交換機，所述命令被設(shè)計為由所述客戶端設(shè)備采取動作，以 促使后者在接收所述命令時向所述修復節(jié)點傳輸進一步的通信請求，以及促使所述客戶端 設(shè)備加入與所述修復節(jié)點的通信，以便實現(xiàn)所述修復服務。
8.一種用于在計算網(wǎng)絡(luò)中將客戶端設(shè)備定向到修復節(jié)點的方法，所述方法包括以下步驟以單個共同標簽標識所述客戶端設(shè)備中要接收修復服務的子集； 確定所述客戶端設(shè)備中發(fā)起通信請求分組的一個客戶端設(shè)備是否由所述單個共同標 簽標識；當確定所述一個客戶端設(shè)備由所述單個共同標簽標識時，如下處理它的通信請求分組將所述通信請求分組定向到重定向服務器，以及從所述重定向服務器向所述一個客戶端設(shè)備傳輸超文本傳輸協(xié)議(HTTP)命令，所述超文本傳輸協(xié)議(HTTP)命令指定所述一個客戶端設(shè)備將通信重定向到所述修復節(jié)點，以 便修復服務可以經(jīng)由所述修復節(jié)點被提供到所述一個客戶端設(shè)備。
9.根據(jù)權(quán)利要求8所述的方法，其中，所述標識步驟包括在三元內(nèi)容尋址存儲器 (TCAM)中指派所述單個共同標簽作為所述子集客戶端的每一個的標識的一部分；以及其中，所述子集客戶端的每一個的所述標識還包括對于所述子集客戶端設(shè)備的每一個 唯一的地址，其中，所述地址是以下中的一個所述客戶端的媒體訪問控制(MAC)地址、與 所述客戶端相關(guān)聯(lián)的實際物理端口地址以及所述客戶端的IP地址。
10.根據(jù)權(quán)利要求8所述的方法，其中，所述定向步驟包括在所述通信請求分組的目的 地地址和重定向服務器的地址之間實施網(wǎng)絡(luò)地址轉(zhuǎn)換(NAT)，以便所述通信請求分組被轉(zhuǎn) 發(fā)到所述重定向服務器；以及進一步包括從所述重定向服務器向所述客戶端設(shè)備傳輸命令，所述命令指導所述客戶 端設(shè)備，通過NAT偽造來自所述客戶端的所述通信請求分組的原始目的地，將其通信請求 重定向到所述修復節(jié)點，在所述命令的傳輸中包含后者的地址。
全文摘要
提供了一種在計算網(wǎng)絡(luò)中將客戶端設(shè)備重定向到修復節(jié)點的示例性方法。以單個共同標簽標識所述客戶端設(shè)備中要接收修復服務的子集。當確定所述客戶端設(shè)備中發(fā)起通信請求分組的一個客戶端設(shè)備是由所述單個共同標簽標識時，通過將所述通信請求分組路由到重定向服務器來處理所述通信請求分組，并且從所述重定向服務器向所述一個客戶端設(shè)備傳輸超文本傳輸協(xié)議(HTTP)命令，所述超文本傳輸協(xié)議(HTTP)命令指定所述一個客戶端設(shè)備將通信重定向到所述修復節(jié)點，以便修復服務可以經(jīng)由所述修復節(jié)點被提供到所述一個客戶端設(shè)備。
文檔編號H04L29/06GK101878630SQ200880118162
公開日2010年11月3日 申請日期2008年11月26日 優(yōu)先權(quán)日2007年11月29日
發(fā)明者D·摩根, J·奧拉坎吉爾, J·翁, L·M·古德溫, L·羅斯, P·凱拉薩姆, R·L·桑格羅尼茲, S·克勞森, S·迪格赫 申請人:阿爾卡特朗訊公司