Networking - Überblick

Der Networking-Service verwendet virtuelle Versionen herkömmlicher Netzwerkkomponenten, mit denen Sie möglicherweise bereits vertraut sind:

Virtuelles Cloud-Netzwerk (VCN)

Ein virtuelles, privates Netzwerk, das Sie in Oracle-Data Centern einrichten. Es ähnelt in etwa einem herkömmlichen Netzwerk mit Firewallregeln und spezifischen Typen von Kommunikationsgateways, die Sie verwenden können. Ein VCN befindet sich in einer einzelnen Oracle Cloud Infrastructure-Region und umfasst mindestens einen CIDR-Block (IPv4 und IPv6, sofern aktiviert). Siehe Zulässige VCN-Größe und Adressbereiche. Die Begriffe "Virtuelles Cloud-Netzwerk", "VCN" und "Cloud-Netzwerk"" werden in dieser Dokumentation gleichbedeutend verwendet. Weitere Informationen finden Sie unter VCNs und Subnetze.

SUBNETZE

Unterteilungen, die Sie in einem VCN definieren (Beispiel: 10.0.0.0/24, 10.0.1.0/24 oder 2001:DB8::/64). Subnetze enthalten virtuelle Netzwerkkarten (VNICs), die an Instanzen angehängt werden. Jedes Subnetz besteht aus einem zusammenhängenden Bereich von IP-Adressen (für IPv4 und IPv6, sofern aktiviert), die sich mit keinen anderen Subnetzen im VCN überschneiden. Sie können ein Subnetz so festlegen, dass es in einer einzelnen Availability-Domain oder in einer gesamten Region vorhanden ist (regionale Subnetze werden empfohlen). Subnetze fungieren als eine Konfigurationseinheit im VCN: Alle VNICs in einem bestimmten Subnetz verwenden dieselbe Routentabelle sowie dieselben Sicherheitslisten und DHCP-Optionen (siehe folgende Definitionen). Sie können ein Subnetz beim Erstellen als öffentlich oder privat definieren. Private bedeutet, dass VNICs im Subnetz keine öffentlichen IPv4-Adressen haben können und dass die Internetkommunikation mit IPv6-Endpunkten unzulässig ist. "Öffentlich" bedeutet, dass VNICs im Subnetz öffentliche IPv4-Adressen haben können und dass die Internetkommunikation mit IPv6-Endpunkten zulässig ist. Siehe Zugriff auf das Internet.

VNIC

Eine virtuelle Netzwerkkarte (VNIC), die an eine Instanz angehängt wird und sich in einem Subnetz befindet, um eine Verbindung zum VCN des Subnetzes herzustellen. Eine VNIC ist die Komponente, mit der die Instanz eine Verbindung zu Endpunkten innerhalb und außerhalb des VCN herstellt. Jede Instanz verfügt über eine primäre VNIC, die beim Erstellen der Instanz erstellt wird und nicht entfernt werden kann. Sie können sekundäre VNICs nach Bedarf zu einer vorhandenen Instanz (in derselben Availability-Domain wie die primäre VNIC) hinzufügen und entfernen. Jede sekundäre VNIC kann sich in einem Subnetz im selben VCN wie die primäre VNIC oder in einem anderen Subnetz entweder im selben VCN oder einem anderen Subnetz befinden. Alle VNICs müssen sich jedoch in derselben Availability-Domain wie die Instanz befinden. Weitere Informationen finden Sie unter Virtuelle Netzwerkkarten (VNICs). Einer VNIC, die an eine Compute-Instanz angehängt ist und sich in einem IPv6-fähigen Subnetz befindet, kann optional eine IPv6-Adresse zugewiesen werden.

PRIVATE IP

Eine private IPv4-Adresse und zugehörige Informationen zur Adressierung einer Instanz (z.B. ein Hostname für DNS). Jede VNIC verfügt über eine primäre private IP, und Sie können sekundäre private IPs hinzufügen und entfernen. Die primäre private IP-Adresse einer Instanz ändert sich während der Lebensdauer der Instanz nicht und kann nicht aus der Instanz entfernt werden. Weitere Informationen finden Sie unter Private IP-Adressen.

ÖFFENTLICHE IP

Eine öffentliche IPv4-Adresse und zugehörige Informationen. Sie können optional eine öffentliche IP zu Instanzen oder anderen Ressourcen zuweisen, die über eine private IP verfügen. Öffentliche IPs können ephemer oder reserviert sein. Weitere Informationen finden Sie unter Öffentliche IP-Adressen.

IPV6

Eine IPv6-Adresse und zugehörige Informationen. Die IPv6-Adressierung wird für alle kommerziellen und Regierungsregionen unterstützt. Weitere Informationen finden Sie unter IPv6-Adressen.

Dynamisches Routinggateway (DRG)

Einen optionalen virtuellen Router, den Sie einem VCN hinzufügen können. Er stellt einen Pfad für privaten Netzwerkverkehr zwischen einem VCN und einem On-Premise-Netzwerk bereit. Sie können ihn zusammen mit anderen Netzwerkkomponenten und einem Router in einem On-Premise-Netzwerk verwenden, um eine Verbindung über Site-to-Site-VPN oder Oracle Cloud Infrastructure FastConnect herzustellen. Sie kann auch einen Pfad für privaten Netzwerktraffic zwischen einem VCN und einem anderen VCN in einer anderen Region bereitstellen. Weitere Informationen finden Sie unter Zugriff auf Ihr On-Premise-Netzwerk, Dynamische Routinggateways und Remote-VCN-Peering mit einem Legacy-DRG.

INTERNETGATEWAY

Ein weiterer optionaler virtueller Router, den Sie einem VCN für direkten Internetzugang hinzufügen können. Weitere Informationen finden Sie unter Zugriff auf das Internet und auch Szenario A: Öffentliches Subnetz.

NAT-(NETWORK ADDRESS TRANSLATION-)GATEWAY

Ein weiterer optionaler virtueller Router, den Sie einem VCN hinzufügen können. Er ermöglicht Cloud-Ressourcen ohne öffentliche IP-Adressen den Zugriff auf das Internet, ohne dass diese Ressourcen für eingehende Internetverbindungen freigegeben werden. Weitere Informationen finden Sie unter Öffentliche und private Subnetze im Vergleich und unter NAT-Gateway.

SERVICEGATEWAY

Ein weiterer optionaler virtueller Router, den Sie einem VCN hinzufügen können. Es stellt einen Pfad für privaten Netzwerkverkehr zwischen einem VCN und nicht unterstützten Services im Oracle Services Network bereit (Beispiele: Oracle Cloud Infrastructure Object Storage und Autonomous Database). Beispiel: DB-Systeme in einem privaten Subnetz in einem VCN können Daten in Object Storage sichern, ohne dass öffentliche IP-Adressen oder der Internetzugang erforderlich sind. Weitere Informationen finden Sie unter Zugriff auf Oracle Services: Servicegateway.

LOKALES PEERING-GATEWAY (LPG)

Ein weiterer optionaler virtueller Router, den Sie einem VCN hinzufügen können. Damit können Sie eine Peering-Beziehung zwischen zwei VCNs in ein und derselben Region herstellen. Peering bezeichnet die Kommunikation der VCNs über private IP-Adressen, ohne dass der Traffic über das Internet oder ein On-Premise-Netzwerk geleitet wird. Ein VCN muss für jedes einzelne Peering ein eigenes LPG haben. Weitere Informationen finden Sie unter Lokales VCN-Peering mit lokalen Peering-Gateways.

REMOTE-PEERING-VERBINDUNG (RPC)

Eine Komponente, die Sie einem DRG hinzufügen können. Damit können Sie eine Peering-Beziehung zwischen zwei VCNs in unterschiedlichen Regionen herstellen. Weitere Informationen finden Sie unter Remote-VCN-Peering mit einem Legacy-DRG.

ROUTENTABELLEN

Virtuelle Routentabellen für ein VCN. Sie verfügen über Regeln, um Traffic von Subnetzen über Gateways oder speziell konfigurierte Instanzen an Ziele außerhalb des VCN weiterzuleiten. Ein VCN enthält eine leere Standardroutentabelle, und Sie können benutzerdefinierte Routentabellen hinzufügen. Weitere Informationen finden Sie unter VCN-Routentabellen.

SICHERHEITSREGELN

Virtuelle Firewallregeln für ein VCN. Ingress- und Egress-Regeln werden die Traffictypen (Protokoll und Port) angegeben, die in und aus den Instanzen zulässig sind. Sie können entscheiden, ob eine bestimmte Regel zustandsbehaftet oder zustandslos ist. Beispiel: Sie können eingehenden SSH-Verkehr von einer beliebigen Quelle zu Instanzen zulassen, indem Sie eine Regel für zustandsbehafteten Ingress mit Quell-CIDR 0.0.0.0/0 und Ziel-TCP-Port 22 einrichten. Zur Implementierung von Sicherheitsregeln können Sie Netzwerksicherheitsgruppen oder Sicherheitslisten verwenden. Eine Netzwerksicherheitsgruppe besteht aus einem Set von Sicherheitsregeln, die nur für die Ressourcen in dieser Gruppe gelten. Im Gegensatz dazu werden bei einer Sicherheitsliste die Regeln auf alle Ressourcen in einem Subnetz angewendet, das die Liste verwendet. Ein VCN enthält eine Standardsicherheitsliste mit Standardsicherheitsregeln. Weitere Informationen finden Sie unter Sicherheitsregeln.

DHCP-OPTIONEN

Konfigurationsinformationen, die automatisch den Instanzen beim Booten bereitgestellt werden. Weitere Informationen finden Sie unter DHCP-Optionen.

CIDR-NOTATION

Eine kompakte Methode zur Angabe von IP-Adressen oder Adressbereichen und Netzwerkmasken. Beispiel: Wenn Sie IPv4 verwenden, stellt ein privater IP-Adressbereich von 10.0.0.0/24 alle Adressen zwischen 10.0.0.0 und 10.0.0.255 dar. /24 stellt eine Subnetzmaske von 255.255.255.0 dar, da die ersten 24 Bit maskiert sind. IPv6 verwendet eine ähnliche Notation wie für Adressblöcke. Weitere Informationen finden Sie in RFC1817 und RFC1519.

Ein VCN deckt einen oder mehrere IPv4 CIDR-Blöcke oder IPv6-Präfixe ab. Der zulässige VCN-Größenbereich liegt bei /16 bis /30. Beispiel: 10.0.0.0/16. Der Networking-Service reserviert die ersten beiden IP-Adressen und die letzte IP-Adresse im CIDR jedes Subnetzes. Sie können IPv6 beim Erstellen für VCNs oder IPv6 auf vorhandenen Nur-IPv4-VCNs aktivieren. Wenn Sie sich für ein von Oracle zugewiesenes IPv6-Präfix entscheiden, erhalten Sie immer ein /56. Alternativ können Sie ein eigenes BYOIP-IPv6-Präfix importieren, aus dem Sie einem VCN ein beliebiges Präfix von /64 oder größer zuweisen können, oder Sie können ein ULA-Präfix von /64 oder größer zuweisen. GUA-Bereiche können bis zu 2000::/3 sein und ULA-Bereiche bis zu fc00::/7. Alle IPv6-Subnetze weisen stets eine Größe von /64 auf.

Für ein VCN wird empfohlen, die in RFC 1918 angegebenen privaten IP-Adressbereiche zu verwenden (der RFC empfiehlt 10.0/8 oder 172.16/12. Oracle unterstützt diese Größen jedoch nicht. Verwenden Sie daher 10.0/16, 172.16/16 und 192.168/16). Sie können jedoch einen öffentlich routbaren Bereich verwenden. Unabhängig davon wird in dieser Dokumentation der Begriff Private IP-Adresse verwendet, wenn auf IP-Adressen im CIDR des VCN Bezug genommen wird. Nicht zulässige Adressbereiche werden unter Für die Verwendung durch Oracle reservierte IP-Adressen beschrieben. Bei IPv6-fähigen VCNs kann entweder von Oracle ein Global Unicast Address-(GUA-)Präfix der Größe /56 zugewiesen werden, oder Sie können ein VCN mit einem BYOIPv6-Präfix erstellen.

Die CIDR-Blöcke des VCN dürfen weder untereinander noch mit CIDRs in einem verbundenen On-Premise-Netzwerk oder mit dem CIDRs eines anderen VCN, mit dem Sie eine Peering-Beziehung haben, überschneiden. Die Subnetze in einem bestimmten VCN dürfen sich nicht gegenseitig überschneiden. Zu Referenzzwecken finden Sie hier einen CIDR-Rechner.

Die IPv6-Adressierung wird für alle kommerziellen und Regierungsregionen unterstützt. Weitere Informationen finden Sie unter IPv6-Adressen.

Ein VCN befindet sich in einer einzelnen Oracle Cloud Infrastructure-Region. Eine Region kann über mehrere Availability-Domains verfügen, um Isolation und Redundanz zu gewährleisten. Weitere Informationen finden Sie unter Regionen und Availability-Domains.

Ursprünglich waren Subnetze für die Abdeckung von nur einer Availability-Domain (AD) in einer Region konzipiert. Dabei handelte es sich ausschließlich um AD-spezifische Subnetze, die sich also in einer bestimmten Availability-Domain befinden mussten. Jetzt können Subnetze AD-spezifisch oder regional sein. Sie wählen den Typ beim Erstellen des Subnetzes aus. Beide Arten von Subnetzen können in demselben VCN vorhanden sein. Im folgenden Diagramm sind die Subnetze 1 bis 3 AD-spezifisch und Subnetz 4 regional.

Abgesehen vom Entfernen des AD-Constraints verhalten sich regionale Subnetze genauso wie AD-spezifische Subnetze. Es wird empfohlen, regionale Subnetze zu verwenden, da sie flexibler sind. Sie machen es einfacher, ein VCN effizient in Subnetze zu unterteilen, während sie gleichzeitig für Availability-Domainausfälle konzipiert sind.

Wenn Sie eine Ressource wie eine Compute-Instanz erstellen, entscheiden Sie, in welcher Availability-Domain sich die Ressource befindet. Vom Standpunkt des virtuellen Netzwerks aus müssen Sie auch entscheiden, in welchem VCN und Subnetz sich die Instanz befindet. Sie können entweder ein regionales oder ein AD-spezifisches Subnetz auswählen, das der für die Instanz gewählten AD entspricht.

Jedem Subnetz sind immer die folgenden Komponenten zugeordnet:

• Eine Routentabelle
• Eine oder mehrere Sicherheitslisten (die maximale Anzahl finden Sie unter Servicelimits)
• Ein Set von DHCP-Optionen

Während der Erstellung eines Subnetzes können Sie entscheiden, welche Routentabelle, Sicherheitsliste und welches Set von DHCP-Optionen das Subnetz verwendet. Wenn Sie keine bestimmte Komponente angeben, verwendet das Subnetz automatisch die Standardkomponente des VCN. Sie können jederzeit die vom Subnetz verwendeten Komponenten ändern.

Sie können bestimmen, ob Subnetze öffentlich oder privat sind und ob Instanzen öffentliche IP-Adressen abrufen. Sie können ein VCN einrichten, um bei Bedarf Zugriff auf das Internet zu haben. Sie können ein VCN auch mit öffentlichen Oracle Cloud Infrastructure-Services, wie Object Storage, mit einem On-Premise-Netzwerk oder einem anderen VCN verbinden.

Diese Dokumentation enthält einige grundlegende Networking-Szenarios, mit denen Sie den Networking-Service und die Zusammenarbeit der Komponenten im Allgemeinen verstehen können. Weitere Informationen finden Sie in diesen Themen:

• Szenario A: Öffentliches Subnetz
• Szenario B: Privates Subnetz mit einem VPN
• Szenario C: Öffentliche und private Subnetze mit einem VPN

Ein VCN befindet sich in einer einzelnen Oracle Cloud Infrastructure-Region. Jedes Subnetz befindet sich in einer einzelnen Availability-Domain (AD). Availability-Domains sind für die Bereitstellung von Isolation und Redundanz im VCN konzipiert, wie in Szenario B und Szenario C bereits erwähnt dargestellt. Beispiel: Sie können ein primäres Set von Subnetzen in einer einzelnen AD einrichten und dann ein doppeltes Set von Subnetzen in einer sekundären AD einrichten. Die beiden ADs werden in den Oracle-Data Centern voneinander isoliert. Wenn also ein Fehler auftritt, können Sie einfach zu der anderen AD wechseln. Weitere Informationen finden Sie unter Regionen und Availability-Domains.

Eine Liste der öffentlichen IP-Bereiche von Oracle Cloud Infrastructure finden Sie unter IP-Adressbereiche.

Sie können Automatisierung basierend auf Statusänderungen für Oracle Cloud Infrastructure-Ressourcen erstellen, indem Sie Ereignistypen, Regeln und Aktionen verwenden. Weitere Informationen finden Sie unter Überblick über Events.

Die meisten Oracle Cloud Infrastructure-Ressourcentypen verfügen über eine eindeutige, von Oracle zugewiesene ID, die als Oracle Cloud-ID (OCID) bezeichnet wird. Informationen zum OCID-Format und zu anderen Möglichkeiten zur Identifizierung der Ressourcen finden Sie unter Ressourcen-IDs.

Allgemeine Informationen zur Verwendung der API finden Sie unter REST-APIs.

Die einfachste Methode zum Erteilen des Zugriffs auf Networking ist die Policy, die unter Verwalten eines Cloud-Netzwerks durch Netzwerkadministratoren zulassen aufgeführt wird. Sie deckt das Cloud-Netzwerk und alle anderen Netzwerkkomponenten (Subnetze, Sicherheitslisten, Routing-Tabellen, Gateways usw.) ab. Weitere Informationen finden Sie unter Starten von Compute-Instanzen durch Benutzer zulassen.

Wenn Sie mit Policys neu sind, finden Sie weitere Informationen unter Identitätsdomains verwalten und Allgemeine Policys.

Referenzmaterial für das Schreiben detaillierter Policys für Networking finden Sie unter Details zu den Coreservices.

In den Servicelimits finden Sie eine Liste der jeweiligen Limits sowie Anweisungen dazu, wie Sie eine Erhöhung beantragen.