6.8. 网络

OpenStack 网络是一种独立服务，可在多个节点上部署多个进程。这些流程相互交互和其他 OpenStack 服务。OpenStack 网络服务的主要流程是 neutron-server，它是公开 OpenStack 网络 API 的 Python 守护进程，并将项目请求传递给一组插件以进行额外的处理。

OpenStack 网络组件有：

下图显示了 OpenStack 网络组件的架构和网络流图：

View larger image

请注意，当使用分布式虚拟路由(DVR)和第 3 层高可用性(L3HA)时，此方法会有很大变化。这些模式改变了 neutron 的安全环境，因为 L3HA 在路由器之间实现 VRRP。部署需要正确调整大小和强化，以帮助缓解对路由器的 DoS 攻击，以及路由器之间的本地网络流量必须被视为敏感，以帮助解决 VRRP 欺骗的问题。DVR 将网络组件（如路由）移到 Compute 节点，同时仍需要网络节点。因此，计算节点需要访问和从公共网络访问，从而增加其暴露，并要求客户需要额外的安全考虑，因为它们需要确保防火墙规则和安全模型支持此方法。

本节介绍包含控制器节点、网络节点和一组用于运行实例的计算节点的标准架构。要为物理服务器建立网络连接，典型的 neutron 部署具有四个不同的物理数据中心网络：

View larger image

建议您将此流量划分为单独的区。如需更多信息，请参阅下一章节。

建议您使用安全区的概念来保持关键系统相互独立。在实际意义上，这意味着使用 VLAN 和防火墙规则隔离网络流量。该短语以细致的细节完成，结果应该是只有需要连接到 neutron 的服务才能这样做。

在下图中，您可以看到已创建区来分离某些组件：

View larger image

.

在设计您的 OpenStack 网络基础架构的初始架构阶段，务必要确保提供适当的专业知识，以帮助设计第一台物理网络基础架构，以确定正确的安全控制和审计机制。

OpenStack 网络添加了一个虚拟化网络服务层，让项目能够构建自己的虚拟网络。目前，这些虚拟化服务不像其传统网络的对应部分一样成熟。在采用这些虚拟化服务之前，请考虑这些虚拟化服务的当前状态，因为它指明了您在虚拟化和传统网络边界上实施的控制。

OpenStack 网络可以使用两种不同的机制来针对各个项目/网络组合使用两种不同的机制：VLAN (IEEE 802.1Q 标记)或使用 VXLAN 或 GRE 封装的 L2 隧道进行。OpenStack 部署的范围和规模决定了您应该用于流量隔离或隔离的方法。

VLAN 在一个特定物理网络中以数据包的形式实现，它包括 IEEE 802.1Q 头，其中带有一个特定的 VLAN ID (VID) 字段值。共享同一物理 netw ork 的 VLAN 网络在网络的 L2 层相互隔离，它们甚至可以有重叠的 IP 地址空间。支持 VLAN 网络的每个不同物理网络都被视为单独的 VLAN trun k，不同的空间为 VID 值。有效的 VID 值为 1 到 4094。

VLAN 配置复杂性取决于您的 OpenStack 设计要求。要允许 OpenStack 网络更有效地使用 VLAN，您必须分配 VLAN 范围（每个项目一个），并将每个 Compute 节点物理交换机端口切换到 VLAN 中继端口。

网络隧道将各个项目/网络组合与唯一的"隧道"组合封装，用于识别属于该组合的网络流量。项目的 L2 网络连接独立于物理本地或底层网络设计。通过在 IP 数据包内封装流量，该流量可以跨第 3 层边界，无需预先配置的 VLAN 和 VLAN 中继。隧道为网络流量添加了一个模糊的层，减少了个别项目流量的可见性会给监控点造成一个监控点。

OpenStack 网络目前支持 GRE 和 VXLAN 封装。提供 L2 隔离的选择取决于部署中将创建的项目网络的范围和大小。

计算(Compute)支持使用 OpenStack 网络服务进行项目网络流量访问控制。通过安全组，管理员可以和项目指定流量类型，以及允许通过虚拟接口端口的方向(ingress/egress)。安全组规则是有状态 L2-L4 流量过滤器。

OpenStack 网络路由器可以连接多个 L2 网络，还可提供网关，将一个或多个专用 L2 网络连接到共享外部网络，如用于访问互联网的公共网络。

L3 路由器在将路由器链接到外部网络的网关端口上提供基本的网络地址转换(SNAT 和 DNAT)功能。默认情况下，此路由器 SNAT （源 NAT）所有出口流量，并支持浮动 IP，它会创建一个静态一对一的双向映射，从外部网络上的公共 IP 到附加到路由器的其他子网的私有 IP。浮动 IP （通过 DNAT）为实例提供外部入站连接，可以从一个实例移到另一个实例。

考虑使用每个项目 L3 路由和浮动 IP 来更精细的项目实例连接。应将特殊考虑给连接到公共网络或使用浮动 IP 的实例。建议仔细考虑安全组，以仅过滤对需要外部公开的服务的访问。

默认情况下，服务质量(QoS)策略和规则由云管理员管理，这会导致项目无法创建特定的 QoS 规则，或将预期策略附加到端口。在某些用例中，如某些电信应用程序，管理员可能会信任项目，从而使他们能够创建和附加自己的策略到端口。这可以通过修改 policy.json 文件来实现。

从 Red Hat OpenStack Platform 12，neutron 支持入口和出口流量的带宽限制 QoS 规则。这个 QoS 规则名为 QosBandwidthLimitRule，它接受每秒 kilobits 测量的两个非负整数：

在 neutron Open vSwitch、Linux 网桥和 SR-IOV 驱动程序中实施了 QoSBandwidthLimitRule。但是，对于 SR-IOV 驱动程序，不使用 max-burst-kbps 值，如果设置，则会被忽略。

对于所有离开一个虚拟机的网络流量，QoS 规则 QosDscpMarkingRule 在服务的类型头（IPv4 (RFC 2474)）或网络类头（IPv6）中设置 DSCP（Differentiated Service Code Point ）值，相关的规则会在其中应用。这是一个 6 位标头，有 21 个有效值，表示数据包的丢弃优先级，因为它跨网络应满足拥塞。防火墙也可以使用它来匹配其访问控制列表的有效或无效流量。

OpenStack 负载均衡服务(octavia)为 Red Hat OpenStack Platform director 安装提供负载平衡即服务(NFV)实施。为了实现负载平衡，octavia 支持启用多个供应商驱动程序。参考供应商驱动程序(Amphora provider driver)是一个开源、可扩展和高度可用的负载供应商。它通过管理一组虚拟机（统称为 amphorae-​），实现负载平衡服务的交付。

有关负载均衡服务的更多信息，请参阅使用 Octavia 进行负载平衡即服务 指南。

本节讨论 OpenStack 网络配置良好实践，因为它们适用于您的 OpenStack 部署中的项目网络安全性。

要限制 OpenStack Networking API 服务将网络套接字绑定到传入客户端连接的接口或 IP 地址，请在 /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf 文件中指定 bind_host 和 bind_por t ：

Address to bind the API server
Port the bind the API server to

# Address to bind the API server
bind_host = IP ADDRESS OF SERVER

# Port the bind the API server to
bind_port = 9696

OpenStack 网络服务的不同组件使用消息传递队列或数据库连接与 OpenStack 网络中其他组件通信。

OpenStack 网络为用户提供网络资源的自助服务配置。云架构师和操作员在让用户能够创建、更新和销毁可用网络资源方面评估其设计用例非常重要。

OpenStack 网络内的策略引擎及其配置文件(policy.json)提供了在项目网络方法和对象上向用户提供精细的授权的方法。OpenStack N etworking 策略定义会影响网络可用性、网络安全和整个 OpenStack 安全性。云架构师和操作员应仔细评估他们对用户和项目访问权限管理网络资源的政策。

如果您的 OpenStack 部署提供了多个外部访问点到不同的安全区，您务必要限制将多个 vNIC 附加到多个外部访问 po ints的项，这可能会导致这些安全区桥接，并可能导致无法预见的安全隐患。您可以使用计算提供的主机聚合功能，或将第 1 个项目实例拆分为具有不同虚拟网络配置的多个项目中，以帮助缓解这一风险。如需有关主机聚合的更多信息，请参阅 link:https://access.redhat.com/documentation/zh-cn/red_hat_openstack_platform/13/html/configuring_the_compute_service_for_instance_creation/crea ting-and-managing-host-aggregates[Creating and managing host aggregates]。

安全组是安全组规则的集合。通过安全组及其规则，管理员可以和项目指定流量类型和方向(ingress/egress)，允许通过虚拟接口端口。在 OpenStack 网络中创建虚拟接口端口时，它将与安全组关联。可以在默认安全组中添加规则，以便根据每个部署更改行为。

在使用 Compute API 修改安全组时，更新的安全组将应用到实例上的所有虚拟接口端口。这是因为计算安全组 API 是基于实例的，而不是基于端口的，如 neutron 中找到。

配额提供限制可用于项目的网络资源数量的功能。您可以为所有项目强制执行默认配额。要查看配额选项，请参阅 /var/lib/config-data/puppet-generated /neutron/etc/neutron/neutron.conf。

OpenStack 网络还通过配额扩展 API 支持按项目配额限制。要启用每个项目配额，您必须在 /var/lib/config-data/puppet-generated/neutron/e tc/neutron/neutron.conf 中设置 quota_driver 选项。例如：

quota_driver = neutron.db.quota_db.DbQuotaDriver

quota_driver = neutron.db.quota_db.DbQuotaDriver

OpenStack 网络具有内置功能，可帮助缓解对实例的 ARP 欺骗。除非为生成的风险赋予了谨慎考虑，否则不应禁用此设置。

配置文件包含组件可以平稳运行所需的关键参数和信息。如果非特权用户意外或意外修改或删除任何半虚拟化计量或文件本身，则会导致严重可用性问题导致向其他最终用户拒绝服务。因此，此类关键配置文件的用户所有权必须设置为 root，并且组所有权必须设置为 neutron。

主机上不存在 neutron 组。使用 ls -l 将显示组所有者的 GID。

sudo ls -l /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf
-rw-r-----. 1 root 42435 41748 Dec 11 09:34 /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf

sudo stat -L -c "%U %G" /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf
root UNKNOWN

sudo ls -l /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf
-rw-r-----. 1 root 42435 41748 Dec 11 09:34 /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf

sudo stat -L -c "%U %G" /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf
root UNKNOWN

确保 neuton.conf 配置文件的用户和组所有权分别设置为 root 和 neutron ：

sudo docker exec -it neutron_api stat -L -c "%U %G" /etc/neutron/neutron.conf
root neutron

sudo docker exec -it neutron_api stat -L -c "%U %G" /etc/neutron/neutron.conf
root neutron

检查 neutron.conf 配置文件的权限是否已设置为 640 或 stricter：

stat -L -c "%a" /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf

$ stat -L -c "%a" /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf

在 /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf 中，检查 [DEFAULT] 部分下的 auth_strategy 的值是否被设置为 keystone，而不是 noauth 2 或 noauth2。

在 /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf 中检查 [keystone_authtoken] 部分下的 auth_uri 的值是否设置为以 'https 开头的身份 API 端点：

在 /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf 中，确保 [DEFAULT] 部分下的参数 use_ssl 设置为 True。