[發明專利]一種公網IP地址資源管理分配方法

有效

• 申請號: 201210126167.3
• 申請日: 2012-04-26
• 公開（公告）號: CN103067531A
• 公開（公告）日: 2013-04-24
• 發明（設計）人: 吳鍵銘
• 申請（專利權）人: 安美世紀（北京）科技有限公司
• 主分類號: H04L29/12
• 分類號: H04L29/12;H04L12/46
• 代理公司: 北京衛平智業專利代理事務所(普通合伙) 11392
• 代理人: 郝亮

技術領域

本發明涉及一種公網IP地址資源管理分配方法，特別是在公網IP地址相對短缺的酒店及其他公共場所的公用網絡，包括客房有線/無線網絡，以及酒店會議室，大堂等公共區域的有線和無線網絡中公網IP地址管理和分配方法。

背景技術

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

共享NAT基本可以保證大多數客人的網絡應用正常訪問Internet，但是在一些商務客人較為集中的中高端酒店，NAT可能會因為無法兼容一些特殊的網絡應用使得客人在應用過程發生異常從而引起客人的服務投訴。具體體現在：

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

①.AH即Authentication?Header，是在IP?header之后插入一個認證頭部，對整個IP?Packet做完整性校驗以保證IP?Packet在傳輸過程中沒有被篡改。而NAT過程是必須要修改IP?Header的IP地址字段信息以及TCP/UDP?Header的端口字段信息的，顯然，IPSec的AH封裝肯定是無法穿越NAT環境的。

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

綜上所述，IPSec中只有ESP封裝的Tunnel模式才有可能通過NAT環境。為了更好地兼容NAT環境，IETF已經發展出了的IPSec?NAT-T標準(RFC?3947和3948)，在IPSec報文之上再增加一層UDP封裝，可以完全解決NAT兼容問題。IPSec?VPN設備長時間來得到了非常廣泛的的應用和部署，雖然NAT-T的標準已經推出，仍然有相當一部分的企業因為各種原因繼續沿用原有的不支持NAT-T標準的IPSec?VPN設備，而沒有進行升級或者更換設備。

對于NAT環境中IPSec?VPN問題的解決，通常的辦法是在酒店公共網絡的出口路由器或者寬帶接入網關上配置1∶1的Static?NAT規則，或者直接給客人的電腦手工配置公網IP地址。