Oracle Cloud Infrastructure - Dokumentation

Zugriff auf andere VCNs: Peering

Beim VCN-Peering werden viele virtuelle Cloud-Netzwerke (VCNs) miteinander verbunden. Vier Typen von VCN-Peering sind verfügbar:

Mit dem VCN-Peering können Sie ein großes Netzwerk in verschiedene VCNs unterteilen (z.B. basierend auf Abteilungen oder Geschäftsbereichen), wobei jedes VCN direkten, privaten Zugriff auf die anderen VCNs besitzt. Traffic muss nicht über das Internet oder durch ein On-Premise-Netzwerk über ein Site-to-Site-VPN oder FastConnect geleitet werden. Sie können auch gemeinsame Ressourcen in einem einzelnen VCN platzieren, auf die alle anderen VCNs privat zugreifen können.

Jedes VCN kann bis zu 10 lokale Peering-Gateways und ein DRG aufweisen. Ein einzelnes DRG unterstützt bis zu 300 VCN-Anhänge, sodass Traffic zwischen ihnen gemäß den Routentabellen des DRG fließen kann. Wir empfehlen die Verwendung von DRG, wenn Sie eine hohe Anzahl von VCNs in Peer-Umgebungen verwenden müssen. Wenn Sie die höchstmögliche Bandbreite und den Datenverkehr mit extrem geringer Latenz zwischen zwei VCNs in derselben Region wünschen, nutzen Sie das Szenario, das in Lokales VCN-Peering in lokalen Peering-Gateways beschrieben wird. Lokales VCN-Peering über ein upgegradetes DRG bietet Ihnen mehr Flexibilität beim Routing, da die Anzahl der Anhänge größer ist.

Da das Remote-VCN-Peering regionsübergreifend ist, können Sie es beispielsweise verwenden, um Datenbanken in einer Region zu spiegeln oder zu sichern.

Lokales VCN-Peering - Überblick

Beim lokalen VCN-Peering werden zwei VCNs in derselben Region miteinander verbunden, sodass ihre Ressourcen über private IP-Adressen kommunizieren können, ohne dass Traffic über das Internet oder über ein On-Premise-Netzwerk geleitet werden muss. Die VCNs können sich entweder im selben oder in verschiedenen Oracle Cloud Infrastructure-Mandanten befinden. Ohne Peering benötigt ein bestimmter VCN ein Internetgateway und öffentliche IP-Adressen für die Instanzen, die mit einem anderen VCN kommunizieren müssen.

Durch das lokale VCN-Peering über ein upgegradetes DRG erhalten Sie mehr Flexibilität beim Routing und vereinfachte Verwaltung. Es erhöht sich jedoch die Latenz um einen Anstieg der Latenz (durch Mikrosekunden) vom Routing des Traffics über einen virtuellen Router, das DRG.

Wichtige Auswirkungen von Peering

In diesem Abschnitt werden einige Auswirkungen auf die Zugriffskontrolle, Sicherheit und Performance von Peer-VCNs zusammengefasst. Im Allgemeinen können Sie den Zugriff und den Traffic zwischen zwei Peer-VCNs mit IAM-Policys, Routentabellen in jedem VCN und Sicherheitslisten in jedem VCN kontrollieren.

Einrichtung von Peerings kontrollieren

Mit IAM-Policys steuern Sie Folgendes:

Trafficfluss über die Verbindung steuern

Selbst wenn eine Peering-Verbindung zwischen einem VCN und einem anderen hergestellt wurde, können Sie den Paketfluss über die Verbindung mit Routentabellen im VCN steuern. Beispiel: Sie können den Traffic auf bestimmte Subnetze im anderen VCN beschränken.

Ohne Beende des Peerings können Sie den Trafficfluss zum anderen VCN stoppen, indem Sie Routingregeln entfernen, die den Traffic vom VCN zum anderen VCN leiten. Sie können den Traffic auch wirksam stoppen, indem Sie alle Sicherheitslistenregeln entfernen, die den Ingress- oder Egress-Traffic mit dem anderen VCN aktivieren. Dadurch wird der Traffic über die Peering-Verbindung nicht unterbrochen, aber auf der VNIC-Ebene gestoppt.

Weitere Informationen zu Routing- und Sicherheitslisten finden Sie in den Diskussionen in den folgenden Abschnitten:

Lokales VCN-Peering mit lokalen Peering-Gruppen:

Remote-VCN-Peering mit einer Remote-Peering-Verbindung:

Lokales VCN-Peering mit einem dynamischen Routinggateway (DRG):

Remote-VCN-Peering mit einem dynamischen Routinggateway (DRG):

Bestimmte zulässige Traffictypen steuern

Jeder VCN-Administrator stellt sicher, dass der gesamte ausgehende und eingehende Traffic im anderen VCN beabsichtigt oder erwartet und definiert ist. In der Praxis bedeutet dies die Implementierung von Sicherheitslistenregeln, die explizit angeben, welcher Traffictypen die VCN untereinander versenden und akzeptieren können.

Wichtig

Compute-Instanzen, auf denen Plattformimages ausgeführt werden, haben auch BS-Firewallregeln, die den Zugriff auf die Instanz steuern. Bei der Fehlerbehebung des Zugriffs auf eine Instanz stellen Sie sicher, dass die folgenden Elemente korrekt festgelegt sind:

  • Die Regeln in den Netzwerksicherheitsgruppen, in denen sich die Instanz befindet
  • Die Regeln in den Sicherheitslisten, die dem Subnetz der Instanz zugeordnet sind
  • Die Firewallregeln des Betriebssystems der Instanz

Wenn auf einer Instanz Oracle Autonomous Linux 8.x, Oracle Autonomous Linux 7, Oracle Linux 8, Oracle Linux 7 oder Oracle Linux Cloud Developer 8 ausgeführt wird, müssen Sie firewalld für die Interaktion mit den iptables-Regeln verwenden. Zu Referenzzwecken sind hier Befehle zum Öffnen eines Ports (in diesem Beispiel 1521) aufgeführt:

sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
								
sudo firewall-cmd --reload

Bei Instanzen mit einem iSCSI-Boot-Volume kann der vorherige --reload-Befehl Probleme verursachen. Weitere Einzelheiten und einen Workaround finden Sie unter Bei den Instanzen hängt das System, nachdem "firewall-cmd --reload" ausgeführt wurde.

Neben Sicherheitslisten und Firewalls sollten sie andere BS-basierte Konfiguration für die Instanzen im lokalen VCN auswerten. Es könnten Standardkonfigurationen vorliegen, die nicht für das CIDR des lokalen VCN gelten, sondern irrtümlich für das CIDR des anderen VCN.

Standardsicherheitslistenregeln verwenden

Wenn das Subnetze des lokalen VCN die Standardsicherheitsliste mit den Standardregeln verwenden, achten Sie darauf, dass zwei Regeln vorhanden sind, mit denen jede Ingress-Traffic von überall zugelassen werden (0.0.0.0/0 und somit vom anderen VCN):

  • Regel für zustandsbehafteten Ingress, die (SSH-)Traffic über den TCP-Port 22 von 0.0.0.0/0 und allen Quellports zulässt
  • Regel für zustandsbehafteten Ingress, die ICMP-Typ-3-Code-4-Traffic von 0.0.0.0/0 und allen Quellports zulässt

Prüfen Sie diese Regeln, und entscheiden Sie, ob Sie sie beibehalten oder aktualisieren möchten. Wie bereits erwähnt, müssen sie sicherstellen, dass der gesamte eingehende oder ausgehende Traffic, den Sie zulassen möchten, beabsichtigt oder erwartet und definiert ist.

Performanceauswirkungen und Sicherheitsrisiken antizipieren

Im Allgemeinen bereiten Sie das lokale VCN entsprechend der allgemeinen möglichen Auswirkungen durch das andere VCN vor. Beispiel: Die Auslastung des lokalen VCN oder seiner Instanzen könnte sich erhöhen. Oder das lokale VCN könnte direkt vom oder über das andere VCN zu einem bösartigen Angriff führen.

Performance: Wenn das lokale VCN einen Service für ein anderes bereitstellt, müssen Sie den Service entsprechend den Anforderungen des anderen VCN vertikal skalieren. Dies kann bedeuten, dass nach Bedarf weitere Compute-Instanzen erstellt werden müssen. Wenn Sie über ein erhöhtes Aufkommen von Netzwerktraffic in Ihrem lokalen VCN besorgt sind, sollten sie die Verwendung von "zustandslosen Sicherheitsregeln in Erwägung ziehen, um das Ausmaß des Verbindungstrackings zu begrenzen, das das lokale VCN ausführen muss. Außerdem können Sicherheitsregeln für zustandslosen Traffic die Auswirkungen eines Denial-of-Service-(DoS-)Angriffs eindämmen.

Sicherheitsrisiken: Sie können nicht unbedingt kontrollieren, ob das andere VCN mit dem Internet verbunden ist. Dadurch könnte das lokale VCN Bounce-Angriffe auslösen, bei denen ein böswilliger Host im Internet Traffic an das lokale VCN sendet, das aussieht, als käme es von dem VCN, mit dem Sie verbunden sind. Um dies zu vermeiden, verwenden Sie wie bereits erwähnt Sicherheitslisten, um eingehenden Traffic vom anderen VCN sorgfältig auf erwarteten und definierten Traffic zu begrenzen.