目录
一、Neutron基本架构
- OpenStack中Neutron采用分布式架构,由多个组件(服务)共同对外提供服务,Neutron架构灵活,层次多。一方面是为了支持各个现有或者将来会出现得先进的网络技术,另外一方面支持分布式部署,获得足够的扩展性
- Neutron仅由一个主要的服务进程Neutron-server,它运行于控制节点
- Neutron-server对外提供Openstack网络API作为Neutron的入口,收集请求后调用plugin(插件)进行处理,最终由计算节点和网络节点上的各种agent(代理)完成请求
- network-provider(网络提供者)是指提供OpenStack网络服务的虚拟机或者物理网络设备,比如Linux Brigde、Open vSwitch或者其他支持neutron的物理交换机。与其他的五福一样,Neutron的各个组件服务之间需要相互协调通信,Neutron-server、插件之间通过消息队列(默认用RabbitMQ实现)进行通信和相互协调
- Neutron-database(数据库,默认使用MariaDB)用于存放OpenStack的网络状态信息,包括网络、子网、端口、路由器等
- Client(客户端)是指使用Neutron服务的应用程序,可以是命令行工具(脚本)、Horizon和Nova计算服务等
创建一个Vlan10的虚拟网络过程
1.Neutron-server收到创建网络(Network)的请求,通过消息队列通知已注册的Linux brige插件,假设网络提供者为Linux Bridge
2.该插件将要创建的网络信息保存到数据库中,并且通过消息队列通知各个运行的节点代理
3.代理收到信息后会在节点上的物理网卡创建vlan设备,并且创建一个网桥来桥接网络设备
二、Neutron-server解析
- neutron-server其作用是提供一组API来定义网络连接和IP地址,供Nova等客户端调用,其本身也是分层模型
- Resetful API:是直接对接客户端API服务,属于最前端的API,包括核心接口和扩展接口两种类型。
- Core API提供管理网络、子网、端口等核心资源
- Extension API提供给网络管理路由器、负载均衡、防火墙、安全组等扩展资源
- common service:通用服务,负责对API请求进行校验、认证、并且提供授权
- Neutron cron:核心处理程序,是调用相应的插件API来处理API的请求
- Plugin API:定义插件的抽象功能集合,提供调用通用插件的API接口,包括核心插件接口、扩展插件接口。Neutron cron通过cron plugin API调用相应的Core plugin,通过扩展插件接口调用相应的service plugin
三、插件、代理与网络提供者
- 插件是Neutron的一种API的后端实现,目的是增强扩展性。插件按照功能可分为CorePlugin和Service Plugin两种类型。Core Plugin提供基础二层虚拟机网络支持,实现网络、子网和端口核心资源的支持。Service plugin是指Core Plugin之外的其他插件,提供路由器、防火墙、安全组、负载均衡等服务支持,值得一提的是, 直到OpenStack的Havana版本,Neutron才开始提供一个名为L3 RouterService Plugin的插件支持路由服务。
- 插件由Neutron-server 的Core Plugin API和Extension Plugin API调用,用于确定具体的网络功能,要配什么样的网络,插件处理Neutron-Server发来的请求,主要职责是在数据库中维护Neutron网络的状态信息(更新Neutron数据库),通知相应的代理实现具体的网络功能。每一个插件支持一组API资源并完成特定操作,这些操作最终由插件通过RPC调用相应的代理(Agent)来完成。
- 代理处理插件转来的请求,负责在网络提供者上真正实现各种网络功能。代理使用物理网络设备或者虚拟化技术完成实际的操作任务,如用于路由具体操作L3 Agent。
- 插件和代理与网络提供者配套使用,比如网络提供者是Linux Bridge,就需要使用LinuxBridge的插件和代理,如换成OpenySwitch,泽需要改成相应的插件和代理。
四、Neutron的物理部署
- Neutron与其他OpenStack服务组件系统工作,可以部署在多个物理主机节点上,主要涉及控制节点、网络节点计算节点,每个节点可以部署多个,典型的主机节点部署介绍如下
- 控制节点和计算节点上的部署
控制节点上部署Neutron-service (API)、Core Plugin和Service Plugin的代理,这些代理包括neutron-plugin -agent、neutron-me dadata-agent neutron-dhcp-a gnet、neutron-l3-agent、neutron-lbaas-agent等。Core plugin和service plugin已经集成到neutron-server中,不需要运行独立的plugin服务。
计算节点上可以部署Core Plugin、Linux Bridge或Open ySwitch的代理,负责体提供二层的网络功能。
控制节点和计算节点都需要部署CorePlugin的代理,因为控制节点与计算节点通过该代理才能建立二层连接。
- 控制节点和网络节点上的部署
可以通过增加网络节点承担更大的负载,该方案特别适合规模较大的OpenStack环境控制节点部署Neutron-server服务,只负责通过Neutron-server响应的API请求。(水平扩展)
网络节点部署的服务包括Core Plugin的代理和se rvice Plugin的代理。将所有的代理从上述控制节点分离出来,部署到独立的网络节点上,由独立的网络节点实现数据的交换,路由以及负责均衡等高级网络服务。
五.ML2插件详解
ML2插件的架构实现
ML2插件的发展
- Neutron可以通过开发不同的插件和代理来支持不同的网络技术、这是一种相当于开发的架构。不过随着所支持的网络提供者种类的增加,开发人员发现两个突出的问题。
- 一个问题是多种网络提供者无法共存。Core Plugin负责管理和维护Neutron二层的虚拟网络的状态信息,一个Neutron网络只能由一个插件管理 ,而Core Plugin插件与相应的代理是一一对应的,如果Linux Bridge插件,则只能选择Linux Bridge代理,必须在OpenStack的所有节点上使用Linux Bridge作为虚拟交换机。
- 另外一个问题是开发插件的工作量太大,所有传统的CorePlugin之间存在大量重复的代码(如数据库访问代码)
- 为了解决这二个问题,从OpenStack的Havana 版本开始,Neutron 实现一一个插件ML2(Moduler. Layer2)为了职代所有Core Plugin,允许在OpenStacks网络中同时使用多种二二层的网络技术,不同的节点可以使用不同的网络实现机制,ML2能够与现在所有的代理无缝集成,以前使用费的代理无需变更,只要将传统的Core Plugin替换ML2。
ML2插件架构详解
- ML2对二层的网络进行抽象,解锁了Neutron所支持的网络类型(Type)与访问这些网络类型的虚拟网络实现机制(Mechansim),并通过驱动的形式进行扩展,不同的网络类型对应不同的类型的驱动(Type Driver),由类型管理器(Type Manager)进行管理,不同的网络实现机制对应不同的机制驱动(Mechasiom Driver),由机制管理器(Mechasim Manager)进行管理。这种ML2实现框架具有弹性,易于扩展,能够能活支持多种网络类型和实现机制
类型驱动(Type Driver)
- Neutron支持的每一种网络类型都有一个对应的ML2类型驱动,类型驱动负责维护网络类型的状态,执行验证、创建网络等工作。目前Neutron已经实现的网络类型包括Flat、Local、Vlan、Vxlan、Gre
机制驱动(Mechansim Driver)
- Neutron支持的每一种网络机制都有一个对应的ML2机制驱动
- 机制驱动负责获取类型驱动维护的网络状态,确保在相应的网络设备(物理或者虚拟的)上正确实现这些状态
类型驱动vlan,机制驱动为Linux Bridge,如果创建vlan10,那么vlan的类型驱动会确保将vlan10的信息保存到Neutron数据库中,包括网络的名称、vlan ID等,而Linux bridge机制驱动会确保各个节点上Linux Bridge代理在物理网卡上创建ID为10的vlan设备和bridge设备,并且将二者进行桥接
Neutron的网络机制有3种类型
基于代理(Agent-based):包括Linux bridge、Openvswitch
基于控制器(controller-based):包括OpenStacDaylight、VMware NSX等
基于物理交换:Cisco Nexus、Arista、Mellanox等
扩展资源
- ML2作为一个Core Plugin,在实现网络、子网和端口核心资源的同事,也实现了包括端口绑定(port Bindings)、安全组(Security Group)等部分扩展资源
六.Linux Bridge代理
- Linux Bridge是成熟可靠的Neutron二层网络虚拟化技术,支持Local、Flat、vlan、Vxlan这四种网络类型,目前不支持Gre
- Linux Bridge可以将一台主机上的多个网卡桥接起来,充当一台交换机,它可以桥接物理网卡,又可以是虚拟网卡,用于桥接虚拟网卡(虚拟机网卡)的是Tap接口,这是一个虚拟机出来的网络设备,称为Tap设备,作为网桥的一个端口,tap接口在逻辑上与物理接口具有相同的功能,可以接收和发送数据包
- 若选择Linux Bridge代理,在计算节点上数据包从虚拟机发送到物理网卡需要经过以下设备
Tap接口(Tap interface):用于网桥虚拟机的网卡,命令为tap XXX
Linux网桥(Linux bridge):作为二层交换机,命令为brq XXXX
VLAN 接口(Vlan interface):在vlan网络中用于连接网桥,命名为ethx.y(ethx为物理网卡名称,y为vlan ID)
VXLAN接口(VXLAN interface):在vxlan网络中用于连接网桥,命名为vxlan-z(z是vlan ID)
物理网络接口:用于连接到物理网络
- 基于Linux Bridge的flat网络(此种方法对于网桥的负载较大)
- 基于Linux Bridge的vlan网络,vlan网络有2个vlan有自己的网桥,实现了基于vlan的代理,如果改用vxlan,其中的vlan接口换成vxlan接口,其命令为vxlan-101、vxlan-102
七.OpenVSwitch代理
- 与Linux Bridge相比,OpenVSwitch(简称OVS)具有几种管控功能,而且性能更加优化,支持更多的功能,目前在Openstack领域为主流。OVS代理支持Local、flat、vlan、vxlan、GRE和GENEVE等网络类型
OVS的设备类型
- Tap设备:用于网桥连接虚拟机网卡
- Linux网桥:桥接网络接口(包括虚拟接口)
- VETH对(VETH Pair):直接相连的一对虚拟机网络接口,发送VETH对一段的数据包由另一端接收。在Openstack中,用来连接两个虚拟网桥
OVS数据包流程(在计算节点上的数据包从虚拟机发送到物理网卡)
- Tap接口:用于网桥虚拟机的网卡,命名为tapxxx
- Linu网桥:与LInux bridge不同,命名为qbrxxx(其中编号xxx与tapxxx中相同)
- VETH对:两端分别命名为qvbxxx和qvoxxx(其中编号xxx与tapxxx中相同)
- OVS集成网桥:命名为br-int
- OVS PATCH端口:两端分别命名为int-br-ethx和phy-br-ethx(x为物理网卡名称的编号)
- OVS物理连接网桥:分为两种类型,在flat和vlan网络中使用OVS提供者网桥(provider bridge),命名为br-ethx(x为物理网卡名称的编号);在vxlan、GRE和GENEVE叠加网络中使用OVS隧道网桥(Tunnel Bridge),命名为Br-tun,另外在local网络中不需要在OVS物理连接网桥
- 物理网路接口:用于连接到物理网络,命名为ethx(x 为物理网卡的名称中的编号)
OVS网络的逻辑结构
- 与Linux Bridge代理不同,open vswitch代理不通过Eth1.101、Eth1.102等VLAN接口隔离不同的vlan.
- 所有的虚拟机都连接到同一个网桥br-int,Open VSwitch通过配置br-int和br-ethx上流规则(flow rule)来进行vlan转换,进而实现vlan之间的隔离
例如:内部标签分别为1和2,而物理网络的vlan标签是101和102,当br-eth1网桥上的phy-br-eth1端口收到一个vlan1标记的数据包时,会将其中的vlan1转让为vlan101;当br-init网桥上的init-br-eth1端口收到一个vlan101标记的数据包时,会将其中的vlan101转让为vlan1
八.DHCP代理
- openstack实例在启动过程中能够从Neutron提供的DHCP服务自动获取IP地址
DHCP主要组件
- DHCP代理(neutron-dhcp-agent):为项目网络提供DHCP功能,提供元数据请求(Metadata request)服务
- DHCP驱动:用于管理DHCP服务器,默认为DNSmasq,这是有一个提供DHCP和DNS服务的开源软件,提供DNS缓存和DHCP服务功能
- DHCP代理调度器(Agent-Scheduler):负责DHCP代理与网络(network)的调度
DHCP代理的主要任务
- Neutron DHCP提供两类REST API接口:Agent Management ExtensionAPI 和Agent Scheduler Extension API这两类API都是Extension API DHCP代理的核心组件
- 定期报告DHCP代理的网络状态,通过RPC报告给Neutron-server,然后通过Core Plugin报告给数据库并进行更新网络状态。
- (2)启动dnsmasg进程,检测dhcp-xxx名称( Namespace)中的ns-xxx端口接收到DHCP DISCOVER请求,在启动dnsmasq进程的过程中,决定是否需要创建名称空间中的ns-xxx 端口,是否需要配置名称空间中的iptables,是否需要刷新dnsmasq进程所需的配置文件
创建网络(Network) 并在子网(subnet)上启用DHCP时,网络节点上的DHCP代理会启动一个dnsmasq进程为网络提供DHCP服务。dnsmasq与网络(network) 是一-对应关系,一个dnsmasg进程可为同- -网络中所有启动DHCP的子网(Subnet) 提供服务
DHCP代理的配置文件
- DHCP代理配置文件是/etc/neutron/dhcp_agent.ini
- interface_ driver:用 来创建TAP设备的接口驱动,如果使用Linux Bridge连接,该值设为neutron.agent.Linux.interface.BridgelnterfaceDriver ;如果选择Open Vswitch,该值为neutron.agnt.linux.interface.OVSInterfaceDriver
- dhcp_ driver: 指定DHCP启动,默认值为neutron.agent.linux.dhcp.Dnsmasq表示dnsmasq进程来实现DHCP服务
DHCP代理的工作机制
- DHCP代理运行在网络节点上,DHCP为项目网络提供DHCP服务IP地址动态分配,另外还会提供数据请求服务,工作机制如下
- 通过DHCP获取IP地址过程如下
(1)创建实例时,Neutron 随机生成MAC并从配置数据中分配一个固定的 IP地址,一起保存到dnsmasg的hosts文件中,让dnsmasq进程做好准备。
(2)与此同时,Nova-compute 会设置Mac地址。
(3)实例启动,发出DHCP DISCOVER广播,该广播消息在整个网络中都可以被收到。
(4)广播消息到达dnsmasq监听Tap接口。dnsmasg收到后检查hosts文件,发现有对应项,它以DHCP OFFER消息将IP和网关IP发回到虚拟机实例。 (5)虚拟机实例发回DHCP REQUEST消息确认接收DHCP OFFER (6)dnsmasq.发回确认消息DHCPACK,整个过程结束。
九.Linux网络名称空间
- 在介绍DHCP服务时提到的linux网络名称空间( Network Namespace简称netns )是linux提供的一种内 核级别的网络环境隔离方法, Namespace也可以翻译称为命名空间或者叫名字空间。当前linux支持6种不同类型的名称空间,网络名称空间是其中一种,在二层网络上,VLAN可以将一- 个物理交换机分割几个独立的虚拟交换机。类似地,在三层网络上,Linux 网络名称空间可以将-个物理三层网络跟个成几个独立的虚拟三层网络。作为一种资源虚拟机隔离机制。
Linux网络名称空间概述
- 在Linux中,网络空间可以被认为是隔离的拥有单独网络栈(网络接口、路由、iptables等)的环境,它经常来隔离网络资源(设备和服务),只有拥有同样网络名称空间的设备才能批次访问。它还能提供了在玩过名称空间内运行进程的功能,后台进程可以运行不同名称空间内的相同端口上,用户还可以虚拟出一块网卡。
- 可以创建一一个完全独立的全新网络环境,包括独立的网络接口、路由表、ARP 表,IP地址表、iptables 或ebtables等,与网络有关的组件都是独立的。
- 通常情况下可以使用ip netns add命令添加新的网络名称空间,使用ip netns list命令查看所有的网络名称空间。
- 执行以下命令进入指定的网络名称空间
ip netns exec netns 名称 命令
- 可以在指定的虚拟环境中运行任何命令,如下
ip netns exec net001 bash
- 为虚拟网路环境netns0的Eth0接口增加P地址,如下
ip netns exec netns0 ip address add 10.0.1.1/24 eth0
- 网络名称空间内部通信没有问题,但是被隔离的网络名称空间之间要进行通信,就必须采用特定方法,即VETH对,VETH对是一种成对出现的网络设备,他们像一根虚拟的网络线,可用于连接两个名称空间,向VETH对一端输 入的数据将自动转发到另外一端。 例如创建两个网络名称空间的netns1和netns2并使他们之间通信,可以执行以下步骤
(1)创建两个网络名称空间
ip netns add netns1
ip netns add netns2
(2)创建一一个VETH对(创建的一-对VETH虚拟接口类似管道(pipe) ,发给veth1的数据包可以在veth2收到,发给veth2的数据包可以在veth1收到,相当于安装两个接[ 1并用网线连接起来)
ip link add veth1 type veth peer name veth2
(3)将上述两个VETH对虚拟接口分别放置到两个网络名称空间中
ip link set veth1 netns netns1
ip link set veth2 netns netns2
Linux网络名称空间实现DHCP服务隔离
- Neutron通过网络名称空间为每个网络提供独立的DHCP和路由服务,从而允许项目创建重叠的网络,如果没有这种隔离机制,网络就不能重叠,这样就失去了很多灵活性
- 每个dnsmasq.进程都位于独立的网络名称空间,命名为qdhcpxx
- 以创建flat网络为例,
Neutron自动新建该网络对应的网桥brqfxxx,以及DHCP的Tap设备tapxxx。物理主机本身也有一个网络名称空间,称为root,拥有一个回环设备(LoopbackDevice)如果DHCP的Tap虚拟接口放置到gdhcp-xxx名称空间,该Tap虚拟接口将无法直接与root名称空间中网桥设备brqxxx连接。为此,Neutron 使用VETH对来解决这个问题,添加VETH对taxxx与ns-xxx i让gdhce xxx连接到brxxx.
Linux网络名称空间实现路由器
- Neutron允许在不同的网络中的子网的CIDR和IP地址重叠,具有相同的IP地址的2个虚拟机也不会产生冲突,这是由于Neutron的路由器通过Linux网络名称空间实现的,每个路由器有自己的独立的路由表
十.Neutron路由器
- Neutron路由器是-一个三层的(L3)的抽象,其模拟物理路由器,为用户提供路由、NAT等服务,在OpenStack网络中,不用子网之间的通信需要路由器,项目网络与外部网络之间的通信更需要路由器。
- Neutron提供虚拟路由器,也支持物理路由器。例如,两个隔离的VLAN网络之间需要实现通信,可以通过物理路由器实现,由物理路由器提供相应的IP路由表,确保两个IP子网之间的通信,将两个VLAN网络中的虚拟机默认网关分别设置为路由路由器的接口A和B的IP地址。VLANA中的虚拟机要与VLANB中的虚拟机通信时,数据包将通过VLAN A中的物理网卡到达路由器,由物理路由器转发到VLAN B中的物理网卡,再到达虚拟机。
- Neutron的虚拟路由器使用软件模拟物理路由器,路由实现机制组网。Neutron的路由服务由L3代理提供
十一.L3代理
L3概述
- 在Neutron中L3代理(neutron-l3agent)具有相当重要的地位。它不仅提供虚拟机路由器,而且通过iptables提供地址转换(SNAT、DNAT)、浮动地址( Floating IP )和安全组(security group)功能,L3代理利用LInux IP栈、路由和iptables.来实现内部网络中不同网络的虚拟机实例之间的通信,以及虚拟机实例和外部网络之间的网络流量路由和转发,L3代理可以部署在控制节点或者网络节点上
路由(routing)
- L3代理提供的虚拟机路由器通过虚拟接口连接到子网,一个子网对应一个接口,该接口的地址是该子网的网关地址,虚拟机的IP地址:栈如果发现数据包的月的IP地址:不在本网段,则会将其发到路由器上对应其子网的虚拟机接口,然后,虚拟机路由器根据配置的路由规则和目的IP地址将包转发到H的端口发出
- L3代理会将每个路由器创建一-个网络名称空间,通过VETH对于TAP相连,然后将网关IP配置在位于名称孔家你的VETH接口上,这样就能够提供路由,网络节点如果不支持linux ;名称空间,则只能运行一个虚拟路由器
通过网络名称空间支持网络重叠
- 在云环境下用户可以按照自己的规划创建网络,不同的项目( 租户)的网络IP地址可能会重叠,为实现此功能,L3 代理使用linux网络名称空间来提供隔离的转发上下文,隔离不同的项目(租户)的网络,每个L3代理运行在-一个名称空间中.每个名称空间由: grouter-<router-UUID>命名
源地址转换(SNAT)
- L3代理通过在iptables表中增加POSTROUTING链来实现源地址转换,既内网计算机访问外网时,发起访问的内网IP地址: (源IP地址)转换为外网网关的IP地址。这种功能让虚拟机实例能够直接访问外网。不过外网计算机还不能直接访问虚拟机实例,因为实例没有外网IP地址,而H的地址转化就能解决这一-问题。
- 项目(和户)网络连接到Neutron路由器,通常将路由器作为默认的网关,当路由器收到实例的数据包并将其转发到外网时。路由器会将数据包的源地址修改成自己的外网地址,确保数据包转发到外网,并能够从外网返回,路由器修改返回的数据包,并转发之间发起访问的实例。
目的地址转换(DNAT)与浮动地址
- Neutron 需要设置浮动IP地址支持从外网访问项目(租户)网络中的实例。每个浮动IP唯一对应一个路由器;浮动IP到关联的端口,在到所在的子网,最后到包含改子网及外部子网路由器。创建浮动IP时。在Neutron分配IP地址后,通过RPC通知该浮动IP地址对应的路由器去设置该浮动IP对应的iptabels规则,从外网访问虚拟机实例时,目的IP地址为实例的浮动IP地址,因此必须由lptables将其转化成固定的IP地址,然后在将其路由到实例。L3 代理通过在iptables表中增加POSTROUTING链来实现地址转换。
- 浮动IP地址是提供静态NAT功能,建立外网IP地址:与实例所在的项目(租户网络) IP .地址的一对+映射,浮动IP地址配置在路由器提供网关的外网接口上,而不是在实例中,路由器会根据通信的方向修改数据包的源或者是目的地址,这是通过在路由器上应用iptables的NAT规则实现的。
- 一旦设置浮动IP地址后,源地址转换就不在使用外网关的IP地址了,而是直接使用对:应的浮动IP地址,虽然相关的NAT规则依然存在,但是neutron-l3-agent-float-snat比neutron-l3-agent-snat更早执行。
安全组(Security Group)
- 安全组定义了那些进入的网络流量能被转发给虚拟机实例。安全组包含一些防火墙策略,称为安全组规则( Security Group nule) ,可以定义若干个安全组。每个安全组可以有若千调规则。可以给每个实例绑定若千个安全组
- 安全组的原理是通过iptables对是咧所在的计算机节点的网络流量进行过滤。安全组规则作用在实例的端口上,具体是在连接实例的计算节点上的linux网桥上实施。
十二.FWaas(虚拟防火墙)
FWaas的概述
- Fwaas(firewall-as-a-service)是- -种基 于NeutronL3 Agent的虚拟防火墙,是Neutron的二个高级服务。通过他,OpenStack 可以将防火墙应用到项目(租户)、路由器、路由器端口和虚拟机端口、在子网边界上对三层和四层的流量进行过滤。
- 传统的网络中的防火墙一般在网关 上,用来控制子网之间的访问。FWaas的原理也是一t样,在Neutron路由上应用防火墙规则,控制进出项目(租户)网络的数据。防火墙必须关联某个策略(Policy) 。策略是规则(rule) 的集合,防火墙会按顺序因公策略中的每一条规则。规则是访问控制的规则,由源于日的子网IP、源于日的端口、协议、允许Allow)和拒绝(Deny)动作组成
- 安全组是最早的网络安全模块,其应用对象是虚拟网卡,在计算机节点上通过iptables.规则控制进出实例虑积网卡的流量。FWaas 的应用对象是虑报路由器,可以在安全组之前控制从外部传入的流量,但是对于同一一个子网内的流量不做限制。安全组保护的是实例,而FWaas.保护的是子网,两者互为补允,通常部客FWaas和安全组来实现双重防护
FW版本(FWaasV1与FWaasV2)
- FWas v1是传统方后墙方案,对路由器提供保护,将防火墙应用到路由器时,改路由器的所有内部端口受到保护,其中虚拟机2进出的数据流都会得到防火墙保护。
- 新的版本的FWaasV2提供了更具细粒度的安全服务,防火墙的概念防火墙组(firewallgroup)代替,一- 一个防火城包括两项策略:入口策略(ingress polie)和出口(egress poliy)。防火墙组不在用于路由器级(路由器全部端口)而足路由器端口,注意,FWaas v2的配置仅提供命令行工具,不支持dashboard图形页面。