Networking - Überblick

Der Networking-Service verwendet virtuelle Versionen herkömmlicher Netzwerkkomponenten, mit denen Sie möglicherweise schon 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 deckt mindestens einen CIDR-Block ab (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 angeben, das in einer einzelnen Availability-Domain  oder in einer gesamten Region vorhanden sein soll (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 beim Erstellen eines Subnetzes bestimmen, ob es öffentlich oder privat sein soll. "Privat" 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. Die VNIC bestimmt, wie die Instanz mit Endpunkten innerhalb und außerhalb des VCN verbunden wird. Jede Instanz verfügt über eine primäre VNIC, die beim Starten der Instanz erstellt wird und nicht entfernt werden kann. Sie können sekundäre VNICs beliebig zu einer vorhandenen Instanz (in derselben Availability-Domain wie die primäre VNIC) hinzufügen und diese entfernen. Jede sekundäre VNIC kann sich in einem Subnetz im selben VCN wie die primäre VNIC oder in einem anderen Subnetz befinden, das sich entweder im selben VCN oder einem anderen Subnetz befindet. 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 Gültigkeitsdauer 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 Ihren 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)

Ein optionaler virtueller Router, den Sie Ihrem VCN hinzufügen können. Er stellt einen Pfad für privaten Netzwerktraffic zwischen dem VCN und dem On-Premise-Netzwerk bereit. Sie können ihn zusammen mit anderen Networking-Komponenten und einem Router in Ihrem On-Premise-Netzwerk verwenden, um eine Verbindung über Site-to-Site-VPN oder Oracle Cloud Infrastructure FastConnect herzustellen. Er kann auch einen Pfad für privaten Netzwerktraffic zwischen Ihrem und einem anderen VCN in einer anderen Region angeben. 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 Ihrem VCN für direkten Internetzugriff 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 zum 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 zum VCN hinzufügen können. Es stellt einen Pfad für privaten Netzwerkverkehr zwischen Ihrem VCN und unterstützten Services im Oracle Services Network bereit (Beispiele: Oracle Cloud Infrastructure Object Storage und Autonomous Database). Beispiel: DB-Systeme in einem privaten Subnetz im VCN können Daten in Object Storage sichern, ohne dass öffentliche IP-Adressen oder der Internetzugriff erforderlich sind. Weitere Informationen finden Sie unter Zugriff auf Oracle Services: Servicegateway.

LOKALES PEERING-GATEWAY (LPG)

Ein weiterer optionaler virtueller Router, den Sie zum VCN hinzufügen können. Damit können Sie eine Peering-Beziehung zwischen zwei VCNs in ein und derselben Region herstellen. Peering bedeutet, dass die VCNs über private IP-Adressen kommunizieren, ohne dass der Traffic über das Internet oder das On-Premise-Netzwerk geleitet wird. Ein VCN muss für jedes einzelne Peering ein separates 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 das VCN. Sie verfügen über Regeln, um Traffic von Subnetzen über Gateways oder speziell konfigurierte Instanzen an Ziele außerhalb des VCN weiterzuleiten. Ihr VCN enthält eine leere Standardroutentabelle, und Sie können eigene benutzerdefinierte Routentabellen hinzufügen. Weitere Informationen finden Sie unter VCN-Routentabellen.

SICHERHEITSREGELN

Virtuelle Firewallregeln für das VCN. Hierbei handelt es sich um Ingress- und Egress-Regeln, die die Traffictypen (Protokoll und Port) angeben, die in die und aus den Instanzen zulässig sind. Sie können wählen, ob eine bestimmte Regel für zustandsbehafteten oder zustandslosen Traffic bestimmt 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. Ihr VCN enthält eine Standardsicherheitsliste mit Standardsicherheitsregeln. Weitere Informationen finden Sie unter Sicherheitsregeln.

DHCP-OPTIONEN

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

Ein VCN deckt mindestens einen IPv4-CIDR-Block oder mindestens ein IPv6-Präfix Ihrer Wahl 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 Ihrer VNICs für die VNICs aktivieren. IPv6 kann auch auf vorhandenen Nur-IPv4-VCNs aktiviert werden. 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.

Oracle empfiehlt für das VCN die Verwendung der privaten IP-Adressbereiche, die in RFC 1918 angegeben sind. (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 verwiesen 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 sich weder untereinander noch mit den CIDRs in Ihrem On-Premise-Netzwerk oder mit den CIDRs eines anderen VCN, mit dem eine Peering-Beziehung besteht, überschneiden. Die Subnetze in einem angegebenen 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.

Ihr 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, weshalb die zugehörigen Ressourcen in einer bestimmten Availability-Domain gespeichert sein mussten. Jetzt können Subnetze AD-spezifisch oder regional sein. Sie wählen den Typ beim Erstellen des Subnetzes. Beide Arten von Subnetzen können in demselben VCN vorhanden sein. Im folgenden Diagramm sind die Subnetze 1-3 AD-spezifisch und Subnetz 4 regional.

Abgesehen vom Entfernen des AD-Constraints verhalten sich regionale Subnetze genauso wie AD-spezifische Subnetze. Oracle empfiehlt die Verwendung von regionalen Subnetzen, da sie flexibler sind. Sie erleichtern die effiziente Aufteilung des VCN in Subnetze, während sie gleichzeitig vorbeugend für etwaige Availability-Domain-Ausfälle konzipiert sind.

Wenn Sie eine Ressource wie eine Compute-Instanz erstellen, wählen Sie aus, in welcher Availability-Domain sich die Ressource befindet. Vom Standpunkt des virtuellen Netzwerks aus müssen Sie auch wählen, in welchem VCN und Subnetz sich die Instanz befinden wird. Sie können entweder ein regionales Subnetz 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 auswählen, 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 Ihr VCN so einrichten, dass Sie auf Wunsch auch Zugriff auf das Internet haben. Sie können Ihr VCN außerdem mit öffentlichen Oracle Cloud Infrastructure-Services, wie Object Storage, mit Ihrem On-Premise-Netzwerk oder einem anderen VCN verbinden.

Diese Dokumentation enthält einige grundlegende Networking-Szenarios, mit denen Sie den Networking-Service und generell die Zusammenarbeit der Komponenten 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

Ihr VCN befindet sich in einer einzelnen Oracle Cloud Infrastructure-Region. Jedes Subnetz befindet sich in einer einzelnen Availability-Domain (AD). Verfügbarkeitsdomains sind für die Bereitstellung von Isolation und Redundanz in Ihrem VCN konzipiert, wie in Szenario B und Szenario C beschrieben. Beispielsweise können Sie das primäre Set von Subnetzen in einer einzelnen AD einrichten und dann ein dupliziertes 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 eine Automatisierung basierend auf Statusänderungen für Ihre Oracle Cloud Infrastructure-Ressourcen erstellen, indem Sie Ereignistypen, Regeln und Aktionen verwenden. Weitere Informationen finden Sie unter Überblick über Events.

Die meisten Typen von Oracle Cloud Infrastructure-Ressourcen besitzen 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 das Netzwerk 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, Routentabellen, Gateways usw.) ab. Weitere Informationen dazu, wie Netzwerkadministratoren Instanzen starten können (um die Netzwerkkonnektivität zu testen), finden Sie unter Starten von Compute-Instanzen durch Benutzer zulassen.

Wenn Sie mit Policys nicht vertraut sind, finden Sie weitere Informationen unter Erste Schritte mit Policys und Allgemeine Policys.

Referenzmaterial für das Schreiben detaillierter Policys zu 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.