Ein VCN ist ein anpassbares privates Netzwerk in Oracle Cloud Infrastructure. Genau wie bei einem herkömmlichen Rechenzentrums-Netzwerk bietet Ihnen ein VCN die vollständige Kontrolle über Ihre Netzwerkumgebung. Dies umfasst das Zuweisen Ihres eigenen privaten IP-Adressraums, das Erstellen von Subnetzen sowie Routingtabellen und das Konfigurieren von Stateful Firewalls. Ein einzelner Mandant (ein Oracle Cloud Infrastructure-Konto) kann über mehrere VCNs verfügen, wodurch die Gruppierung und Isolation verwandter Ressourcen ermöglicht wird. Beispielsweise können Sie mehrere VCNs verwenden, um die Ressourcen in verschiedenen Abteilungen Ihres Unternehmens zu verteilen.
Eine vollständige Liste der Komponenten finden Sie unter Überblick über Netzwerke.
Eine kurze Anleitung zum Starten einer Instanz in einem VCN in Oracle Cloud Infrastructure finden Sie unter Erste Schritte.
Siehe auch diese Themen:
Beim Erstellen Ihres VCN weisen Sie einen zusammenhängenden IPv4 CIDR-Block Ihrer Wahl zu. VCN-Größen von /16 (65.533 IP-Adressen) bis /30 (1 IP-Adresse) sind zulässig. Beispiel: 10.0.0.0/16, 192.168.0.0/24.
Wir empfehlen die Verwendung eines CIDR-Blocks aus den privaten Adressbereichen, die in RFC1918 angegeben sind. Wenn Sie einen nicht in RFC1918 angegebenen CIDR-Block verwenden, beachten Sie, dass dieser weiterhin als privater IP-Adressbereich behandelt wird und nicht über das Internet-Gateway von Oracle aus dem Internet weitergeleitet werden kann.
Sie erstellen Subnetze, indem Sie den Adressbereich des VCN in zusammenhängende IPv4 CIDR-Blöcke unterteilen. Der CIDR-Block eines Subnetzes muss in den CIDR-Block des VCN fallen. Wenn Sie eine Instanz in einem Subnetz starten, wird die private IP-Adresse der Instanz aus dem CIDR-Block des Subnetzes zugewiesen.
Ja. Wenn Sie ein Subnetz erstellen, können Sie den Zugriffstyp festlegen: entweder Privat oder Öffentlich. Standardmäßig wird ein Subnetz mit öffentlichem Zugriff erstellt. In diesem Fall kann den Instanzen im Subnetz eine öffentliche IP-Adresse zugewiesen werden. In einem Subnetz mit privatem Zugriff gestartete Instanzen dürfen keine öffentlichen IP-Adressen haben, wodurch sichergestellt wird, dass diese Instanzen keinen direkten Internetzugang haben.
Ja.
Subnetze können sich über mehrere Verfügbarkeitsdomänen erstrecken, jedoch nicht über mehrere VCNs. Wenn Sie ein regionales Subnetz erstellen, können sich die Ressourcen des Subnetzes in einer beliebigen Verfügbarkeitsdomäne (AD) in der Region befinden. Wenn Sie jedoch ein AD-spezifisches Subnetz erstellen, müssen sich die Ressourcen des Subnetzes in der speziellen Verfügbarkeitsdomäne des Subnetzes befinden.
Ja. Wenn Sie jedoch beabsichtigen, ein VCN mit Ihrem On-Premises-Netzwerk oder einem anderen VCN zu verbinden, empfehlen wir, sicherzustellen, dass sich die IP-Adressbereiche nicht überschneiden.
Aktuelle Limits für alle Services und Anweisungen zum Anfordern einer Service-Limit-Erhöhung finden Sie in der Hilfedokumentation zu Service-Limits.
Ja. Sie können den Namen des Subnetzes bearbeiten und ändern, welche Routingtabelle, Sicherheitslisten und DHCP-Optionen ihm zugeordnet sind. Sie können jedoch nicht den CIDR-Block des Subnetzes ändern.
Die neue Funktionalität ist in der kommerziellen Realm verfügbar. Sie wird künftig auch in anderen Realms zur Verfügung gestellt werden.
Die neue Funktionalität ist in allen kommerziellen Oracle Cloud Infrastructure (OCI)-Regionen verfügbar.
Ja. Sie müssten das DRG allerdings über den Aktualisierungsprozess, der in der Dokumentation beschrieben ist, aktualisieren.
Die Kommunikation zwischen DRG-Anhängen (einschließlich VCNs) wird von Routentabellen und den zugehörigen Import-Policys gesteuert. Mit der Standardroutentabelle für VCN-Anhänge können alle angehängten VCNs miteinander kommunizieren. Sie können die zugehörige Import-Policy ändern, um VCNs wie hier dargestellt zu isolieren.
Ja. Dazu muss allerdings eine bestimmte IAM-Policy konfiguriert werden
Das DRG unterstützt dynamisches und statisches Routing zwischen verbundenen Netzwerken. Das DRG verfügt über zwei Standardroutentabellen. Eine für Ihre FastConnect-, IPsec-VPN- und RPC-Peering-Anhänge und eine für VCN-Anhänge. Sie können weitere Routentabellen erstellen, um eine feinstufigere Kontrolle des Verkehrsflusses zwischen Anhängen zu ermöglichen. Die Routen entscheiden je nach IP-Zieladresse des Pakets über den nächsten Hop.
Statische Routen haben eine höhere Präferenz als dynamische Routen. Sie können nicht mehrere statische Routen für dasselbe Classless Inter-Domain Routing (CIDR) erstellen. Bei dynamischen Routen werden Konflikte wie folgt aufgelöst:
Sie können festlegen, wie Routen auf der Basis einer jeweiligen Routentabelle importiert und exportiert werden, indem Sie die zugehörigen Import- und Export-Policys ändern. Routen werden wie folgt weitergegeben:
Sie können zwei OCI-VCNs mit sich überschneidenden CIDRs mit dem selben DRG verbinden. Die Routentabelle des DRGs fällt eine deterministische und konsistente Weiterleitungsentscheidung, um zu bestimmen, welcher VCN-Anhang der nächste Hop für die unvereinbaren Subnetz-CIDRs ist. Diese Reihenfolge der Präferenzen kann vom Kunden nicht gesteuert werden. Da die Steuerung dieses Verhaltens sehr komplex ist, werden sich überschneidende CIDRs nicht empfohlen.
Ja, das DRG ermöglicht Ihnen jetzt, ein FastConnect in einer Region zu verwenden, um mit Ressourcen in einem VCN in einer anderen Region zu kommunizieren.
Einzelheiten zu Limits oder Quoten finden Sie in unserer Dokumentation.
Sollten Sie diese Limits überschreiten müssen, erstellen Sie bitte einen Supportfall.
Ja, das DRG unterstützt das Anhängen von VCNs an IPv6-CIDRs.
Das Standardverhalten des DRG hat sich nicht verändert. Die neuen Funktionen müssen explizit aktiviert werden.
Das DRG verfügt über zwei Standardroutentabellen. Eine für Ihre FastConnect-, IPsec-VPN- und RPC-Peering-Anhänge und eine für VCN-Anhänge. Diese beiden Standardroutentabellen implementieren das bestehende DRG-Verhalten.
Jedes VCN kann bis zu 10 lokale Peering-Gateways und ein DRG aufweisen. Ein einzelnes DRG unterstützt bis zu 300 VCN-Anhänge. Wir empfehlen die Verwendung des DRG, wenn Sie Peering mit einer großen Anzahl von VCNs ausführen müssen. Sollten Sie außerdem eine extrem hohe Bandbreite und eine äußerst geringe Latenz zwischen zwei VCNs in der selben Region benötigen, sollten Sie das Szenario, das in Local VCN Peering mit lokalen Peering-Gateways beschrieben wird, verwenden. Durch das Peering von zwei VCNs in der selben Region über ein DRG sichern Sie sich bei Ihrem Routing mehr Flexibilität. Allerdings müssen Sie dabei höhere Latenzzeiten und möglicherweise eine geringere Bandbreite in Kauf nehmen.
Das derzeitige Limit liegt bei 8 Pfaden
Ziehen Sie bitte hier den Abschnitt „Upgraden eines DRG“ zu Rate.
Die Server in Oracle Cloud Infrastructure-Rechenzentren verfügen über physische Netzwerk-Schnittstellenkarten (NICs). Wenn Sie eine Instanz auf einem dieser Server starten, kommuniziert die Instanz über die virtuellen Netzwerk-Schnittstellenkarten (VNICs) des Netzwerkdienstes, die den physischen Netzwerk-Schnittstellenkarten zugeordnet sind. Eine VNIC ermöglicht die Verbindung einer Compute-Instanz mit einem VCN und bestimmt, wie die Instanz mit Endpunkten innerhalb und außerhalb des VCN kommuniziert.
Jede VNIC befindet sich in einem Subnetz und besitzt die folgende Konfiguration:
Weitere Informationen finden Sie unter Virtuelle Netzwerkschnittstellenkarten (VNICs).
Jede Instanz in Ihrem VCN wird mit einer VNIC erstellt, die eine private IP-Adresse (von Ihnen oder Oracle zugewiesen) aus dem bei der Instanzerstellung bereitgestellten Subnetz und eine entsprechende öffentliche IP-Adresse besitzt. Diese VNIC wird als die primäre VNIC bezeichnet und ihre private IP-Adresse als primäre private IP-Adresse.
Die primäre VNIC kann nicht von der Instanz getrennt werden. Sie wird automatisch gelöscht, wenn die Instanz beendet wird.
Jede Instanz in Ihrem VCN verfügt über mindestens eine VNIC, bei der es sich um die primäre VNIC handelt. Sie können einer Instanz zusätzliche VNICs hinzufügen, die als sekundäre VNICs bezeichnet werden . Die sekundären VNICs können zu verschiedenen VCNs oder Subnetzen gehören.
Die Anzahl der VNICs, die an eine Instanz angehängt werden können, hängt von der Form ab. Informationen zu diesen Limits finden Sie in der Support-Dokumentation zu Compute-Ausprägungen.
Ja. Fragen Sie den unter http://169.254.169.254/opc/v1/vnics/ verfügbaren Instanz-Metadatendienst ab.
Ja. Bei der primären VNIC können Sie die private IP-Adresse beim Start der Instanz angeben. Bei sekundären VNICs können Sie eine private IP-Adresse angeben, wenn Sie die VNIC an eine Instanz anhängen. Die angegebene private IP-Adresse sollte zu demselben Subnetz gehören, zu dem die VNIC gehört, und sollte nicht verwendet werden.
Nein. Derzeit sind VNICs immer an die Instanz gebunden und existieren nicht unabhängig voneinander. Die primäre VNIC wird mit der Instanz erstellt und zerstört. Alle sekundären VNICs werden erstellt und zerstört, wenn sie angehängt bzw. getrennt werden.
Ja. Das Anhängen mehrerer VNICs aus demselben CIDR-Subnetzblock an eine Instanz kann jedoch zu asymmetrischem Routing führen, insbesondere bei Instanzen, die eine Linux-Variante verwenden. Wenn Sie diese Art der Konfiguration benötigen, empfiehlt Oracle, einer VNIC mehrere private IP-Adressen zuzuweisen oder richtlinienbasiertes Routing zu verwenden. Ziehen Sie zum Beispiel das Skript Linux: Konfiguration des BS für sekundäre VNICs zu Rate.
Nein. Alle VNICs müssen zu Subnetzen in derselben AD wie die Instanz gehören. Bei Verwendung regionaler Subnetze müssen die VNICs in derselben AD wie die Instanz erstellt werden.
Ja. Sie können sekundäre VNICs anfügen, die zu einem Subnetz eines VCN gehören, das sich vom VCN der primären VNIC unterscheidet.
Jede Recheninstanz in Ihrem VCN wird mit einer virtuellen Netzwerk-Schnittstellenkarte (VNIC) erstellt und erhält eine private IP-Adresse aus dem Subnetz, das beim Start der Instanz bereitgestellt wird. Dies sind die primäre VNIC bzw. ihre primäre private IP-Adresse . Sie können einer Instanz, die als sekundäre VNIC bezeichnet wird, weitere VNICs hinzufügen, die auch über eine primäre private IP-Adresse verfügen.
Oracle kann die private IP-Adresse auswählen oder Sie wählen Sie aus dem verfügbaren Pool des Subnetzes aus. Wenn die von Ihnen angegebene Adresse bereits verwendet wird, schlägt die Startanforderung fehl.
Darüber hinaus können Sie einer VNIC sekundäre private IP-Adressen zuweisen. Ähnlich wie primäre private IP-Adressen bietet eine sekundäre private IP-Adresse Konnektivität zu Zielen innerhalb Ihres VCN und/oder On-Premise (wenn eine Konnektivität über VPN oder Oracle Cloud Infrastructure FastConnect besteht).
Ja. Sie können eine sekundäre private IP-Adresse von einer VNIC auf einer Instanz auf eine VNIC auf einer anderen Instanz verschieben, sofern beide VNICs demselben Subnetz angehören und die Autorisierung den Vorgang zulässt. Bei Verwendung regionaler Subnetze kann die sekundäre private IP-Adresse auch auf eine VNIC in einer anderen AD verschoben werden.
Derzeit können Sie einer VNIC bis zu 31 sekundäre private IP-Adressen zuweisen.
Nein. Das Betriebssystem kann die sekundäre private IP-Adresse nicht mithilfe von Mechanismen wie DHCP erkennen. Sie müssen die sekundären privaten IP-Adressen mithilfe eines betriebssystemspezifischen Verfahrens konfigurieren. Weitere Informationen finden Sie in den Skripten, die unter Virtuelle Netzwerkschnittstellenkarten (VNICs) bereitgestellt werden.
Eine öffentliche IP-Adresse ist eine IPv4-Adresse, die über das Internet erreichbar ist (eine IP-Adresse, die über das Internet weitergeleitet werden kann). Eine Instanz in Ihrem VCN kommuniziert mit Hosts im Internet über eine öffentliche IP-Adresse. Eine private IP-Adresse kann nicht über das Internet weitergeleitet werden. Instanzen innerhalb des VCN kommunizieren unter Verwendung privater IP-Adressen miteinander.
Sie können einer privaten IP-Adresse einer Compute-Instanz oder einer Load Balancer-Instanz eine öffentliche IP-Adresse zuweisen und diese für die Kommunikation mit dem Internet aktivieren. Damit eine öffentliche IP-Adresse über das Internet erreichbar ist, muss die VCN, in der sie sich befindet, über ein Internet-Gateway verfügen. Im öffentlichen Subnetz müssen Routingtabellen und Sicherheitslisten entsprechend konfiguriert sein.
Es gibt zwei Arten von öffentlichen IP-Adressen:
Weitere Informationen und eine Tabelle zum Vergleich der beiden Typen finden Sie unter Hilfedokumentation zu öffentlichen IP-Adressen.
Eine öffentliche IP-Adresse wird zur Identität Ihres Dienstes für Clients, die den DNS-FQDN nicht verwenden können. Mit einer reservierten öffentlichen IP-Adresse können Sie diese Identität unabhängig von Änderungen an den zugrunde liegenden Ressourcen beibehalten. Im Folgenden sind einige spezifische Szenarien aufgeführt, die von der Verwendung einer reservierten öffentlichen IP-Adresse profitieren können:
Sie können jeder (primären oder sekundären) privaten IP-Adresse nur eine reservierte öffentliche IP-Adresse zuweisen. Sie können jedoch jeder VNIC, die an Ihre Instanz angehängt ist, mehrere private IP-Adressen zuweisen. Sie können dann jeder dieser privaten IP-Adressen eine reservierte öffentliche IP-Adresse zuweisen.
Die maximale Anzahl reservierter öffentlicher IP-Adressen, die Sie in Ihrer Tenancy erstellen können, ist begrenzt. Weitere Informationen finden Sie in der Hilfedokumentation zu Servicelimits.
Sie können jeder primären privaten IP-Adresse der VNIC nur eine vorübergehende öffentliche IP-Adresse zuweisen. Sie können jedoch mehrere VNICs erstellen und an Ihre Instanz anhängen. Anschließend können Sie jeder primären IP-Adresse jeder VNIC eine vorübergehende private IP-Adresse zuweisen.
Es gibt eine Begrenzung der maximalen Anzahl von vorübergehenden öffentlichen IP-Adressen, die einer Instanz zugewiesen werden können. Weitere Informationen finden Sie in der Hilfedokumentation zu Servicelimits.
Ja, aber nur wenn sie einem zweiten privaten IP auf einer VNIC zugewiesen ist. Wenn Sie diese sekundäre private IP auf eine andere VNIC verschieben (die sich im selben Subnetz befinden muss), gilt dies auch für das vorübergehende öffentliche IP.
Ja, und Sie können sie unter Verfügbarkeitsdomänen oder VCNs verschieben. Die VCNs müssen sich in derselben Region befinden.
Es gibt zwei Möglichkeiten, ein reserviertes öffentliches IP zu verschieben:
Beachten Sie, dass der Neustart der Instanz keine Auswirkungen auf die entsprechenden vorübergehenden öffentlichen IP-Adressen hat.
Sie sehen nur die private IP-Adresse Ihrer Compute-Instanz. Wenn der Instanz eine öffentliche IP-Adresse zugewiesen wurde, stellt der Netzwerkdienst eine 1:1-NAT (statische NAT) zwischen der privaten und der öffentlichen IP-Adresse bereit, wenn die Instanz versucht, mit einem Ziel im Internet (über das Internet-Gateway) zu kommunizieren.
Auf der Betriebssystemebene der Instanz wird nur die private IP-Adresse der VNIC angezeigt, die an die Instanz angehängt ist. Wenn an die öffentliche IP-Adresse gesendeter Datenverkehr empfangen wird, führt der Netzwerkdienst eine Netzwerkadressübersetzung (NAT) von der öffentlichen IP-Adresse zur entsprechenden privaten IP-Adresse durch. Der Datenverkehr wird in Ihrer Instanz mit der Ziel-IP-Adresse angezeigt, die auf die private IP-Adresse festgelegt ist.
Nein. Der Netzwerkdienst weist die MAC-Adresse zu.
Ja. IPv6-Support Weitere Informationen finden Sie unter IPv6-Adressen.
Nein, derzeit nicht.
Nein, derzeit nicht.
Mit Bring your own IP (BYOIP) können Sie öffentlich routbare IPv4 CIDR-Blöcke in Oracle Cloud Infrastructure importieren, damit Ihre Ressourcen sie verwenden können.
IP-Adressen sind Assets, die von einer Firma sorgfältig verwaltet und kontrolliert werden. Einige Anwendungen erfordern eine starke IP-Reputation für das Senden von E-Mails, andere Anwendungen haben Zugriffsrichtlinien globalen Bereitstellungen festgelegt und einige Anwendungen haben Architektur-Regeln in ihren IP-Adressen. Durch die Migration eines IP-Präfixes von einer On-Premises-Infrastruktur zu OCI können Sie die Auswirkungen auf Ihre Kunden und Anwendungen minimieren und gleichzeitig alle Vorteile von Oracle Cloud Infrastructure nutzen. Mit BYOIP in OCI können Sie Ausfallzeiten während der Migration minimieren, indem Sie gleichzeitig Ihr IP-Adresspräfix von OCI bekannt geben und es aus der On-Premises-Umgebung entfernen.
Der Vorgang zum Verschieben eines IP-Präfixes zur Verwendung in OCI beginnt im Portal unter Netzwerk>IP-Verwaltung oder kann über die API initiiert werden. Es sind nur ein paar einfache Schritte.
1 – Initiieren Sie die Anforderung, ein IP-CIDR nach OCI zu verschieben (das IP-CIDR muss ein /24 oder größer sein, das von Ihrem Unternehmen gesteuert wird).
2 – Registrieren Sie ein Validierungstoken, das über eine Anfrage beim regionalen Internet-Registry (RIR)-Service (ARIN, RIPE oder APNIC) erstellt wurde. Folgen Sie den Schritten in der Dokumentation.
3 – Nachdem Sie Ihr Token registriert haben, kehren Sie zur Konsole zurück und klicken auf „CIDR-Block validieren“, damit Oracle den Validierungsprozess abschließen kann. Oracle überprüft, ob Ihr CIDR-Block für die Übertragung ordnungsgemäß registriert wurde, und stellt Ihr BYOIP bereit. Dieser Schritt kann bis zu 10 Werktage dauern. Sie werden per E-Mail benachrichtigt, wenn der Vorgang abgeschlossen ist. Sie können den Fortschritt dieses Prozesses auch in Ihren Arbeitsanforderungen überprüfen.
Was tun mit dem von Oracle ausgegebenen Validierungstoken? Beim Importieren eines BYOIP-CIDR-Blocks gibt Oracle ein Validierungstoken aus. Sobald Sie Ihr Token haben, müssen Sie es leicht ändern und die unten gezeigten Informationen hinzufügen. Sie können einen beliebigen Texteditor verwenden.
OCITOKEN:: <CIDRblock> : <validation_token>
So senden Sie das Validierungstoken an Ihr RIR (Regionales Internet-Register).
ARIN: Fügen Sie die geänderte Token-Zeichenfolge im Abschnitt „Öffentliche Kommentare“ für Ihren Adressbereich hinzu. Fügen Sie es nicht zum Kommentarbereich für Ihre Firma hinzu.
RIPE: Fügen Sie die geänderte Token-Zeichenfolge als neues „descr“-Feld für Ihren Adressbereich hinzu. Fügen Sie es nicht zum Kommentarbereich für Ihre Firma hinzu.
APNIC: Fügen Sie es dem Feld „Bemerkungen“ für Ihren Adressbereich hinzu, indem Sie die geänderte Token-Zeichenfolge per E-Mail an helpdesk@apnic.net senden. Senden Sie die E-Mail über den von APNIC autorisierten Kontakt für die IP-Adressen.
Nach der Validierung des IP-CIDR haben Sie die volle Kontrolle über den IP-CIDR. Verwalten Sie das Präfix, indem Sie es in kleinere IP-Pools aufteilen und reservierte IP-Adressen für die Verwendung mit Ihren Ressourcen erstellen.
Sie können Compute-, NAT Gateway- und LBaaS-Instanzen BYOIP-Adressen zuweisen. Sie können den IP-Speicher über IP-Pools verwalten und reservierte IP-Adressen erstellen.
Sobald das IP-Präfix in OCI integriert ist, steuern Sie die Anzeige und das Zurückziehen des Präfixes.
Die BYOIP-Validierung und -Bereitstellung kann bis zu 10 Arbeitstage dauern. Sie werden per E-Mail benachrichtigt, wenn der Vorgang abgeschlossen ist.
Nein. Das BYOIP-Präfix ist einer bestimmten OCI-Region zugeordnet und wird nur in der Region angezeigt, in der es eingebunden ist.
Das minimale Präfix für BYOIP ist ein /24 und das maximale Präfix ist ein /8. Sie müssen nicht Ihren gesamten IP-Speicherplatz in OCI integrieren. Wenn Sie einen größeren IP-Block besitzen, können Sie auswählen, welche Präfixe in OCI integriert werden sollen.
Nachdem das Präfix integriert wurde, steuern Sie die Verteilung von Adressen und Richtlinien innerhalb Ihres OCI-Mandanten. Sie können das Präfix in einem IP-Pool behalten oder das Präfix zur Verwendung mit Ihren OCI-Ressourcen auf /28 verteilen.
Ja. Sie können reservierte IP-Adressen aus einem BYOIP-Präfix erstellen. Weitere Informationen finden hier unter„IP-Adressierung“: https://www.oracle.com/cloud/networking/virtual-cloud-network-faq.html
Die BYOIP-Funktion unterstützt nur IPv4-Präfixe.
Ja. Sie können weiterhin Oracle-eigene flüchtige und reservierte IP-Adressen zusammen mit Ihren eigenen IP-Adressen verwenden. Standardlimits gelten für Oracle Adressen.
Die Instanzen können eine Verbindung herstellen zu:
Ein Internet-Gateway ist ein softwaredefinierter, hochverfügbarer, fehlertoleranter Router, der eine öffentliche Internetverbindung für Ressourcen in Ihrem VCN bereitstellt. Über ein Internet-Gateway kann eine Compute-Instanz mit einer zugewiesenen öffentlichen IP-Adresse mit Hosts und Diensten im Internet kommunizieren.
Anstatt ein Internet-Gateway zu verwenden, können Sie Ihr VCN mit Ihrem On-Premise Rechenzentrum verbinden, von dem aus Sie den Datenverkehr über Ihre vorhandenen Netzwerkausgangspunkte ins Internet leiten können.
Ein NAT-Gateway ist ein zuverlässiger und hochverfügbarer Router, der ausschließlich ausgehende Internetverbindungen für Ressourcen in Ihrem VCN bereitstellt. Mit einem NAT-Gateway können private Instanzen (nur mit einer privaten IP-Adresse) Verbindungen zu Hosts und Diensten im Internet initiieren, jedoch keine eingehenden Verbindungen empfangen, die über das Internet initiiert wurden.
Nein. Die Standardbeschränkungen ist ein NAT-Gateway pro VCN. Wir gehen davon aus, dass dies für die meisten Anwendungen ausreicht.
Wenn Sie mehr als ein NAT-Gateway in einem bestimmten VCN zuweisen möchten, fordern Sie eine Limiterhöhung an. Anweisungen zum Anfordern einer Limiterhöhung finden Sie unter Service-Limits.
Instanzen erhalten mit dem NAT-Gateway den gleichen Durchsatz wie beim Routing des Datenverkehrs über ein Internet-Gateway. Darüber hinaus ist ein einzelner Datenverkehrsfluss durch das NAT-Gateway auf 1 Gbit/s (oder weniger für kleine Instanzausprägungen) beschränkt.
Ja. Es gibt eine Beschränkung von ungefähr 20.000 gleichzeitigen Verbindungen zu einer einzelnen Ziel-IP-Adresse und einem Port. Dieses Limit ist die Summe aller Verbindungen, die von Instanzen im gesamten VCN initiiert wurden, die das NAT-Gateway verwenden.
Ein dynamisches Routing-Gateway ist ein softwaredefinierter, hochverfügbarer, fehlertoleranter Router, den Sie einem VCN hinzufügen können. Es bietet einen privaten Pfad für den Datenverkehr zwischen dem VCN und anderen Netzwerken außerhalb der Region des VCN, z. B. Ihrem On-Premises-Rechenzentrum oder einem gleichrangigen VCN in einer anderen Region. Um Ihr VCN mit Ihrem On-Premises-Rechenzentrum zu verbinden, können Sie ein IPSec-VPN oder FastConnect zum DRG des VCN einrichten. Die Verbindung ermöglicht Ihren On-Premises-Hosts und -Instanzen eine sichere Kommunikation.
Sie verwenden dieses Objekt, wenn Sie ein IPSec-VPN einrichten. Es ist eine virtuelle Darstellung des eigentlichen Routers, der sich On-Premises an Ihrem Standort am Ende des VPN befindet. Wenn Sie dieses Objekt im Rahmen der Einrichtung eines IPSec-VPN erstellen, geben Sie die öffentliche IP-Adresse Ihres On-Premises-Routers an.
Nein. Sie müssen lediglich ein DRG bereitstellen, dieses an Ihr VCN anhängen, das CPE-Objekt und die IPSec-Verbindung sowie die Routentabellen konfigurieren.
Siehe die Liste der getesteten Gerätekonfigurationen.
Ja. Wenn Sie ihn entsprechend der allgemeinen CPE-Konfigurationsinformationen konfigurieren. Wir unterstützen mehrere Konfigurationsoptionen, um die Interoperabilität mit verschiedenen VPN-Geräten zu maximieren.
Oracle stellt zwei VPN-Tunnel als Teil der IPSec-Verbindung bereit. Stellen Sie sicher, dass Sie beide Tunnel aus Gründen der Redundanz auf Ihrem CPE konfigurieren.
Darüber hinaus können Sie in Ihrem On-Premises-Rechenzentrum zwei CPE-Router bereitstellen, die jeweils für beide Tunnel konfiguriert sind.
IPSec VPN ist ein offener Standard und Software-IPSec-VPNs können mit Oracle Cloud Infrastructure zusammenarbeiten. Sie müssen sicherstellen, dass Ihr Software-IPSec-VPN mindestens einen unterstützten Oracle IPSec-Parameter in jeder Konfigurationsgruppe gemäß den allgemeinen CPE-Konfigurationsinformationen unterstützt.
Ja. Der Datenverkehr zwischen zwei öffentlichen OCI-IP-Adressen in derselben Region bleibt innerhalb der OCI-Region. Der Datenverkehr zwischen öffentlichen OCI-IP-Adressen in verschiedenen Regionen wird über den privaten OCI-Backbone übertragen. In beiden Fällen wird der Datenverkehr nicht durch das Internet geleitet. Die vollständige Liste der öffentlichen OCI-IP-Adressen finden Sie hier: https://docs.cloud.oracle.com/en-us/iaas/tools/public_ip_ranges.json.
Das Oracle Services Network ist ein konzeptionelles Netzwerk in Oracle Cloud Infrastructure, das für Oracle Services reserviert ist. Das Netzwerk umfasst eine Liste regionaler CIDR-Blöcke. Jeder Service im Oracle Services Network macht einen Service-Endpunkt verfügbar, der öffentliche IP-Adressen aus dem Netzwerk nutzt. Derzeit ist in diesem Netzwerk eine große Anzahl von Oracle Services verfügbar (siehe die vollständige Liste ) und in Zukunft werden weitere Services hinzugefügt, sobald sie auf Oracle Cloud Infrastructure bereitgestellt werden.
Über ein Service-Gateway können Ressourcen in Ihrem VCN privat und sicher auf Oracle Services im Oracle Services Network zugreifen, z. B. auf Oracle Cloud Infrastructure Object Storage, ADW und ATP. Der Datenverkehr zwischen einer Instanz im VCN und einem unterstützten Oracle Service nutzt die private IP-Adresse der Instanz zum Routing, wird über die Oracle Cloud Infrastructure-Struktur übertragen und durchläuft niemals das Internet. Ähnlich wie das Internet-Gateway oder das NAT-Gateway ist das Service-Gateway ein virtuelles Gerät, das hochverfügbar ist und sich dynamisch skalieren lässt, um die Netzwerkbandbreite Ihres VCN zu unterstützen.
Derzeit können Sie das Service-Gateway so konfigurieren, dass es auf die Oracle Services im Oracle Services Network zugreift. Derzeit ist in diesem Netzwerk eine große Anzahl von Oracle Services verfügbar (siehe die vollständige Liste ) und in Zukunft werden weitere Services hinzugefügt, sobald sie auf Oracle Cloud Infrastructure bereitgestellt werden.
Eine Anleitung finden Sie unter Zugriff auf Objektspeicher: Servicegateway. Bitte beachten Sie, dass das Service-Gateway den Zugriff auf Oracle Services in Ihrer Region ermöglicht, um Ihre Daten vor dem Internet zu schützen. Ihre Anwendungen erfordern möglicherweise Zugriff auf öffentliche Endpunkte oder Services, die vom Service-Gateway nicht unterstützt werden, z. B. Updates oder Patches. Stellen Sie bei Bedarf sicher, dass Sie über ein NAT-Gateway oder einen anderen Zugriff auf das Internet verfügen.
Das Service-Gateway verwendet das Konzept einer Service-CIDR-Kennzeichnung. Hierbei handelt es sich um eine Zeichenfolge, die alle regionalen öffentlichen IP-Adressbereiche für den Service oder eine Gruppe von Services darstellt (z. B. ist OCI IAD Services in Oracle Services Network die Kennzeichnung, die den regionalen CIDR-Blöcken im Oracle Services Network in us-ashburn-1 zugeordnet wird). Sie verwenden die Service-CIDR-Kennzeichnung, wenn Sie das Service-Gateway und die Routen-/Sicherheitsregeln konfigurieren. Eine Anleitung finden Sie unter Zugriff auf Oracle Services: Servicegateway.
Nein. Das Service-Gateway ist regional und kann nur auf Services zugreifen, die in derselben Region ausgeführt werden.
Ja. Wenn Sie ein Service-Gateway verwenden, können Sie eine IAM-Richtlinie definieren, die den Zugriff auf einen Bucket nur dann ermöglicht, wenn die Anfragen von einem bestimmten VCN- oder CIDR-Bereich stammen. Die IAM-Richtlinie funktioniert nur für Datenverkehr, der über das Service-Gateway weitergeleitet wird. Der Zugriff wird blockiert, wenn die IAM-Richtlinie gilt und der Datenverkehr stattdessen ein Internet-Gateway durchläuft. Beachten Sie auch, dass die IAM-Richtlinie Sie daran hindert, durch die Konsole auf den Bucket zuzugreifen. Der Zugriff ist nur programmgesteuert über Ressourcen im VCN zulässig.
Ein Beispiel für eine IAM-Policy finden Sie unter Zugriff auf Object Storage: Servicegateway.
Nein. Ein VCN kann zu diesem Zeitpunkt nur ein Service-Gateway haben.
Nein. Ein VCN, das mit einem anderen VCN mit einem Service-Gateway verbunden wird, kann dieses Service-Gateway nicht für den Zugriff auf Oracle Services verwenden.
Nein. Sie können dazu jedoch das öffentliche FastConnect-Peering verwenden (ohne über das Internet zu gehen).
Nein. Instanzen erhalten mit dem Service-Gateway den gleichen Durchsatz wie beim Routing des Datenverkehrs über ein Internet-Gateway.
Das Service-Gateway ist für alle Oracle Cloud Infrastructure-Kunden kostenlos.
Eine Sicherheitsliste bietet eine virtuelle Firewall für eine Instanz mit Eingangs- und Ausgangsregeln, die die Arten des Datenverkehrs festlegen, der in die Instanz und aus der Instanz zugelassen wird. Sie können Ihre Compute-Instanz mithilfe von Sicherheitslisten sichern. Sie konfigurieren Ihre Sicherheitslisten auf der Subnetzebene. Das bedeutet, dass alle Instanzen im Subnetz denselben Sicherheitslistenregeln unterliegen. Die Regeln werden auf der Instanzebene durchgesetzt und steuern den Datenverkehr auf der Paketebene.
Eine bestimmte VNIC in einer Instanz unterliegt den Sicherheitslisten, die dem Subnetz der VNIC zugeordnet sind. Wenn Sie ein Subnetz erstellen, geben Sie eine oder mehrere Sicherheitslisten an, die mit dem Subnetz verknüpft werden sollen. Hierzu kann die Standardsicherheitsliste des VCN gehören. Wenn Sie während der Subnetzerstellung nicht mindestens eine Sicherheitsliste angeben, wird die Standardsicherheitsliste des VCN dem Subnetz zugeordnet. Die Sicherheitslisten werden auf Subnetzebene zugeordnet, die Regeln gelten jedoch für den Datenverkehr der VNIC auf Paketebene.
Ja. Sie können Subnetz-Eigenschaften bearbeiten, um Sicherheitslisten hinzuzufügen oder zu entfernen. Sie können auch die einzelnen Regeln in einer Sicherheitsliste bearbeiten.
Die Anzahl der Sicherheitslisten, die Sie erstellen können, die Anzahl der Listen, die Sie einem Subnetz zuordnen können, und die Anzahl der Regeln, die Sie einer bestimmten Liste hinzufügen können, sind begrenzt. Weitere Informationen zu den Standardbeschränkungen und Anweisungen zum Anfordern einer Service-Limit-Erhöhung finden Sie in der Hilfe-Dokumentation zu den Service-Limits.
Nein. Sicherheitslisten verwenden nur Zulassungsregeln. Der gesamte Datenverkehr wird standardmäßig abgelehnt. Nur Netzwerkdatenverkehr, der den in den Regeln angegebenen Attributen entspricht, ist zulässig.
Jede Regel ist entweder zustandsbehaftet oder zustandslos und entweder eine Eingangsregel oder eine Ausgangsregel.
Bei statusbehafteten Regeln wird nach dem Zulassen eines Netzwerkpakets, das der Regel entspricht, die Verbindungsnachverfolgung verwendet. Alle weiteren Netzwerkpakete, die zu dieser Verbindung gehören, werden dann automatisch zugelassen. Wenn Sie also eine statusbehaftete Eingangsregel erstellen, sind sowohl eingehender Datenverkehr, der mit der Regel übereinstimmt, als auch der entsprechende ausgehende (Antwort-) Datenverkehr zulässig.
Bei zustandslosen Regeln sind nur die Netzwerkpakete zulässig, die mit der Regel übereinstimmen. Wenn Sie also eine zustandslose Eingangsregel erstellen, ist nur der eingehende Datenverkehr zulässig. Sie müssen eine entsprechende zustandslose Ausgangsregel erstellen, die dem entsprechenden ausgehenden (Antwort-) Datenverkehr entspricht.
Weitere Informationen finden Sie in der Support-Dokumentation zu Sicherheitslisten.
Netzwerk-Sicherheitsgruppen und -Sicherheitslisten sind zwei verschiedene Methoden zum Implementieren von Sicherheitsregeln. Diese Regeln steuern den ein- und ausgehenden Datenverkehr zu und von VNICs.
Mit Sicherheitslisten können Sie eine Reihe von Sicherheitsregeln definieren, die für alle VNICs in einem bestimmten Subnetz gelten. Mit Netzwerksicherheitsgruppen (NSGs) können Sie eine Reihe von Sicherheitsregeln definieren, die für eine Gruppe von VNICs Ihrer Wahl gelten. Zum Beispiel: eine Gruppe von Compute-Instanzen mit derselben Sicherheitslage.
Weitere Informationen finden Sie unter:
Nein. Standardmäßig wird der gesamte Datenverkehr abgelehnt. Nur Sicherheitsregeln lassen Datenverkehr zu. Die Regeln, die für eine bestimmte VNIC gelten, ist die Kombination der folgenden Elemente:
Compute-, Lastausgleichs- und Datenbankservices. Dies bedeutet, dass Sie beim Erstellen einer Compute-Instanz, eines Load Balancer oder eines Datenbanksystems eine oder mehrere Netzwerk-Sicherheitsgruppen angeben können, um den Datenverkehr für diese Ressourcen zu steuern.
Mit der Einführung von NSGs ändert sich nichts am Verhalten der Sicherheitsliste. Ihr VCN verfügt weiterhin über eine Standardsicherheitsliste, die Sie optional für die Subnetze Ihres VCN verwenden können.
Wenn Sie Regeln für eine NSG schreiben, können Sie eine NSG als Quelle des Datenverkehrs (für Eingangsregeln) oder als Ziel des Datenverkehrs (für Ausgangsregeln) angeben. Die Möglichkeit, eine NSG anzugeben, bedeutet, dass Sie auf einfache Weise Regeln schreiben können, um den Datenverkehr zwischen zwei verschiedenen NSGs zu steuern. Die NSGs müssen sich in demselben VCN befinden.
Nein. Wenn Sie eine NSG-Sicherheitsregel schreiben, die eine andere NSG als Quelle oder Ziel angibt, muss sich diese NSG in demselben VCN befinden. Dies gilt auch dann, wenn sich die andere NSG in einer von der Sicherheitsliste abweichenden VCN befindet.
Mit Sicherheitslisten können Sie eine Reihe von Sicherheitsregeln definieren, die für alle VNICs in einem vollständigen Subnetz gelten. Mit Netzwerk-Sicherheitsgruppen (NSGs) können Sie eine Reihe von Sicherheitsregeln definieren, die für eine Gruppe von VNICs Ihrer Wahl (einschließlich der VNICs von Load Balancers oder Datenbanksystemen) innerhalb eines VCN gelten.
Eine VCN-Routingtabelle enthält Regeln zum Weiterleiten von Datenverkehr, der letztendlich für Standorte außerhalb des VCN bestimmt ist.
Jede Regel in einer Routingtabelle hat einen Ziel-CIDR-Block und ein Routenziel. Wenn der ausgehende Datenverkehr des Subnetzes mit dem Ziel-CIDR-Block der Routingregel übereinstimmt, wird der Datenverkehr an das Routing-Ziel weitergeleitet. Beispiele üblicher Routingziele beinhalten: ein Internet-Gateway oder ein dynamisches Routing-Gateway.
Weitere Informationen finden Sie unter Routingtabellen.
Eine bestimmte VNIC in einer Instanz unterliegt den Routingtabellen, die dem Subnetz der VNIC zugeordnet sind. Wenn Sie ein Subnetz erstellen, geben Sie eine Routingtabelle an, die mit dem Subnetz verknüpft werden soll. Dies kann die Standardroutingtabelle des VCN oder eine andere sein, die Sie bereits erstellt haben. Wenn Sie während der Subnetzerstellung keine Routingtabelle angeben, wird die Standardroutingtabelle des VCN dem Subnetz zugeordnet. Die Routingtabelle wird auf Subnetzebene zugeordnet, die Regeln gelten jedoch für den Datenverkehr der VNIC auf Paketebene.
Nein. Derzeit können Sie eine Routingregel nur für einen CIDR-Block hinzufügen, der sich nicht mit dem Adressraum des VCN überschneidet.
Ja. Sie können Subnetzeigenschaften bearbeiten, um die Routingtabelle zu ändern. Sie können auch die einzelnen Regeln in einer Routingtabelle bearbeiten.
Nein, derzeit nicht.
Die Anzahl der Regeln in einer Routingtabelle ist begrenzt. Weitere Informationen finden Sie in der Hilfedokumentation zu Servicelimits.
Ja. Sie können eine private IP als Ziel einer Routingregel in Situationen verwenden, in denen Sie den Datenverkehr eines Subnetzes an eine andere Instanz im gleichen VCN weiterleiten möchten. Anforderungen und weitere Details finden Sie unter Verwenden einer privaten IP als Routingziel.
Beim VCN-Peering werden zwei VCNs verbunden, um die private Konnektivität und den Datenverkehrsfluss zwischen ihnen zu ermöglichen. Es gibt zwei allgemeine Peering-Typen:
Weitere Informationen finden Sie unter Zugriff auf andere VCNs: Peering.
Anweisungen finden Sie unter Lokales VCN-Peering.
Nein. Die beiden VCNs in einer lokalen Peering-Beziehung dürfen keine überlappenden CIDRs aufweisen.
Ja. Wenn VCN-1 mit zwei anderen VCNs (z. B. VCN-2 und VCN-3) verbunden wird, können diese beiden VCNs (VCN-2 und VCN-3) überlappende CIDRs aufweisen.
Ja.
Ein bestimmtes VCN kann maximal zehn lokale Peerings gleichzeitig aufweisen.
Nein. Sie stellen eine Remote-Peering-Verbindung mithilfe eines dynamischen Routing-Gateways (DRG) her.
Anweisungen finden Sie unter Remote-VCN-Peering.
Nein. Die beiden VCNs in einer Remote-Peering-Beziehung dürfen keine überlappenden CIDRs aufweisen.
Nein. Wenn VCN-1 mit zwei anderen VCNs (z. B. VCN-2 und VCN-3) remote verbunden wird, können diese beiden VCNs (VCN-2 und VCN-3) keine überlappenden CIDRs aufweisen.
Nein.
Ja. Ihr Remote-VCN-Peering-Datenverkehr wird mit der branchenüblichen Verbindungsverschlüsselung verschlüsselt.
Ein bestimmtes VCN kann maximal zehn Remote-Peerings gleichzeitig aufweisen.
Ja. Sie können die Routingtabellen und Sicherheitslisten von VCN-A verwenden, um die Konnektivität mit dem gleichrangigen VCN-B zu steuern. Sie können die Konnektivität für den gesamten Adressbereich von VCN-B zulassen oder auf ein oder mehrere Subnetze beschränken.
Ja. Nachdem das lokale oder Remote-Peering eingerichtet wurde, können die Instanzen in VCN-B Datenverkehr an den gesamten Adressbereich von VCN-A senden. Sie können jedoch den Zugriff von Instanzen in VCN-B auf ein bestimmtes Subnetz in VCN-A einschränken, indem Sie die entsprechenden Eingangsregeln in den Sicherheitslisten des Subnetzes verwenden.
Nein. Durchsatz und Latenz sollten ähnlich der intraregionalen VCN-Verbindungen liegen. Der Datenverkehr über das lokale Peering unterliegt ähnlichen Verfügbarkeits- und Bandbreitenbeschränkungen wie der Datenverkehr zwischen Instanzen in einem VCN.
Remote-VCN-Peering nutzt den interregionalen Oracle Cloud Infrastructure-Backbone, der überlegene Performance- und Verfügbarkeitsmerkmale sowie eine Verfügbarkeits-SLA von 99,5% für die interregionale Konnektivität bietet. Als Richtschnur gilt, dass Oracle einen Durchsatz von mehr als 75 Mbit/s und eine Latenz von weniger als 60 ms zwischen US-Regionen, 80 ms zwischen der EU und den USA, 175 ms zwischen den USA und APAC und 275 ms zwischen EU und APAC bietet.
Die VTR-Lösung (VCN-Transit-Routing) basiert auf einer Hub-and-Spoke-Topologie und ermöglicht es dem Hub-VCN, Transitkonnektivität zwischen VCNs mit mehreren Spokes (innerhalb der Region) und On-Premises-Netzwerken bereitzustellen. Für die Kommunikation mit allen Spoke-VCNs ist nur ein einziges FastConnect- oder IPSec-VPN (verbunden mit dem Hub-VCN) erforderlich.
Anweisungen finden Sie unter Einrichten von VCN-Transit-Routing in der Konsole.
Derzeit können die Spoke-VCNs über das Hub-VCN auf Ihre On-Premises-Netzwerke zugreifen.
Nein. Die Lösung VCN-Transit-Routing unterstützt nur die konsolidierte Konnektivität zwischen VCNs in derselben Region.
Ja. Sie steuern dies mit der Routingtabelle, die dem LPG auf dem Hub-VCN zugeordnet ist. Sie können restriktive Routingregeln konfigurieren, die nur die On-Premises-Subnetze angeben, die Sie dem Spoke-VCN zur Verfügung stellen möchten. Die dem Spoke-VCN angezeigten Routen entsprechen denen in dieser Routingtabelle und des CIDR des Hub-VCN.
Ja. Sie steuern dies mit der Routingtabelle, die dem DRG auf dem Hub-VCN zugeordnet ist. Sie können restriktive Routingregeln konfigurieren, die nur die Spoke-VCN-Subnetze angeben, die Sie dem On-Premises-Netzwerk zur Verfügung stellen möchten. Die im On-Premises-Netzwerk angezeigten Routen entsprechen den Routen in dieser Routingtabelle und im CIDR des Hub-VCN.
Ja. Das Hub-VCN ist auf maximal 10 lokale Peerings mit Spoke-VCNs beschränkt.
Ja. Sie können einem VCN, das über FastConnect oder Site-to-Site-VPN mit Ihrem On-Premises-Netzwerk verbunden ist, ein Service-Gateway hinzufügen. Anschließend können Sie Routingregeln in den Routingtabellen konfigurieren, die mit dem DRG und dem Service-Gateway des VCN verknüpft sind, um den On-Premises-Datenverkehr durch das VCN zu den relevanten Oracle Services leiten. Ihre On-Premises-Hosts können ihre privaten IP-Adressen für die Kommunikation mit den Oracle Services verwenden und der Datenverkehr wird nicht über das Internet übertragen.
Weitere Informationen finden Sie unter Transitrouting: Privater Zugriff auf Oracle Services.
Ja. Sie können das Transit-Routing über eine private IP im Hub-VCN einrichten. In diesem Fall leiten Sie den Datenverkehr an ein privates IP in der Firewall-Instanz im Hub-VCN weiter. Die Firewall-Instanz kann den gesamten Datenverkehr zwischen Ihrem On-Premises-Netzwerk und den Spoke-VCNs überprüfen.
Wenn Sie das Routing über eine Firewall-Instanz (oder eine andere virtuelle Netzwerk-Appliance) im Hub-VCN ausführen, basieren die Performance-Limits auf den E/A-Eigenschaften der virtuellen Netzwerk-Appliance. Wenn Sie den Datenverkehr nicht über eine virtuelle Netzwerk-Appliance weiterleiten, sondern direkt über die Gateways des Hub-VCN, gibt es keine Performance-Limits. Die Gateways sind virtuelle Geräte, die hochverfügbar sind und dynamisch skaliert werden, um die Bandbreitenanforderungen Ihres Netzwerks zu unterstützen.
Das Dynamic Host Configuration Protocol (DHCP) bietet ein Framework für die Weitergabe von Konfigurationsinformationen an Hosts in einem IP-Netzwerk. Konfigurationsparameter und andere Steuerungsinformationen werden an die Instanz im Optionsfeld ( RFC 2132) der DHCP-Nachricht übertragen. Jedem Subnetz in einem VCN kann ein einzelner Satz von DHCP-Optionen zugeordnet sein.
Sie können zwei Optionen konfigurieren, die steuern, wie Instanzen in Ihrem VCN DNS-Hostnamen (Domain Name System) auflösen:
Beim Auflösen einer DNS-Abfrage verwendet das Betriebssystem der Instanz die mit DNS-Typ angegebenen DNS-Server und fügt die Suchdomäne an den abgefragten Wert an. Weitere Informationen finden Sie unter DHCP-Optionen.
Ja. Sie können die Subnetz-Eigenschaften bearbeiten, um die vom Subnetz verwendeten DHCP-Optionen zu ändern. Sie können auch die Werte der DHCP-Optionen ändern.
Wenn Sie eine Instanz starten, können Sie einen Hostnamen für die Instanz zusammen mit einem Anzeigenamen angeben. Dieser Hostname wird in Kombination mit dem Domänennamen des Subnetzes zum vollqualifizierten Domänennamen (FQDN) Ihrer Instanz. Dieser FQDN ist innerhalb des VCN eindeutig und wird in die private IP-Adresse Ihrer Instanz aufgelöst. Weitere Informationen finden Sie unter DNS in Ihrem virtuellen Cloud-Netzwerk.
Beachten Sie, dass zur Angabe eines Hostnamens für die Instanz das VCN und Subnetz so konfiguriert sein müssen, dass DNS-Hostnamen aktiviert werden können.
Wenn Sie ein VCN erstellen, können Sie dessen DNS-Bezeichnung angeben. Dies wird in Kombination mit der übergeordneten Domäne oraclevcn.com zum Domänennamen des VCN.
Wenn Sie ein Subnetz erstellen, können Sie dessen DNS-Bezeichnung angeben. In Kombination mit dem Domänennamen des VCN wird diese zum Domänennamen des Subnetzes.
Sie können einen Hostnamen für eine Computerinstanz nur aktivieren, wenn sowohl das VCN als auch das Subnetz mit einer DNS-Bezeichnung erstellt wurden.
Ein DNS-Hostname ist ein Name, der der IP-Adresse einer mit einem Netzwerk verbundenen Instanz entspricht. Bei einem VCN von Oracle Cloud Infrastructure kann jede Instanz mit einem DNS-Hostnamen konfiguriert werden, der der privaten Adresse der Instanz entspricht.
Ein vollqualifizierter Domainname (FQDN) einer Instanz sieht wie folgt aus: hostname.subnetdnslabel.vcndnslabel.oraclevcn.com, wobei Hostname der DNS-Hostname der Instanz ist. Subnetdnslabel und vcndnslabel sind die DNS-Labels des Subnetzes der Instanz bzw. des VCN.
Die übergeordnete Domäne oraclevcn.com ist für die Verwendung mit DNS-Hostnamen reserviert, die in Oracle Cloud Infrastructure erstellt wurden.
Ja.
Nein.
Ja. DNS-Hostnamen werden für Instanzen unabhängig vom für das Subnetz ausgewählten DNS-Typ erstellt.
Nein. Die Instanz kann nur Hostnamen von Instanzen innerhalb desselben VCN auflösen.
Ja, dies ist mit benutzerdefinierten DNS-Servern möglich, die im VCN eingerichtet sind. Sie können die benutzerdefinierten DNS-Server so konfigurieren, dass sie 169.254.169.254 als Weiterleitung für die VCN-Domain (wie contoso.oraclevcn.com) verwenden.
Beachten Sie, dass die benutzerdefinierten DNS-Server in einem Subnetz konfiguriert werden müssen, das "Internet und VCN-Resolver" als DNS-Typ verwendet (um den Zugriff auf die IP-Adresse 169.254.169.254 zu ermöglichen).
Ein Beispiel für eine Implementierung mit dem Oracle Terraform-Anbieter finden Sie unter "Hybrid-DNS-Konfiguration".
Das Erstellen und Verwenden von VCNs ist kostenlos. Es fallen jedoch Nutzungsgebühren für andere Oracle Cloud Infrastructure-Dienste (einschließlich Compute- und Blockvolumes) und Datenübertragungsgebühren zu den veröffentlichten Tarifen an. Für die Kommunikation zwischen Ressourcen innerhalb eines VCN fallen keine Datenübertragungsgebühren an.
Ihnen werden nur die veröffentlichten ausgehenden Datenübertragungsraten in Oracle Cloud Infrastructure berechnet. Es gibt keine stündliche oder monatliche VPN-Verbindungsgebühr.
Beim Zugriff auf andere öffentliche Oracle Cloud Infrastructure-Dienste wie z. B. Object Storage in derselben Region fallen keine Datenübertragungsgebühren an. Der gesamte Netzwerkverkehr über private oder öffentliche IP-Adressen zwischen Ihren Instanzen und anderen Ressourcen in Ihrem VCN, z. B. einer Datenbank oder einem Load Balancer, ist kostenlos.
Wenn Sie über Ihr IPSec-VPN von Ihrem VCN aus auf öffentliche Oracle Cloud Infrastructure-Ressourcen zugreifen, fallen die veröffentlichten Gebühren für die ausgehende Datenübertragung an.
Sofern nicht anders angegeben, enthalten die Oracle Cloud Infrastructure-Preise sowie die Gebühren für die ausgehende Datenübertragung, keine Steuern und Abgaben, einschließlich Mehrwertsteuer und etwaiger anfallender Umsatzsteuern.