宽带私网双栈地址溯源的云化实现

2021-11-11 06:04张承立何肖嵘宋蔚芳
电信科学 2021年10期
关键词:双栈公网云化

张承立,何肖嵘,宋蔚芳

(中国电信股份有限公司上海分公司,上海 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平台解耦后的私网双栈溯源系统,使现网认证无须改造,也能支持私网双栈的宽带业务,并通过溯源系统云化部署,在云计算和云存储的支撑下,提供更好的溯源大数据处理,能更灵活地满足运营商在运维及网络安全要求下海量溯源数据留存的需求。

猜你喜欢
双栈公网云化
浅析大临铁路公网覆盖方案
公网铁路应急通信质量提升的技术应用
5G/云化下的VR产业未来
如何迎接公网对讲的春天
浅析IPv6网络演进及其部署方案
IBM中国企业云化实践中心成立
基于公网短信的河北省高速公路数据传输应用
核心网云化技术的分析
IPv4到IPv6演进技术及策略探讨
IPv4和IPv6双栈计费流程分析