Oracle Cloud Infrastructure - Dokumentation

Zugriff auf andere VCNs: Peering

Beim VCN-Peering werden mehrere virtuelle Cloud-Netzwerke (VCNs) miteinander verbunden. Es gibt vier Arten von VCN-Peering:

Mit dem VCN-Peering können Sie Ihr Netzwerk in mehrere VCNs (z.B. basierend auf Abteilungen oder Geschäftsbereichen) unterteilen, wobei jedes VCN direkten, privaten Zugriff auf die anderen VCNs hat. Es ist nicht erforderlich, dass Traffic über das Internet oder durch Ihr On-Premise-Netzwerk über ein Site-to-Site-VPN oder FastConnect geleitet wird. Sie können auch gemeinsame Ressourcen in einem einzelnen VCN platzieren, auf die alle anderen VCNs privat zugreifen können.

Jedes VCN kann über bis zu 10 lokale Peering-Gateways verfügen und kann nur an ein DRG angehängt werden. Ein einzelnes DRG unterstützt bis zu 300 VCN-Anhänge, sodass Traffic zwischen ihnen wie von den Routentabellen des DRG angewiesen fließen kann. Wir empfehlen die Verwendung von DRG, wenn Sie eine große Anzahl von VCNs als Peer verwenden müssen. Wenn Sie Traffic mit extrem hoher Bandbreite und extrem geringer Latenz zwischen zwei VCNs in derselben Region benötigen, verwenden Sie das unter Lokales VCN-Peering mit lokalen Peering-Gateways beschriebene Szenario. Das lokale VCN-Peering über ein upgegradetes DRG bietet Ihnen mehr Flexibilität beim Routing aufgrund der größeren Anzahl von Anhängen.

Da das Remote-VCN-Peering mehrere Regionen umfasst, können Sie es beispielsweise verwenden, um die Datenbanken aus einer Region in eine andere zu spiegeln oder zu sichern.

Lokales VCN-Peering - Überblick

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

Mit dem lokalen VCN-Peering über ein upgegradetes DRG erhalten Sie mehr Flexibilität beim Routing und vereinfachte Verwaltung. Allerdings erhöht sich die Latenz um einige Mikrosekunden, da der Traffic über einen virtuellen Router, das DRG, geleitet wird.

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 Ihrem VCN und einem anderen hergestellt wurde, können Sie den Paketfluss über die Verbindung mit Routentabellen in Ihrem VCN steuern. Beispiel: Sie können den Traffic auf bestimmte Subnetze im anderen VCN beschränken.

Ohne Beenden des Peerings können Sie den Trafficfluss zum anderen VCN stoppen, indem Sie einfach 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 muss sicherstellen, dass der gesamte ausgehende und eingehende Traffic im anderen VCN beabsichtigt oder erwartet und ordnungsgemäß definiert ist. In der Praxis bedeutet dies die Implementierung von Sicherheitslistenregeln, die explizit angeben, welche Traffictypen die VCNs untereinander versenden und akzeptieren können.

Wichtig

Ihre Instanzen, auf denen Plattformimages ausgeführt werden, verfügen auch über Firewallregeln des Betriebssystems, die den Zugriff auf die Instanz steuern. Stellen Sie bei der Fehlerbehebung des Zugriffs auf eine Instanz sicher, dass alle 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 Konfigurationen für die Instanzen in Ihrem VCN auswerten. Es können Standardkonfigurationen vorhanden sein, die nicht für das CIDR Ihres eigenen VCN gelten, sondern irrtümlicherweise für das CIDR des anderen VCN.

Standardsicherheitslistenregeln verwenden

Wenn die Subnetze des VCN die Standardsicherheitsliste mit den Standardregeln verwenden, beachten Sie, dass es zwei Regeln gibt, mit denen jeder Ingress-Traffic zugelassen wird (also 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, beabsichtigt/erwartet und ordnungsgemäß definiert ist.

Performanceauswirkungen und Sicherheitsrisiken antizipieren

Richten Sie das VCN generell entsprechend möglicher Auswirkungen durch das andere VCN ein. Beispiel: Die Auslastung Ihres VCN oder seiner Instanzen könnte sich erhöhen. Oder Ihr VCN könnte direkt vom oder über das andere VCN schädlich angegriffen werden.

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

Zu Sicherheitsrisiken: Sie können nicht unbedingt kontrollieren, ob das andere VCN mit dem Internet verbunden ist. Ist dies der Fall, kann Ihr VCN Bounce-Angriffen ausgesetzt sein, bei denen ein böswilliger Host im Internet Traffic an Ihr VCN sendet, wobei der Anschein erweckt wird, dass der Traffic vom anderen Peer-VCN stammt. Um dies zu vermeiden, verwenden Sie Ihre Sicherheitslisten, um den eingehenden Traffic vom anderen VCN sorgfältig auf erwarteten und ordnungsgemäß definierten Traffic zu begrenzen.