ネットワークサービス¶
あなたの OpenStack ネットワークインフラデザインの概要設計段階では、適切なセキュリティ管理・監査機構を確認する為、物理ネットワークインフラ設計で支援する適切な専門技術が間違いなく利用できる事は重要です。
OpenStack Networking adds a layer of virtualized network services which gives tenants the capability to architect their own virtual networks. Currently, these virtualized services are not as mature as their traditional networking counterparts. Consider the current state of these virtualized services before adopting them as it dictates what controls you may have to implement at the virtualized and traditional network boundaries.
VLAN とトンネリングを使用した L2 分断¶
OpenStack Networking can employ two different mechanisms for traffic segregation on a per tenant/network combination: VLANs (IEEE 802.1Q tagging) or L2 tunnels using GRE encapsulation. The scope and scale of your OpenStack deployment determines which method you should utilize for traffic segregation or isolation.
VLAN¶
VLAN は特別な VLAN ID (VID) フィールド値を持つ IEEE 802.1Q ヘッダを含む特別な物理ネットワーク上のパケットを実現します。同じ物理ネットワークを共有する VLAN ネットワーク群は、L2 において相互から独立しており、重複する IP アドレス空間を持つ事すら可能です。VLAN ネットワークに対応した各個別の物理ネットワークは、独自の VID 値を持つ独立した VLAN トランクとして扱われます。有効な VID 値は1～4094です。
VLAN 設定の複雑さはあなたの OpenStack 設計要件に依存します。OpenStack Networking がVLAN を効率良く使用できるようにする為に、VLAN 範囲を (各テナントに１つ) 割り当てて、各 compute ノードの物理スイッチポートを VLAN トランクポートに変更する必要があります。
注釈
あなたのネットワークを4095 以上のテナントに対応するようにしたい場合、VLAN はあなたにとって多分正しい選択肢ではありません。なぜなら、4095 以上に VLAN タグを拡張する為の複数の「改造」が必要だからです。
L2 トンネリング¶
ネットワークトンネリングは、固有の「トンネルID」を用いてテナント／ネットワークの各組合せをカプセル化します。これは、上記の組合せに属するネットワーク通信を独立させる為に使用されます。テナントの L2 ネットワーク接続は、物理的配置や下層のネットワーク設計から独立しています。IP パケット内で通信をカプセル化する事により、通信はレイヤ３境界を越える事ができ、VLAN や VLAN とランキングの事前設定の必要が無くなります。トンネリングはネットワークのデータ通信に不明瞭なレイヤを追加し、監視の観点で個々のテナント通信の可視性を低下させます。
OpenStack Networking は現在 GRE と VXLAN のカプセル化をサポートします。
L2 分断を提供する技術の選択は、あなたのデプロイで作成される予定のテナントネットワークの範囲とサイズに依存します。あなたの環境が VLAN ID の利用で制限がある場合や、大多数の L2 ネットワークが見込まれる場合、トンネリングの使用を推奨します。
ネットワークサービス¶
テナントネットワーク分断の選択はネットワークセキュリティと制御境界をどのように実装するかに影響します。以下の追加ネットワークサービスは利用可能か、OpenStack ネットワークアーキテクチャのセキュリティポーズを拡張する為の開発中かのいずれかです。
アクセス制御リスト¶
OpenStack Compute は、旧式の nova-network サービスでデプロイする場合、テナントネットワーク通信のアクセス制御を直接サポートします。又は、OpenStack Networking サービスにアクセス制御を任せる事も出来ます。
注：旧式の nova-network セキュリティグループは、iptables を使用してインスタンス上の全ての仮想インターフェースポートに適用されます。
セキュリティグループでは、管理者とテナントが仮想インターフェースポート通過を許可する通信のタイプと方向（内向き／外向き）を指定できるようになっています。
When using the Networking service, we recommend that you enable security groups in this service and disable it in the Compute service.
L3 ルーティングおよび NAT¶
OpenStack Networking routers can connect multiple L2 networks, and can also provide a gateway that connects one or more private L2 networks to a shared external network, such as a public network for access to the Internet.
L3 ルータは、外部ネットワークへのルータに接続する ゲートウェイ ポート上の基本的なネットワークアドレス変換 (NAT) 機能を提供します。このルータはデフォルトで全てのネットワークの SNAT (静的 NAT) を行います。これは、外部ネットワーク上のパブリック IP アドレスから、ルータにアタッチされた他の１サブネットのプライベート IP アドレスへ変換する静的な１対１マッピングを作成します。
テナント VM のより粒度の細かいテナント L3 ルーティングとフローティング IP 単位で設定する事をお勧めします。
サービス品質(QoS)¶
By default, Quality of Service (QoS) policies and rules are managed
by the cloud administrator, which results in tenants being unable to
create specific QoS rules, or to attach specific ports to policies. In
some use cases, such as some telecommunications applications, the
administrator may trust the tenants and therefore let them create and
attach their own policies to ports. This can be achieved by modifying
the policy.json file and specific documentation.
will be released with the extension.
The Networking service (neutron) supports bandwidth-limiting QoS rules in
Liberty and later. This QoS rule is named QosBandwidthLimitRule and it
accepts two non-negative integers measured in kilobits per second:
max-kbps: bandwidthmax-burst-kbps: burst buffer
The QoSBandwidthLimitRule has been implemented in the neutron Open
vSwitch, Linux bridge and single root input/output virtualization (SR-IOV)
drivers.
In Newton, the QoS rule QosDscpMarkingRule was added. This rule marks
the Differentiated Service Code Point (DSCP) value in the type of service
header on IPv4 (RFC 2474) and traffic class header on IPv6 on all traffic
leaving a virtual machine, where the rule is applied. This is a 6-bit header
with 21 valid values that denote the drop priority of a packet as it crosses
networks should it meet congestion. It can also be used by firewalls to
match valid or invalid traffic against its access control list.
Port mirroring service involves sending a copy of packets entering or leaving one port to another port, which is usually different from the original destinations of the packets being mirrored. Tap-as-a-Service (TaaS) is an extension to the OpenStack networking service (neutron). It provides remote port mirroring capability for tenant virtual networks. This service has been primarily designed to help tenants (or the cloud administrator) debug complex virtual networks and gain visibility into their VMs, by monitoring the network traffic associated with them. TaaS honors tenant boundaries and its mirror sessions are capable of spanning across multiple compute and network nodes. It serves as an essential infrastructure component that can be utilized for supplying data to a variety of network analytics and security applications.
負荷分散¶
Another feature in OpenStack Networking is Load-Balancer-as-a-service (LBaaS). The LBaaS reference implementation is based on HA-Proxy. There are third-party plug-ins in development for extensions in OpenStack Networking to provide extensive L4-L7 functionality for virtual interface ports.
ファイアウォール¶
FW-as-a-Service (FWaaS) is considered an experimental feature for the Kilo release of OpenStack Networking. FWaaS addresses the need to manage and leverage the rich set of security features provided by typical firewall products which are typically far more comprehensive than what is currently provided by security groups. Both Freescale and Intel developed third-party plug-ins as extensions in OpenStack Networking to support this component in the Kilo release. For more details on the administration of FWaaS, see Firewall-as-a-Service (FWaaS) overview in the OpenStack Administrator Guide.
During the design of an OpenStack Networking infrastructure it is important that you understand the current features and limitations of available network services. Understanding the boundaries of your virtual and physical networks will assist in adding required security controls in your environment.
ネットワークサービス拡張¶
A list of known plug-ins provided by the open source community or by SDN companies that work with OpenStack Networking is available at OpenStack neutron plug-ins and drivers wiki page.
Networking サービスの制限事項¶
OpenStack Networking は以下の制限があります。
- IP アドレスの重複
If nodes that run either neutron-l3-agent or neutron-dhcp-agent use overlapping IP addresses, those nodes must use Linux network namespaces. By default, the DHCP and L3 agents use Linux network namespaces and run in their own respective namespaces. However, if the host does not support multiple namespaces, the DHCP and L3 agents should be run on separate hosts. This is due to the fact that there is no isloation between the IP addresses created by the L3 agent and the DHCP agent.
ネットワークネームスペースサポートがない場合、L3エージェントでは追加の制限事項として単一の論理ルータのみサポートされます。
- マルチホスト DHCP エージェント
OpenStack Networking supports multiple L3 and DHCP agents with load balancing. However, tight coupling of the location of the virtual machine is not supported. In other words, the default Virtual Machine scheduler will not take the location of the agents into account when creating virtual machines.
- L3 エージェントの IPv6 未対応
neutron-l3-agent （L3 転送の実装用に多くのプラグインが使用）は IPv4 転送のみサポートしています。
