Netzwerkdienste¶
In den anfänglichen architektonischen Phasen der Gestaltung Ihrer OpenStack Netzwerkinfrastruktur ist es wichtig, dass ein angemessenes Fachwissen zur Verfügung steht, um bei der Gestaltung der physischen Netzwerkinfrastruktur zu helfen, um die ordnungsgemäße Sicherheitskontrolle und die Prüfungsmechanismen zu identifizieren.
OpenStack Networking fügt eine Ebene von virtualisierten Netzwerkdiensten hinzu, die den Tenants die Möglichkeit gibt, ihre eigenen virtuellen Netzwerke zu entwerfen. Derzeit sind diese virtualisierten Dienstleistungen nicht so reif wie ihre traditionellen Networking-Pendants. Betrachten Sie den aktuellen Stand dieser virtualisierten Dienste, bevor Sie sie annehmen, da sie diktiert, welche Kontrollen Sie an den virtualisierten und traditionellen Netzwerkgrenzen implementieren müssen.
L2 Isolation mit VLANs und Tunneling¶
OpenStack Networking kann zwei verschiedene Mechanismen für die Verkehrssegregation auf einer pro Tenant/Netzwerk-Kombination einsetzen: VLANs (IEEE 802.1Q Tagging) oder L2-Tunnel mit GRE-Kapselung. Das Ziel und der Umfang Ihrer OpenStack-Bereitstellung bestimmen, welche Methode Sie für die Verkehrssegregation oder die Isolation nutzen sollten.
VLANs¶
VLANs werden als Pakete auf einem bestimmten physischen Netzwerk mit IEEE 802.1Q-Headern mit einem bestimmten VLAN-ID (VID) Feldwert realisiert. VLAN-Netzwerke, die das gleiche physikalische Netzwerk teilen, sind bei L2 voneinander getrennt und können sogar überlappende IP-Adressräume aufweisen. Jedes einzelne physikalische Netzwerk, das VLAN-Netzwerke unterstützt, wird als separater VLAN-Trunk behandelt, mit einem deutlichen Raum von VID-Werten. Gültige VID-Werte sind 1 bis 4094.
Die VLAN-Konfigurationskomplexität hängt von Ihren OpenStack-Designanforderungen ab. Um OpenStack Networking effizient zu nutzen, um VLANs effizient zu nutzen, müssen Sie einen VLAN-Bereich (einen für jeden Tenant) zuordnen und jeden Compute-Knoten physikalischen Switch-Port in einen VLAN-Trunk-Port umwandeln.
Bemerkung
Wenn Sie beabsichtigen, dass Ihr Netzwerk mehr als 4094 Tenant unterstützt, ist VLAN wahrscheinlich nicht die richtige Option für Sie, da mehrere ‚Hacks‘ erforderlich sind, um die VLAN-Tags auf mehr als 4094 Tenant zu erweitern.
L2-Tunnelbau¶
Das Netzwerk-Tunneling kapselt jede Tenant-/Netzwerkkombination mit einer einzigartigen „Tunnel-ID“, die verwendet wird, um den Netzwerkverkehr zu identifizieren, der zu dieser Kombination gehört. Die L2-Netzwerkkonnektivität des Tenants ist unabhängig von physischer Lokalität oder zugrunde liegendem Netzwerkdesign. Durch das Einkapseln von Datenverkehr in IP-Paketen kann dieser Verkehr Layer-3-Grenzen überschreiten, wodurch die Notwendigkeit für vorkonfigurierte VLANs und VLAN-Trunking entfernt wird. Tunneln fügt eine Verschiebungsschicht für den Netzwerkdatenverkehr hinzu, wodurch die Sichtbarkeit des einzelnen Tenantverkehrs aus Überwachungssicht verringert wird.
OpenStack Networking unterstützt derzeit sowohl die GRE- als auch die VXLAN-Kapselung.
Die Wahl der Technologie zur Bereitstellung von L2-Isolation hängt von dem Umfang und der Größe der Tenant-Netzwerke ab, die in Ihrem Einsatz erstellt werden. Wenn Ihre Umgebung begrenzte VLAN-ID-Verfügbarkeit hat oder eine große Anzahl von L2-Netzwerken haben wird, ist es unsere Empfehlung, dass Sie Tunneling nutzen.
Netzwerkdienste¶
Die Wahl der Tenantnetz-Isolation beeinflusst, wie die Netzwerksicherheits- und Kontrollgrenze für Tenantdienste implementiert wird. Die folgenden zusätzlichen Netzwerkdienste sind entweder verfügbar oder derzeit in der Entwicklung, um die Sicherheitsposition der OpenStack-Netzwerkarchitektur zu verbessern.
Zugriffskontrolllisten¶
OpenStack Compute unterstützt die Direktzugriffskontrolle von Tenantnetzwerken direkt, wenn sie mit dem Legacy-Nova-Netzwerkdienst bereitgestellt wird, oder die Zugriffskontrolle auf den OpenStack Networking-Dienst verschieben.
Anmerkung, Legacy-Nova-Netzwerk-Sicherheitsgruppen werden auf alle virtuellen Schnittstellen-Ports auf einer Instanz mit iptables angewendet.
Sicherheitsgruppen erlauben Administratoren und Tenants die Möglichkeit, die Art des Verkehrs und die Richtung (Ingress/Egress) anzugeben, die durch einen virtuellen Schnittstellenport passieren darf. Sicherheitsgruppenregeln sind staatliche L2-L4-Verkehrsfilter.
Wenn Sie den Networking-Dienst verwenden, empfehlen wir Ihnen, Sicherheitsgruppen in diesem Dienst zu aktivieren und im Compute-Dienst zu deaktivieren.
L3-Routing und NAT¶
OpenStack Networking Router können mehrere L2 Netzwerke anschließen und können auch ein Gateway bereitstellen, das ein oder mehrere private L2 Netzwerke mit einem freigegebenen externen Netzwerk verbindet, z. B. einem öffentlichen Netzwerk für den Zugriff auf das Internet.
Der L3 Router bietet grundlegende Network Address Translation (NAT) Fähigkeiten auf Gateway Ports, die den Router auf externe Netzwerke verlagern. Dieser Router SNATs (Static NAT) ist standardmäßig standardmäßig und unterstützt schwimmende IPs, die eine statische Eins-zu-Eins-Zuordnung von einer öffentlichen IP auf dem externen Netzwerk zu einer privaten IP auf einem der anderen Subnetze, die an den Router angeschlossen sind, erstellt.
Es ist unsere Empfehlung, pro Tenant L3 Routing und Floating IPs für mehr granulare Konnektivität von Tenant VMs zu nutzen.
Quality of Service (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.
Der Networking Service (Neutron) unterstützt bandbreitenbegrenzende QoS Regeln in Liberty und später. Diese QoS-Regel heißt `` QosBandwidthLimitRule``und akzeptiert zwei nicht-negative Ganzzahlen, gemessen in Kilobit pro Sekunde:
max-kbps: bandbreitemax-burst-kbps: Burst-Puffer
Die ``QoSBandwidthLimitRule``wurde in den Neutronen Open VSwitch, Linux Bridge und Single Root Input/Output Virtualisierung (SR-IOV) Treiber implementiert.
In Newton wurde die QoS-Regel ``QosDscpMarkingRule``hinzugefügt. Diese Regel markiert den Wert des differenzierten Servicecodepunkts (DSCP) in der Art des Dienstkopfes auf IPv4 (RFC 2474) und Verkehrsklassenüberschrift auf IPv6 auf allen Verkehr, der eine virtuelle Maschine verlässt, wobei die Regel angewendet wird. Dies ist ein 6-Bit-Header mit 21 gültigen Werten, die
Port-Spiegelungsdienst beinhaltet das Senden einer Kopie von Paketen, die einen Port eingeben oder verlassen, einen anderen Port, der sich normalerweise von den ursprünglichen Zielen der Pakete unterscheidet, die gespiegelt sind. Tap-as-a-Service (TaaS) ist eine Erweiterung des OpenStack Networking Service (Neutron). Es bietet Remote-Port-Mirroring-Fähigkeit für virtuelle Tenant-Netzwerke. Dieser Service wurde in erster Linie dazu gedacht, den Tenants (oder dem Cloud-Administrator) zu helfen, komplexe virtuelle Netzwerke zu debuggen und in ihre VMs zu sehen, indem sie den damit verbundenen Netzwerkverkehr überwachen. TaaS ehrt Tenantgrenzen und seine Spiegelsitzungen sind in der Lage, über mehrere Compute- und Netzwerkknoten zu reisen. Es dient als wesentliche Infrastrukturkomponente, die für die Bereitstellung von Daten für eine Vielzahl von Netzwerkanalysen und Sicherheitsanwendungen genutzt werden kann.
Lastverteilung¶
Ein weiteres Merkmal in OpenStack Networking ist Load-Balancer-as-a-Service (LBaaS). Die LBaaS-Referenzimplementierung basiert auf HA-Proxy. Es gibt Drittanbieter-Plug-Ins in der Entwicklung für Erweiterungen in OpenStack Networking, um umfangreiche L4-L7-Funktionalität für virtuelle Schnittstellen-Ports bereitzustellen.
Firewalls¶
FW-as-a-Service (FWaaS) gilt als experimentell für die Kilo-Version von OpenStack Networking. FWaaS adressiert die Notwendigkeit, die umfangreichen Sicherheitsmerkmale zu verwalten und zu nutzen, die von typischen Firewall-Produkten bereitgestellt werden, die typischerweise weit umfassender sind als das, was derzeit von Sicherheitsgruppen bereitgestellt wird. Sowohl Freescale als auch Intel entwickelten Drittanbieter-Plug-Ins als Erweiterungen in OpenStack Networking, um diese Komponente in der Kilo-Version zu unterstützen. Weitere Informationen zur Verwaltung von FWaaS finden Sie unter Firewall-as-a-Service (FWaaS) Übersicht im OpenStack Administrator Guide.
Bei der Gestaltung einer OpenStack Networking-Infrastruktur ist es wichtig, dass Sie die aktuellen Funktionen und Einschränkungen der verfügbaren Netzwerkdienste verstehen. Das Verständnis der Grenzen Ihrer virtuellen und physischen Netzwerke wird dazu beitragen, die erforderlichen Sicherheitskontrollen in Ihrer Umgebung hinzuzufügen.
Netzwerkdienste Erweiterungen¶
Eine Liste der bekannten Plug-Ins, die von der Open-Source-Community oder von SDN-Unternehmen bereitgestellt werden, die mit OpenStack Networking arbeiten, ist unter OpenStack Neutron-Plug-Ins und Treiber-Wiki-Seite verfügbar.
Beschränkungen der Netzwerkdienste¶
OpenStack Networking hat folgende bekannte Einschränkungen:
- Überlappende IP-Adressen
Wenn Knoten, die entweder Neutron-l3-Agent oder Neutron-DHCP-Agent überlappende IP-Adressen verwenden, müssen diese Knoten Linux-Netzwerk-Namespaces verwenden. Standardmäßig verwenden die DHCP- und L3-Agenten Linux-Netzwerk-Namespaces und laufen in ihren eigenen Namespaces. Wenn der Host jedoch nicht mehrere Namespaces unterstützt, sollten die DHCP- und L3-Agenten auf separaten Hosts ausgeführt werden. Dies liegt daran, dass zwischen den vom L3-Agenten und dem DHCP-Agenten erstellten IP-Adressen keine Isolation besteht.
Wenn keine Netzwerk-Namespace-Unterstützung vorhanden ist, ist eine weitere Einschränkung des L3-Agenten, dass nur ein einzelner logischer Router unterstützt wird.
- Multi-Host DHCP-Agent
OpenStack Networking unterstützt mehrere L3- und DHCP-Agenten mit Lastverteilung. Eine enge Kopplung des Standortes der virtuellen Maschine wird jedoch nicht unterstützt. Mit anderen Worten, der Standard-Virtual Machine-Scheduler wird den Standort der Agenten bei der Erstellung virtueller Maschinen nicht berücksichtigen.
- Keine IPv6-Unterstützung für L3-Agenten
Der Neutron-l3-Agent, der von vielen Plug-Ins verwendet wird, um L3-Weiterleitung zu implementieren, unterstützt nur die IPv4-Weiterleitung.
