Copyright © 2016 杭州华三通信技术有限公司 版权所有,保留一切权利。 非经本公司书面许可,任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部, 并不得以任何形式传播。本文档中的信息可能变动,恕不另行通知。 |
数据报文在网络中传递时,往往需要经过各种各样的业务节点,才能保证网络能够按照设计要求,提供给用户安全、快速、稳定的网络服务。这些业务节点(Service Node)包括熟知的防火墙(FireWalls)、入侵检测(Intrusion Prevention System)、负载均衡(Load Balancing)等。通常,网络流量需要按照业务逻辑所要求的既定顺序穿过这些业务点,才能实现所需要的安全业务。
但是,传统安全业务的部署,通常都是基于物理拓扑,通过手工配置多种策略,将安全设备串行到业务流量路径当中。这种部署和运维的模式存在诸多问题:
· 网络设备之间的耦合性大,拓扑依赖严重。新业务上线、扩容或业务发生变更时,需要手工调整整个转发路径下设备的策略,无法满足业务快速迭代、变更的需求;
· 数据包在业务路径中转发时,往往要经过多次分类,即多次解包、封包的过程,效率低下;
· 在逐渐普及的Overlay虚拟化组网中,网络设备需要越过新增的Overlay报文头对内层报文进行检测,检测方法匮乏,性能损耗也更加严重;
· 安全设备无法池化,扩展性差,一旦出现性能不足,通常只能更换更高端的设备;
· 安全设备的能力无法在多业务间共享。
在新的网络架构下,如何利用新的技术将安全业务更好的融合进来,从而提供便捷、安全的网络架构,是各方面临的难题。
随着Overlay网络的发展,虚拟网络和物理网络得以分离,虚拟网络承载于物理网络之上,更加抽象;而SDN技术和NFV(Network Functions Virtualization,网络功能虚拟化)技术的不断发展,也让数据中心的网络控制变得更加灵活,更具有扩展性。
在SDN Overlay数据中心中,同样需要网络服务节点提供必要的安全业务处理能力。SDN以其控制转发分离的特性,通过对基础网络的虚拟化和逻辑抽象,通过网络的集中控制部件——SDN控制器的控制,可以引导转发流量自动穿过服务节点,从而实现拓扑无关的、灵活、便捷、高效、安全地调配转发流量到服务节点上进行安全业务的处理,从而形成SDN定义的Overlay虚拟网络中的服务链(Service Function Chaining)。
在SDN Overlay网络中,服务链可以理解为一种基于应用的业务形式。
基于SDN Overlay的服务链,需要有对应的字段来标识数据报文中服务链的特征,每条Chain都有自己的标识,数据包需要携带这些特征,例如:数据包应该走哪一条服务链,服务链有几跳等等。
目前,对于数据报文中这些特征的标识,有如下两种方式。
充分利用现有成熟的支持VXLAN报文的芯片,扩充其8 Bytes的VXLAN头。
H3C SDN服务链对VXLAN报文的扩展如图1所示。
图1 SDN服务链对VXLAN报文的扩展
扩展方式为,从VXLAN保留字段中:
· 取出3 Bytes作为Service Path ID,记录服务链编号,用于唯一确定一个服务链;
· 取出1Byte作为Order counter,当一个服务链多次进入一个主机下的不同服务点时,可以通过匹配Order counter确定是第几次进入该服务节点。
这种方式对硬件网络设备无依赖,仅需网络设备支持VXLAN即可,简单易行,且能满足绝大多数服务链定义的需求。但是由于没有标准推广,存在一定的技术壁垒。
NSH(Network Service Header,网络服务头)是专门为服务链设计的封装格式,并且在OpenDaylight的SFC项目中采用。其封装格式如图2所示。
图2 NSH封装格式
从上图可以看到,NSH对VXLAN报文又进行了扩展,可以携带更多的业务信息,完成更加复杂的业务处理;扩展性较强,可以支持携带多个业务上下文信息;并且其带有Protocol Type字段,因此可以承载二层用户报文、三层用户报文,较为灵活。
NSH可以承载于VXLAN、GRE等多种Overlay封装中。
但是,由于对标准VXLAN封装又进一步扩展,所以需要硬件网络设备的芯片支持这种扩展,而新型芯片推出和扩展并非易事,需要推动芯片相关的整个产业链的认同和真正的实际需求,才有可能大规模的生产,从而降低芯片乃至整个网络架构的成本。短期看,支持NSH的芯片尚无法大规模投产应用。
在当前形势下,H3C SDN服务链缺省使用扩展VXLAN头中保留字段的方式。
H3C SDN服务链,基于网络的核心控制部件SDN控制器——H3C VCF控制器进行部署。VCF控制器根据租户需求,定义、创建服务链,并部署服务链上每个节点的业务逻辑。VCF控制器将需要进入服务链处理的用户报文特征下发到接入软件/硬件VTEP,VTEP设备根据相应的报文特征将数据报文引入服务链。
H3C SDN服务链中具有如下角色:
· 流分类节点:原始数据报文的接入节点。按照定义的流分类规则匹配数据报文,对报文做服务链的Overlay封装,并将其转发到服务链中处理。
· 服务节点:服务节点作为资源被分配使用,它的物理位置可以是任意的、分散的,通过SDN对服务链的定义和引流串联,完成预定义的工作。服务节点可以是防火墙(FireWalls)、负载均衡(LoadBalance)、入侵检测(Intrusion Prevention System)等资源/资源池。
· 代理节点:对于不支持服务链封装的服务节点,需要通过代理节点剥离服务链封装,再转交给服务节点处理。
· 控制平面:负责管理服务链域内的设备以及创建服务链,并将服务节点的配置定义下发到相关节点上。在H3C SDN网络中,通过VCF控制器实现。
图3中各角色及其对报文的处理方式如下:
· VCF控制器:H3C SDN控制器。作为网络资源池的唯一控制点,它控制了虚拟化网络,并且通过对虚拟网络进行抽象和编排,定义服务链特征。VTEP和服务节点上的转发策略都由控制器下发。
· 服务链流分类节点(VTEP1):原始报文通过VTEP1接入VXLAN网络,并直接进行流分类以确定报文是否需要进入服务链。如果需要进入服务链,则为报文进行VXLAN和服务链ID封装,并转发到服务链首节点进行处理。
· 服务链首节点(SF1):服务链中对报文进行处理的首个服务节点。首节点对数据报文进行服务处理后,将数据报文继续做服务链封装并转发给服务链的下一个服务节点。
· 服务链尾节点(SF2):服务链中对报文进行处理的最后一个服务节点。尾节点对数据报文进行服务处理后,解除其服务链封装,并将报文做普通VXLAN封装后转发给目的VTEP。如果尾节点不具备根据用户报文寻址能力,则需要将用户报文送到网关(VTEP3),网关再查询目的VTEP进行转发。
报文转发说明如下:
· ①⑥Native以太报文,IP(src)---->IP(dst)
· ② VXLAN+业务链报文,外层: IP(VTEP1)---->IP(SF1)
· ③ VXLAN+业务链报文,外层: IP(SF1)---->IP(SF2)
· ④ VXLAN报文,外层: IP(SF2)---->IP(VTEP3)
· ⑤ VXLAN报文,外层: IP(VTEP3)---->IP(VTEP4)
具体的匹配转发流程描述如下:
· VM首包上送控制器处理时,在VCF控制器上解析Packet-In报文,根据报文目的地址确定是虚拟网络内的东西向流量还是通往传统网络的南北向流量。如果是南北向流量则将报文转发到网关设备,报文后续的处理由网关设备负责。
· 如果是东西向流量,从收到的Packet-In报文中提取源端口,并根据源端口确定源subnet、network、router信息;同时根据Packet-In报文的目的IP地址获取目的VM连接的目的端口,并根据目的端口确定目的subnet、network、router信息。
· 对于东西向流量,根据报文特征进行服务链匹配,首先使用源端口和目的端口的属性与服务链配置进行匹配,如果找到匹配的服务链,则下发导流流表;如果未找到匹配的服务链,则下发东西向卸载的流表项(即非服务链转发)。
· 如果存在匹配的服务链,则VCF控制器会确定服务链所在VTEP的VTEP IP,并向VTEP和后续处理节点下发流表项,流表项格式如下:
¡ Match:匹配port & vlan & 五元组的普通报文进入服务链或匹配tunnel & vni & 五元组的VXLAN报文进入服务链
¡ Action:vni & service chain id & order counter & tunnel,指向服务链首节点所在的服务节点,order counter =1。
· 当匹配到多条服务链时,按照最精确匹配的原则确定实际使用的服务链配置。服务链特征组所支持的特征按照精确程度从低到高排序依次为:Routers, Networks, Subnets, Ports。
H3C SDN服务链支持如下几种流分类节点:
· 支持服务链的vSwitch:vSwitch收到虚拟机报文后,直接做流分类;在vSwitch上进行服务链Overlay封装。例如H3C S1020V。
· 硬件交换机接入普通vSwitch:虚拟机通过普通vSwitch接入,vSwitch仅作二层交换使用,报文上送硬件交换机后由硬件交换机进行流分类以及服务链Overlay封装。例如H3C S6800交换机。
· 硬件交换机接入物理设备:硬件交换机直接接入物理设备,对物理设备发送的数据报文做流分类,进行服务链Overlay封装。例如H3C S6800交换机。
· 硬件交换机接入普通VXLAN报文:普通VXLAN报文上送到硬件交换机,由硬件交换机进行流分类,进行服务链Overlay封装。例如H3C S6800交换机。
H3C SDN服务链支持如下几种服务节点:
· H3C NFV服务节点:支持VXLAN和服务链功能。可以直接进行VXLAN封装/解封装处理以及业务处理。
· H3C硬件安全设备:支持VXLAN和服务链功能。可以直接进行VXLAN封装/解封装处理以及业务处理。
· 传统物理服务节点:第三方厂家的传统防火墙、负载均衡等无法支持服务链的安全功能节点,通过服务链代理节点(例如H3C S6800交换机)外挂。
该模式组网下,H3C VSR充当VXLAN IP GW,提供Overlay网关功能;H3C S1020V充当L2 VTEP,将虚拟机接入到VXLAN网络中,其中H3C S1020V支持运行在ESXi、KVM、H3C CAS等多种虚拟化平台上。
同时,该组网模式下的Service安全节点包括VSR、vFW、vLB等设备,通过H3C VCF控制器的集中控制和编排实现东西向和南北向服务链服务节点的功能。服务链能够支持以虚拟端口、虚拟路由器、虚拟链路层网络、虚拟子网以及IP地址等作为流量特征对需进入服务链的流量进行分流。服务链经过服务节点时先经过vFW再经过vLB。
在此场景下,依据安全服务功能的配置位置,又可以分为灵活服务链模型和OpenStack服务链模型两种。
如图4所示,服务链可以直接在VCF控制器上配置实现灵活服务链部署。
这种场景下,南北向服务链由VSR集成vFW,vLB可以独立部署;东西向服务链的vFW和vLB也可以独立部署。
如图5所示,在OpenStack、H3Cloud OS等云平台上配置安全服务,VCF控制器配合实现安全服务功能,安全服务功能在云平台上配置。
这种场景下南北向服务链由VSR集成vFW功能,vLB可以独立部署;东西向跨网段服务链的vFW业务集成在VSR上,vLB可以独立部署。
图5 Openstack服务链模型
该模式组网下,S12500-X或S9800设备充当VXLAN IP GW,提供Overlay网关功能;H3C S1020V、S6800充当L2 VTEP,将虚拟机或物理服务器接入到VXLAN网络中,其中H3C S1020V支持运行在ESXi、KVM、H3C CAS等多种虚拟化平台上。
该组网模式下的Service安全节点包括VSR、vFW、vLB、M9000/F5000、L5000等设备。同虚拟路由器VSR做网关的服务链应用类似,也分为灵活服务链模型和OpenStack模型。
如图6所示,在VCF控制器上配置实现东西向服务链提供安全服务。其中,服务节点支持硬件形态或NFV形态。
该模型中,南北向服务链无需专门编排,可以通过S12500-X串联M9000实现NAT、防火墙等服务,S12500-X旁挂L5000提供负载均衡服务;由VCF控制器通过PBR、静态路由等技术实现引流。
在OpenStack、H3Cloud OS等云平台上配置安全服务,VCF控制器配合实现安全服务功能,安全服务功能在云平台上配置。
如图7所示,南北向服务链的流量在S12500-X、S9800上做VXLAN终结,在OpenStack、H3Cloud OS进行相关安全资源配置后,由VCF控制器向M9000、L5000等安全设备自动下发PBR、静态路由等配置,实现对安全流量的引导。对于跨网段的东西向流量,也可以共享南北向的M9000、L5000等安全设备,由VCF控制器自动下发PBR、静态路由等配置,将流量引流到M9000、L5000。
传统的安全设备不支持VXLAN和服务链功能。H3C通过服务链代理设备,可以将传统的甚至是第三方的安全设备引入H3C SDN服务链,从而共享SDN服务链先进技术,为客户提供更加多样化的选择。
如图8所示,该模式组网下,传统安全设备通过S6800的AC口(可以是S6800的堆叠、聚合后的逻辑接口)222接入SDN VXLAN网络;S6800作为服务链的服务代理节点,进行SDN服务链的报文特征识别和解析。S6800与安全设备二层连接,其同一个接口可以接入多台虚拟化安全设备,并以VLAN进行区分。
第三方安全设备服务链代理的应用,可以支持第三方安全设备通过S6800的单臂模式和双臂模式两种接入模式,实现了网络中东西向流量的安全自动防护,也为客户的安全设备选型提供了更加多样的选择。在这种模式下,VCF控制器不再识别具体的安全业务类别,只需识别业务所在S6800的接口,并负责导流到该接口。
通过OpenStack Neutron中的FWaaS和LBaaS两大安全服务功能的定义,经由H3C VCF控制器的自动映射,可以实现对网络中FW/LB安全服务的服务链编排。
在这种编排模式下,使用FWaaS或LBaaS即可以定义网络的安全服务链。OpenStack标准模型所编排的功能是:
· 南北向流量缺省经过防火墙、负载均衡。
· 跨网段的东西向流量,可以共享南北向的防火墙、负载均衡。
VCF控制器将OpenStack编排的这些抽象描述和定义自动转换配置映射到网络设备中,从而实现OpenSatack的服务链模型。如图9所示。
图9 Openstack自动编排模型
如图10所示,VCF控制器接管整个SDN Overlay网络,拥有包括网关、软硬件VTEP以及NFV资源池等设备的全部信息:
图10 SDN控制器自动编排模型
通过VCF控制器的Service Chain App,可以进行更加灵活、精细化的服务链编排:
(1) 申请安全服务功能节点,定义各节点上的安全服务配置,例如防火墙的策略、规则,负载均衡的成员、VIP等。
(2) 定义流量特征组,即定义需要经过安全服务节点的流量的源和目的IP地址,可以是已有的虚拟链路层网络、虚拟子网或虚拟端口。
(3) 创建服务链,指定该服务链所属的租户、源和目的特征组等参数,并选择需引用的安全服务功能节点。
通过上面的几步简单操作,VCF控制器即可将定义的流量特征以流表和配置的方式分别下发到流分类节点及安全服务节点,从而引导租户流量的自动、按定义转发。效果如图11所示。
图11 SDN控制器自动编排效果图
基于SDN Overlay网络的服务链,具有如下特征:
· 基于Overlay网络技术,能够做到控制平面和网络转发平面的分离,物理网络与逻辑网络分离。
· 基于SDN的配置,可以动态的添加或者删除服务链上的服务节点,解耦了网络设备之间的关联,打破了物理拓扑的限制。
· 基于租户的部署模型,可以为每个租户提供个性化的安全选择。
· 实现租户业务的灵活编排和修改,而不影响物理拓扑和其它租户。
· 数据包只需在初次接入的流分类节点分类一次,整个业务转发和安全检测的过程更便捷、更高效。
· 可以支持多种类型的服务节点。
· 服务节点统一资源池化,可以实现安全能力的无缝扩张和多业务共享。
GBP(Group-Based Policy,基于组的安全策略)是Cisco主导的一个OpenStack的API框架,它提供了一个意向性的驱动模型,目的是以独立于底层基础架构的方式描述应用需求,它引入了组的概念和策略模型来提供组间的连通性控制、安全性和网络服务,可以定义包含4-7层网络服务的服务链。GBP作为OpenStack Neutron组件的一种服务,目前已经在OpenStack的Kilo版本发布(需单独安装)。
图12 GBP的模型
其中各组成部件的含义如下:
· Policy Target:网络端点。是策略组的基本单元。
· Group:具有相同属性的端点形成组。是GBP的基本原语。
· Policy Rule:策略规则。由Classifier和Action组成。
· Classifier:过滤网络流量的方式,即:对流进行分类。
· Action:当某规则被匹配时要执行的操作。Action可包含allow、deny、copy和service-chain等动作,如果选择service-chain,可按顺序插入(编排)服务节点。其最基本的action是“重定向到服务链”。
· Policy RuleSet:策略规则组成的规则集。
GBP可以把部分策略直接映射成Neutron的API,从而能够使用部分现有的Neutron插件,映射关系如下:
表1 GBP策略与Neutron API的映射关系
GBP Resource | Neutron |
Policy Target | Port |
Target Group | Subnet |
L2 Policy | Network |
L3 Policy | Router |
可见,GBP目前尚未能够与Neutron自带的FWaaS、LBaaS服务实现联动和配合,如果使用GBP,则必须使用其自带的API接口编排安全服务节点,这也是其待改进的方向之一。
H3C SDN服务链框架采用服务插入(Service Insertion)方式实现,具有良好的适配性。对于GPB模型来说,更是有良好的对应关系:
表2 GBP与H3C SDN服务链对应关系
GBP | H3C SDN服务链 |
Target构成Group | 流量特征组 |
Classifier | 服务链定义 |
Action | 进入服务链(安全服务节点) |
由此可见,H3C SDN服务链完全可以与GBP进行适配,H3C SDN服务链方式可以看作是GBP的一种最简实现。