寬帶私網雙棧地址溯源的云化實現

張承立，何肖嶸，宋蔚芳

（中國電信股份有限公司上海分公司，上海 200122）

1 引言

2011年4月，IANA（Internet Assigned Numbers Authority）宣布IPv4地址池剩下最后一個A類地址，全球各大運營商都將互聯網IPv6的演進提上日程。IPv4向IPv6的遷移過程中，由于IPv6無法兼容IPv4，產生了隧道及雙棧兩種過渡方案。因現網用戶和業務大多承載在IPv4網絡上，在IPv6終端及應用未大量普及前，運營商為保證平滑過渡，并兼顧后期純IPv6的目標，往往采用IPv4/IPv6雙棧的方案，同時實施IPv4地址的私網化改造，解決IP資源緊缺的問題，最終實現純IPv6的全網部署。

鑒于國家網絡安全和信息化委員會對現網運維的相關要求，CGN、BRAS、AAA等網絡設備，需要保存6個月以上的用戶日志，然而私網雙棧過渡期間，地址類型將涵蓋IPv4公網、IPv4私網、IPv6地址，并涉及IP地址端口映射，地址類型的多樣性及兼容模式與各網絡設備交互量成倍增長，對IP地址溯源的傳統物理架構下，各設備大量離散數據的分布式處理、硬盤頻繁讀/寫產生的物理硬件損壞率的提升，以及突發請求下系統性能的靈活擴展，提出了挑戰。而溯源云化實現方式，較好地解決了這些問題。

2 寬帶私網雙棧IP溯源模型

IP地址雙協議棧技術指在一臺設備上同時啟用IPv4協議棧和IPv6協議棧，這臺設備既能和IPv4網絡通信，又能和IPv6網絡通信。固網寬帶私網雙棧，作為IPv6過渡期的運營商實施方案，關鍵是引入了NAT444，通過兩次IPv4的地址網絡地址轉換（network address translation，NAT）映射，將用戶側的IPv4私網地址對應到電信側的IPv4公網地址端口范圍，大幅提升了IPv4公網地址復用率，延長了IPv4的生命周期，同時也為IPv6的最終部署爭取了寶貴的時間。

IPv4兩次NAT映射分別發生在電信末端的接入設備家庭網關及上層多業務邊緣路由器（multi-service edge router，MSE），如圖1所示。通過NAT映射，首先將一個公網地址65 536個端口按每段4 096個分割為16段端口范圍，單個用戶寬帶認證通過后，最終分配到可使用的IPv4公網資源為一個公網地址加4 096個端口，這一做法實現了IPv4公網地址1:16的復用，相當于直接將運營商現有的IPv4資源擴容了近16倍。但不同的用戶可同時使用相同的IPv4公網地址，加上IPv6地址，大幅增加了溯源的復雜度。

圖1 IPv4私網化的兩次NAT映射

鑒于同一IPv4公網地址可分配不同用戶，以及不同MSE設備可以統一配置模板下發相同的電信側私網地址，原有IPv4公網地址+時間戳的溯源將無法唯一定位上網賬號，新IPv6+IPv4私網雙棧的溯源模型如圖2所示。

圖2 私網雙棧的溯源模型

客戶終端設備（customer premise equipment，CPE）在上網認證、授權和計費（authentication authorization and accounting，AAA）時，對于私網雙棧的場景，MSE會下發電信側的IPv4私網地址為100.X.X.X的地址及240E開頭的IPv6地址。

對于溯源系統而言，需要采集處理如下信息。

? 遠程認證撥號用戶服務（remote authentication dial-in user service，RADIUS）日志，包含用戶私網IP地址、接入設備NASIP。

? 運營商級NAT（carrier-grade NAT，CGN）日志，包含CGN標識、私網IP、映射后公網IP地址、分配的編口范圍。

匹配步驟如下：

? 通過RADIUS日志、NAT日志的私網IP、時間戳進行匹配查找；

? 根據 NAT日志的CGN 標識與RADIUS的NASIP是否相同，判斷是否是同一NAT域；

? 采集MSE設備CGN板卡通過Syslog推送的IP地址映射記錄，從而獲得公、私網地址及端口段的對應關系；

? 將上述信息合成，最終將寬帶賬號、上聯MSE、IPv4私網地址、IPv4公網地址、端口范圍、IPv6地址以及上下線的時間等信息，合成為一條記錄。

得到合成記錄后，溯源的查證通過IPv4公網地址+端口（或IPv6地址）+時間戳，反向對應到具體上網賬號的過程，如圖3所示。

圖3 私網雙棧溯源過程

事實上，地址、端口、時間戳3個要素便可以溯源到唯一的上網賬號。而溯源在時間上的一致性，通過網絡側設備、平臺側設備與多級時鐘源同步完成。

通常，時間同步網由各節點時鐘和傳遞同步定時信號的同步鏈路構成。同步網的主要功能是準確地將網絡中的各級時鐘與基準時鐘建立并保持信號同步，滿足通信網整體在時間上的高度一致性。各級時鐘源同步確保溯源時間一致如圖4所示，圖4中一級TS時鐘源，可由自主運行的銫原子鐘組或銫原子鐘與衛星定位系統（GPS和/或GLONASS及其他定位系統）組成，作為同步網的全網時鐘基準。二級TS時鐘源可作為區域時鐘的基準，通過向一級TS時鐘源同步或可同時接收GPS等作同步校準。三級TS時鐘源則可在二級時鐘源的基礎上擴展，以滿足區域內的設備及相關業務的時間同步需求。

圖4 各級時鐘源同步確保溯源時間一致

本文中的溯源平臺及相關網絡設備，與三級TS時鐘源同步完成用戶上網請求時RADIUS報文的時間戳、MSE上公轉私NAT Syslog報文時間戳、溯源平臺的本地時間戳等保持一致。溯源合成記錄中所取時間是相關報文時間戳的值，這個值由時鐘同步的網絡設備插入，與用戶側的終端設備時間是否準確并沒有關系。可確保從不同的用戶設備、不同的區域、不同的網元線路上網，只要提供正確的IP地址、上網端口及時間戳3個要素便可以精準地溯源唯一上網賬號。

值得注意的是，由于網絡傳輸存在一定的時延，不同的網絡設備廠商對IPv4及IPv6報文處理方式和順序不同，現網的運行過程中，IPv4、IPv6、CGN NAT映射的請求報文在實際到達溯源平臺時會存在亂序的情況，便需以時間同步為基礎，通過緩存進行二次關聯，盡可能滿足在報文亂序情況，溯源記錄的完整性。例如基于Spark的內存時延關聯、二次關聯合成技術。當采集的NAT日志找不到匹配的RADIUS上下線信息時，支持臨時寫入緩存隊列，延遲一個可配置的時間段（比如30 s內）再次加載匹配。盡可能降低因設備差異、路由差異、采集時延等導致的公轉私溯源記錄匹配失敗場景。Spark內存延遲匹配技術示意圖如圖5所示。

圖5 Spark內存延遲匹配技術示意圖

3 私網雙棧溯源的業務應用

為提升用戶體驗，實現單點登錄或自動獲取用戶賬號等信息，運營商在應用側會通過IP地址信息溯源定位當前用戶，如圖6所示。

圖6 私網雙棧溯源的業務應用場景

如IPTV用戶在定購電信產品時，通過IP地址溯源用戶賬戶信息，并與機頂盒SN所登記的用戶賬戶對比，實現用戶身份的一致性校驗，滿足用戶無感訂購的需求，同時加強訂購過程的安全性。用戶通過網上營業廳進行測速時，無須輸入賬號，點擊開始測速，便可以得出該用戶簽約速率是否測速達標。其通過溯源，定位用戶當前的上網賬號，進而返回該用戶在運營商處的簽約速率，與實際測速速率進行比較。

在溯源系統提供了私網雙棧的溯源能力后，應用需確認如何獲取當前用戶的IP地址和端口信息。需要注意的是，在使用nginx（一種高性能的HTTP和反向代理Web服務器）、防火墻Server NAT等場景下，應用側需保持用戶側的源地址和源端口信息，否則無法準確溯源到實際用戶。

4 私網雙棧溯源云化改造

溯源系統理論上可以利用RADIUS報文，在AAA認證計費平臺的基礎上構建緊耦合的溯源功能。考慮運營商的AAA平臺建設較早，大多為傳統的IT架構，而私網雙棧溯源在處理公私網映射、上下線報文入庫、中間計費報文更新、IPv4和IPv6上網記錄的合成、海量的歷史溯源記錄存儲及對外提供的溯源大數據查詢等能力，都更貼近云的特性。

在IPv4、IPv6利用私網雙棧平滑過渡的同時，可考慮溯源系統的云化改造，充分利用云存儲和云計算的優勢，為固網AAA整體云化提供實踐基礎。

4.1 RADIUS鏡像報文采集

為保持原有AAA架構不變，且不影響現網業務的正常使用，可采用鏡像報文采集的方式，如圖7所示，獲取RADIUS的所有認證計費報文，并由MSE的CGN板卡發送NAT映射Syslog報文給溯源平臺，以便獲取溯源所需的必要信息。固網AAA鏡像流量采集如圖7所示。

圖7 固網AAA鏡像流量采集

4.2 溯源記錄合成

采集數據處理示意圖如圖8所示，使用Flume分布式數據采集服務框架，可以通過分布式部署、平滑擴展支持多節點、多數據源的數據采集，充分利用現網AAA平臺的冗余架構，保證數據的完整性，并能對采集的數據進行指定預處理（例如按條件過濾或格式規整），適合于RADIUS鏡像流式數據以及CGN映射數據的處理。通過分布式計算能力，建立溯源關鍵數據的索引，提供快速查詢的能力；利用云存儲完成歷史溯源數據的海量存儲，滿足運營商的溯源及統計分析要求。

圖8 采集數據處理示意圖

4.3 溯源查詢接口

當溯源記錄合成后，根據用戶當前是否在線（是否收到斷線請求報文），可生成在線溯源庫及歷史溯源庫，針對不同的應用場景通過統一的溯源查詢中心能力接口，提供外部應用完成溯源查詢的請求，并通過能力開放平臺（enabler open platform，EOP）等，獲取業務所需的賬號關聯信息，溯源查詢接口如圖9 所示。

圖9 溯源查詢接口

溯源查詢能力也可注冊能力開放平臺，從而參與各類電信級業務能力編排，更快速、靈活地支撐業務產品所需的相關功能。

5 溯源云化實現的性能及價值分析

為驗證溯源云化實現的性能，模擬云虛機單臺配置為8核CPU、32 GB內存；數據庫組成MySQL 2×2集群的條件，400萬寬帶用戶基數溯源云化實現的部分性能指標見表1、表2、表3。

表1 單臺虛機RADIUS計費采集的性能

表2 單臺服務器上Syslog日志采集的性能

表3 數據庫合成溯源記錄增、刪、改、查的性能

云化后若使用通用的共享虛擬磁陣進行數據庫讀/寫，可能會存在與其他共享同一虛擬磁陣的應用發生I/O爭用的問題，且普通硬盤共享磁陣的I/O在測試中只能穩定在5 000 TPS（transaction per second）的讀/寫能力，通過優化為SSD的硬盤或建立內存數據庫可較好地解決這一問題。

云化虛擬機與傳統物理硬件平臺比對分析見表4。

表4 云化虛機與傳統物理硬件平臺對比

6 結束語

私網雙棧的現網部署，切實解決了IPv4地址資源耗盡問題，為互聯網應用遷移至IPv6提供了無縫過渡的可能。而與傳統AAA平臺解耦后的私網雙棧溯源系統，使現網認證無須改造，也能支持私網雙棧的寬帶業務，并通過溯源系統云化部署，在云計算和云存儲的支撐下，提供更好的溯源大數據處理，能更靈活地滿足運營商在運維及網絡安全要求下海量溯源數據留存的需求。