[發(fā)明專(zhuān)利]一種公網(wǎng)IP地址資源管理分配方法

有效

• 申請(qǐng)?zhí)枺?/td>: 201210126167.3
• 申請(qǐng)日: 2012-04-26
• 公開(kāi)（公告）號(hào): CN103067531A
• 公開(kāi)（公告）日: 2013-04-24
• 發(fā)明（設(shè)計(jì)）人: 吳鍵銘
• 申請(qǐng)（專(zhuān)利權(quán)）人: 安美世紀(jì)（北京）科技有限公司
• 主分類(lèi)號(hào): H04L29/12
• 分類(lèi)號(hào): H04L29/12;H04L12/46
• 代理公司: 北京衛(wèi)平智業(yè)專(zhuān)利代理事務(wù)所(普通合伙) 11392
• 代理人: 郝亮

技術(shù)領(lǐng)域

本發(fā)明涉及一種公網(wǎng)IP地址資源管理分配方法，特別是在公網(wǎng)IP地址相對(duì)短缺的酒店及其他公共場(chǎng)所的公用網(wǎng)絡(luò)，包括客房有線/無(wú)線網(wǎng)絡(luò)，以及酒店會(huì)議室，大堂等公共區(qū)域的有線和無(wú)線網(wǎng)絡(luò)中公網(wǎng)IP地址管理和分配方法。

背景技術(shù)

由于IPv4公網(wǎng)地址資源的短缺問(wèn)題，電信運(yùn)營(yíng)商通常只會(huì)給酒店的公共網(wǎng)絡(luò)internet出口分配很少的IP地址，比如從幾個(gè)到幾十個(gè)不等。顯然，在公網(wǎng)IP地址這么少的情況下，酒店是無(wú)法保證為每個(gè)接入到酒店公共網(wǎng)絡(luò)的智能終端(包括筆記本電腦，智能手機(jī)，平板電腦等)直接分配公網(wǎng)IP地址的，而通常是為各個(gè)上網(wǎng)終端分配RFC?1918規(guī)定的私網(wǎng)地址，然后在酒店公共網(wǎng)絡(luò)的出口的路由器或者寬帶接入網(wǎng)關(guān)上啟用NAT，使得所有分配私網(wǎng)IP地址的上網(wǎng)終端能夠共享有限的公網(wǎng)IP地址訪問(wèn)Internet。最典型的應(yīng)用配置是在出口的路由器或者寬帶接入網(wǎng)關(guān)上只配置一個(gè)公網(wǎng)地址，啟用N:1的共享NAT規(guī)則，使得所有住店客人和非住店客人都共享一個(gè)公網(wǎng)IP地址上網(wǎng)。

共享NAT基本可以保證大多數(shù)客人的網(wǎng)絡(luò)應(yīng)用正常訪問(wèn)Internet，但是在一些商務(wù)客人較為集中的中高端酒店，NAT可能會(huì)因?yàn)闊o(wú)法兼容一些特殊的網(wǎng)絡(luò)應(yīng)用使得客人在應(yīng)用過(guò)程發(fā)生異常從而引起客人的服務(wù)投訴。具體體現(xiàn)在：

1.IPSec?VPN與NAT可能存在的不兼容問(wèn)題。IPSec的控制連接使用是的UDP會(huì)話，而數(shù)據(jù)連接使用的是非TCP/UDP協(xié)議，包括AH和ESP兩種協(xié)議封裝形式。

①.AH即Authentication?Header，是在IP?header之后插入一個(gè)認(rèn)證頭部，對(duì)整個(gè)IP?Packet做完整性校驗(yàn)以保證IP?Packet在傳輸過(guò)程中沒(méi)有被篡改。而NAT過(guò)程是必須要修改IP?Header的IP地址字段信息以及TCP/UDP?Header的端口字段信息的，顯然，IPSec的AH封裝肯定是無(wú)法穿越NAT環(huán)境的。

②.ESP即Encapsulation?Security?Payload，同樣是在IP?Header后插入一個(gè)新的認(rèn)證頭部，但是行為與AH有所不同。ESP包含transport和tunnel兩種模式。ESP的transport模式只對(duì)原IP?Packet中除了IP?header的部分進(jìn)行校驗(yàn)，也就是之針對(duì)IP?Payload部分進(jìn)行校驗(yàn)，顯然，這種行為與NAT也是沖突的，典型的是與TCP的沖突，TCP?Header的檢驗(yàn)算法是關(guān)聯(lián)了IP?Header的源和目的IP地址字段信息的，那么NAT對(duì)IP?Header的更改必將會(huì)使得原先的TCP?Header失效，因此，ESP的transport也無(wú)法與NAT共存。ESP的tunnel模式是生成一個(gè)全新的IP?header，然后再在這個(gè)新的IP?Header之后再封裝/加密原先的整個(gè)IP?Packet，這個(gè)情況下NAT對(duì)IP?Header的IP地址字段更改不會(huì)影響到IPSec的校驗(yàn)，也不會(huì)影響被封裝的TCP或UDP的頭部校驗(yàn)，但是仍然有問(wèn)題。ESP協(xié)議設(shè)計(jì)上有類(lèi)似TCP/UDP?Port作用的SPI，但是對(duì)ESP的SPI進(jìn)行轉(zhuǎn)換復(fù)用需要跟蹤IPSec關(guān)聯(lián)的IKE會(huì)話，在技術(shù)上是非常復(fù)雜的可行性并不高。所以通常對(duì)ESP只能做1∶1的Static?NAT，也就是說(shuō)，在只有一個(gè)出口公網(wǎng)IP地址做NAT的酒店里，同一個(gè)公司的多個(gè)客人，同一時(shí)刻只能有一個(gè)客人能夠撥通ESPtunnel模式的IPSec?VPN。

綜上所述，IPSec中只有ESP封裝的Tunnel模式才有可能通過(guò)NAT環(huán)境。為了更好地兼容NAT環(huán)境，IETF已經(jīng)發(fā)展出了的IPSec?NAT-T標(biāo)準(zhǔn)(RFC?3947和3948)，在IPSec報(bào)文之上再增加一層UDP封裝，可以完全解決NAT兼容問(wèn)題。IPSec?VPN設(shè)備長(zhǎng)時(shí)間來(lái)得到了非常廣泛的的應(yīng)用和部署，雖然NAT-T的標(biāo)準(zhǔn)已經(jīng)推出，仍然有相當(dāng)一部分的企業(yè)因?yàn)楦鞣N原因繼續(xù)沿用原有的不支持NAT-T標(biāo)準(zhǔn)的IPSec?VPN設(shè)備，而沒(méi)有進(jìn)行升級(jí)或者更換設(shè)備。

對(duì)于NAT環(huán)境中IPSec?VPN問(wèn)題的解決，通常的辦法是在酒店公共網(wǎng)絡(luò)的出口路由器或者寬帶接入網(wǎng)關(guān)上配置1∶1的Static?NAT規(guī)則，或者直接給客人的電腦手工配置公網(wǎng)IP地址。