【文章內(nèi)容簡介】 組網(wǎng)方式 IPVPN 的聯(lián)網(wǎng)方式大致有三種： 固定 IP 與固定 IP； 固定 IP 與動態(tài) IP； 動態(tài) IP 與動態(tài) IP。 第一種的聯(lián)網(wǎng)方式是比較傳統(tǒng)的方式，技術(shù)上實現(xiàn)最容易，目前的防火墻等設(shè)備就可以實現(xiàn)這種功能；第二種的 VPN 聯(lián)網(wǎng)方式對于目前大多數(shù)專業(yè)的 VPN 廠商也基本能解決；而第三種方式即動態(tài) IP 與動態(tài) IP 之間的 VPN 通訊卻成了很多廠商和科研機構(gòu)望而卻步的技術(shù)難題，實現(xiàn)起來并解決大規(guī)模的實際應用就更加困難。 xxx 公司 作為國內(nèi)領(lǐng)先的專業(yè) VPN 廠商，投入了很大的人力、財力，經(jīng)過一 段時間的攻關(guān)和研究，最終以 “策略服務器” 的方式解決了這個難題。 “策略服務器” 管理系統(tǒng)由 Dynamic VPN 管理服務器、網(wǎng)絡管理員和 Dynamic VPN 網(wǎng)元組成。 Dynamic 管理服務器由 WEB 服務器、管理應用服務器、數(shù)據(jù)庫服務器組成。 WEB服務器負責以 WEB 服務的形式對外提供各種管理服務，管理應用服務器完成具體的邏輯與業(yè)務處理功能，數(shù)據(jù)庫服務器負責保存 Dynamic VPN 管理所需要的各種數(shù)據(jù)，它可以是關(guān)XX 集團 VPN 網(wǎng)絡建設(shè)解決方案 第 10 頁 共 25 頁 系數(shù)據(jù)庫和 /或 LDAP 服務器。 xxx 公司 的 “策略服務器 ”不但真正解決了全動態(tài)的 VPN 組網(wǎng)方案，還融入了 PKI 技術(shù)，采用基于數(shù)字證書的動態(tài) IKE 進行協(xié)商和認證，解決了大規(guī)模 VPN 組網(wǎng)的安全管理和安全認證技術(shù)。 基于 IPVPN 中 NAT 穿透問題 基于 IPsec 的 VPN 解決方案中 NAT 穿透問題一直是很多廠商以及客戶所棘手的問題。不但 IPsec 協(xié)議本身不能穿透 NAT 設(shè)備，就是常用的視頻、語音等通訊方式所用的 和 SIP 協(xié)議也不能穿透 NAT。下面以 A、 B 兩地實現(xiàn)視頻會議為例，闡述一下 NAT 穿透問題。 我們假設(shè)在 寬帶城域網(wǎng) 有兩個用戶 A 和 B，其中 A 用戶處在私網(wǎng)內(nèi)部， B 用戶是在Inter 公網(wǎng)上，這兩個用戶都 安裝了 IP 視頻會議終端，希望通過 寬帶城域網(wǎng)開個臨時的視頻會議。 如下圖示， B 用戶首先呼叫 A 用戶， B 用戶發(fā)出的 或 SIP 建立會話連接的初始化包發(fā)送到 A 用戶網(wǎng)絡的 NAT 設(shè)備時，由于 NAT 設(shè)備只做 IP 地址轉(zhuǎn)換的處理，因此不知道該如何將 B用戶發(fā)來的 或 SIP 建立會話連接的初始化包轉(zhuǎn)發(fā)給內(nèi)網(wǎng)的哪個用戶，只好將該初始化包丟棄。而 A 用戶雖然一直在等待 B 用戶的初始化包，但 A 用戶卻永遠等不到 B 用戶的初始化包，這樣 A 用戶和 B 用戶永遠都建立不起來 或 SIP 會話連接，也就無法開 IP 視頻會議。 圖 32 NAT 穿透問題示意圖（一） 另一種情況也一樣，由 A 用戶首先呼叫 B 用戶，如下圖示， A 用戶發(fā)出的 或 SIP建立會話連接的初始化包發(fā)送到 A 用戶網(wǎng)絡的 NAT 設(shè)備時，由于 NAT 設(shè)備只做 IP 地址轉(zhuǎn)換的處理， NAT 設(shè)備將該 IP 包包頭中的 A 用戶私網(wǎng)地址替換成自己的公網(wǎng)地址，這樣 A用戶發(fā)出的 或 SIP 建立會話連接的初始化包才能夠發(fā)送 B 用戶處， B 用戶上層的 視頻XX 集團 VPN 網(wǎng)絡建設(shè)解決方案 第 11 頁 共 25 頁 會議應用程序收到該初始化包，并作出應答，但是 A 用戶在發(fā)出 或 SIP 建立會話連接 的初始化包時，在上層應用數(shù)據(jù)包中采用的地址是 A 用戶的私網(wǎng)地址，這樣 B 用 戶上層的 視頻會議應用程序就會采用初始化包中上層應用數(shù)據(jù)包里的 A 用戶的私網(wǎng)地址來發(fā)送應答包，由于 A 用戶的地址是私網(wǎng)地址，因此該應答包就無法在公網(wǎng)上傳送。 這樣 A 用戶和B 用戶還是建立不起來 或 SIP 會話連接，還是無法開 IP 視頻會議。 圖 33 NAT 穿透問題示意圖（二） xxx 公司 作為國內(nèi)領(lǐng)先的專業(yè) VPN 廠商，經(jīng)過一段時間的 攻關(guān)和研究，初步解決了 NAT穿透問題，為企業(yè)構(gòu)建跨城域網(wǎng)的 VPN 網(wǎng)絡以及視頻、語音通訊的建立提供了解決方案。 如果需要實現(xiàn)穿越 NAT 的安全連接，需要在內(nèi)部網(wǎng)絡和外部網(wǎng)絡之間設(shè)置 ADT 引擎（需要在 NAT 設(shè)備上為 ADT 引擎作靜態(tài)地址翻譯）或者在外網(wǎng)（公網(wǎng)）設(shè)置 ADT 引擎。 ADT引擎是一個專用 UDPT(即 UDP 隧道 )數(shù)據(jù)包的路由轉(zhuǎn)發(fā)軟件，放置在網(wǎng)絡邊緣，在內(nèi)部網(wǎng)絡和外部網(wǎng)絡之間轉(zhuǎn)發(fā)數(shù)據(jù)流量。 下面為數(shù)據(jù)包的結(jié)構(gòu)： UDPT 封裝 標準 IP 報文 IP Tunnel Header UDP Header UDPT header IP virtual header IPSec headers(optional) Pay load XX 集團 VPN 網(wǎng)絡建設(shè)解決方案 第 12 頁 共 25 頁 UDPT 包在經(jīng)過 ADT 引擎轉(zhuǎn)發(fā)時， ADT 引擎根據(jù) UDPT 包內(nèi)的 UDPT Header 域所指定的路由信息來更換 UDPT 包 IP Tunnel Header 域的源地址和目的地址，從而完成從一個私網(wǎng)成員到另一個私網(wǎng)成員的包轉(zhuǎn)發(fā)，而 UDPT 包內(nèi)部的 IP Virtual Header 的源地址和目的地址始終保持不變，保證了上層應用中 IP 地址的完整性，從而實現(xiàn) IPSec、 SIP 等多媒體協(xié)議端到端通信的完整性 。 系統(tǒng)設(shè)計功能分析 企業(yè)建設(shè)安全的信息系統(tǒng)，一個前提是不能改變原 有的應用方式，并且既要保證安全的遠程訪問（加密），又要和正常的直接訪問（明文）相兼容，適合多種多樣的應用需求。 按照本方案建設(shè)的網(wǎng)絡安全系統(tǒng)，將在不改變應用系統(tǒng)結(jié)構(gòu)和用戶的使用習慣已經(jīng)與正常訪問兼容的基礎(chǔ)之上，為 XX 集團的信息系統(tǒng)提供強有力的安全保障，并在移動接入、分支機構(gòu)網(wǎng)絡等方面為企業(yè)節(jié)省成本，帶來直接的效益。 VPN 系統(tǒng)對原有系統(tǒng)的兼容 VPN 安全網(wǎng)關(guān)遵循標準的 Ipsec 和 IKE 協(xié)議，在網(wǎng)絡層對 IP 數(shù)據(jù)包進行加密，對網(wǎng)絡中的數(shù)據(jù)流做基于五元組的訪問控制，因此，對于應用系統(tǒng)是完全透明的，即上 層的應用程序感覺不到數(shù)據(jù)在傳輸過程中被加密；也就是最終用戶感覺不出使用了 VPN 前后在網(wǎng)絡系統(tǒng)上有什么不同，也不必對自己平時的使用習慣做任何改變；應用程序的開發(fā)商也不需要對在 VPN 上使用的系統(tǒng)做特別的修改。在 XX 集團內(nèi)部，無論是目前已投入使用的多套應用系統(tǒng)，還是以后的新系統(tǒng)，不管系統(tǒng)平臺如何，采用的結(jié)構(gòu)是傳統(tǒng)的 C/S 還是 B/S，都將可以平滑過渡到 VPN 網(wǎng)絡平臺上使用。 Ipsec 協(xié)議決定了只要在網(wǎng)絡傳輸上使用 TCP/IP 協(xié)議的應用系統(tǒng)，都可以在 VPN 平臺下正常運行，然而在 TCP/IP 協(xié)議作為事實上的工業(yè)標準的今天，任何新開發(fā)的應用系統(tǒng)都是基于此的，因此對于將來的 ERP 等系統(tǒng)修改、擴展乃至增加系統(tǒng)等等， VPN 系統(tǒng)完全不需更改，不必要擔心應用系統(tǒng)的兼容性問題。 VPN 系統(tǒng)對原有網(wǎng)絡的兼容 由于根據(jù)網(wǎng)絡設(shè)計 VPN 設(shè)備 —— VPN 安全網(wǎng)關(guān)將會串行的連接在總部的路由器之后，XX 集團 VPN 網(wǎng)絡建設(shè)解決方案 第 13 頁 共 25 頁 并將作為分公司的路由設(shè)備為網(wǎng)絡提供路由，因此，在增加了這個設(shè)備后會不會影響原有正常的網(wǎng)絡訪問，比如 WEB、 MAIL、 DNS 等等是一個必須說明并確認的問題。 這個問題可以分為二個方面來討論，首先是內(nèi)部的服務器是否能象原來一樣向外提供服務，其次是內(nèi)部網(wǎng)絡用戶是否能正常訪問互聯(lián)網(wǎng)（ Inter）。下面將就這二點分別闡述。 1） 服務器單獨放在一個子網(wǎng)中，使用私有 IP 地址，對外是不可見的，但可以通過在 VPN 安全網(wǎng)關(guān)上配置靜態(tài)端口映射，使得外部網(wǎng)絡可以訪問到該服務器的某端口，而通常服務器都是通過 TCP 或 UDP 的某一個的端口來提供服務（比如 WEB 使用 TCP 的 80 端口， DNS 使用 UDP 的 53 端口等等），因此對于絕大多數(shù)的 應用，都可以使用靜態(tài)端口映射來滿足向外提供服務的需求。對于某些少數(shù)在網(wǎng)絡通信中使用不固定端口的應用，還可以通過靜態(tài)地址映射來達到目的，即將整個服務器映射成公有地址。這樣， XX 集團公司中所有需要公開的服務器都可以利用 VPN 安全網(wǎng)關(guān)的靜態(tài)端口映射和靜態(tài)地址映射向外提供服務。 2） 內(nèi)網(wǎng)主機眾多，可是公有 IP 地址有限，要訪問互聯(lián)網(wǎng)必須通過地址轉(zhuǎn)換來實現(xiàn)，VPN 安全網(wǎng)關(guān)的地址池映射功能可以滿足提供內(nèi)部網(wǎng)絡上互聯(lián)網(wǎng)的要求，并且還可以對上網(wǎng)的主機和時間段作出控制。同樣，對于分公司的子網(wǎng)，也可以通過 VPN 安全網(wǎng)關(guān)的地址池映射功 能提供內(nèi)部主機的上網(wǎng)。 為滿足以上二點采用的各種技術(shù)和 VPN 安全加密功能都可以同時發(fā)揮作用， VPN 安全網(wǎng)關(guān)將根據(jù)數(shù)據(jù)包的 IP 地址和端口（五元組）信息自動地對 IP 數(shù)據(jù)包作出相應地處理，達到以上的目的。即 VPN 系統(tǒng)與原有的網(wǎng)絡系統(tǒng)完全兼容，絕不會因建設(shè)了 VPN 系統(tǒng)而導致原有的正常訪問中斷或改變方式。 網(wǎng)絡層的訪問控制和身份認證 VPN 系統(tǒng)在網(wǎng)絡層實現(xiàn)了訪問控制和身份認證功能。當一個用戶需要訪問受網(wǎng)關(guān)保護的服務器的信息時， VPN 安全網(wǎng)關(guān)首先根據(jù)預先配置的策略判斷對方的 IP 地址是否授權(quán)的用戶，如果有為對 方配置的策略，則開始 IKE 密鑰協(xié)商，密鑰協(xié)商包含了身份認證的過程，在基于 PKI 體系下的身份認證能很好地確保網(wǎng)絡訪問的安全性和唯一性。只有在 IKE 密鑰協(xié)商成功以后， VPN 安全網(wǎng)關(guān)才會把服務器的返回數(shù)據(jù)通過加密發(fā)送到客戶端；對進來的數(shù)據(jù)進行完整性校驗和解密。 XX 集團 VPN 網(wǎng)絡建設(shè)解決方案