VCN - Fehlerbehebung

Wichtige API-Änderungen

Wenn jemand in Ihrer Organisation ein regionales Subnetz implementiert, müssen Sie möglicherweise jeden Clientcode aktualisieren, der mit Subnetzen des Networking-Service und privaten IPs arbeitet. Es können wichtige Änderungen hinsichtlich der API vorliegen. Weitere Informationen finden Sie im Versionshinweis für das regionale Subnetz .

DNS-Resolver-Endpunkte

Netzwerksicherheitsgruppen (NSGs) fungieren als virtuelle Firewall für die DNS-Resolver-Endpunkte. Eine NSG besteht aus einem Set von Ingress- und Egress-Sicherheitsregeln, die nur für die zugeordneten DNS-Resolver-Endpunkte gelten.

Sekundäre IP-Adresse

Wenn Sie einer sekundären VNIC eine sekundäre IP zugewiesen haben und policybasiertes Routing für die sekundäre VNIC verwenden, konfigurieren Sie die Routingregeln für die Instanz so, dass dieselbe Routentabelle für die sekundäre IP-Adresse mit dem Befehl ip rule add from <source address> lookup <table name> gesucht wird.

DNS in Ihrem VCN

Mit der DHCP-Option für den Domain Name Server geben Sie den DNS-Typ für das verknüpfte Subnetz an. Wenn Sie den Wert der Option ändern, starten Sie entweder den DHCP-Client auf der Instanz neu oder starten die Instanz neu. Andernfalls wird die Änderung erst wirksam, wenn der DHCP-Client die Lease aktualisiert (innerhalb von 24 Stunden).

Im Internet- und VCN-Resolver können Instanzen standardmäßig keine Namen von Hosts in Ihrem On-Premise-Netzwerk auflösen, das über Site-to-Site-VPN oder FastConnect mit Ihrem VCN verbunden ist. Diese Funktionalität kann entweder mit einem benutzerdefinierten Resolver oder durch Konfigurieren des privaten DNS-Resolvers des VCN erreicht werden.

Anforderungen an DNS-Labels und -Hostnamen

VCN- und Subnetzlabels: Maximal 15 alphanumerische Zeichen und müssen mit einem Buchstaben beginnen. Beachten Sie, dass Bindestriche und Unterstriche NICHT zulässig sind. Der Wert kann später nicht geändert werden.
Hostnamen: maximal 63 Zeichen, Buchstaben und Zahlen sind zulässig. Bindestriche sind zulässig. Beachten Sie, dass der Hostname keine Punkte enthalten, nicht mit einem Bindestrich beginnen oder enden und nicht nur aus Zahlen bestehen darf. Hostnamen müssen mit RFCs 952 und 1123 konform sein. Der Wert kann später geändert werden.

Verwechseln Sie das DNS-Label oder den Hostnamen nicht mit dem benutzerfreundlichen Namen, den Sie dem Objekt zuweisen können (also dem Anzeigenamen), der nicht eindeutig sein muss.

Weitere Informationen finden Sie unter DNS-Domains und -Hostnamen.

Firewalls

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 Ihrer 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.

Ausgehendes SMTP ist blockiert

Mandanten, die nach dem 23. Juni 2021 erstellt wurden, dürfen standardmäßig keine E-Mails über den ausgehenden TCP-Port 25 an das Internet senden. Mandanten, die vor dem 23. Juni 2021 erstellt wurden, sind nicht betroffen. Wenn Sie E-Mails von Ihrem Mandanten senden müssen, öffnen Sie eine Serviceanfrage für Servicelimits, um eine Ausnahme zu erhalten.

Neue Verbindungen zu einer Compute-Instanz sind nicht erfolgreich

Oracle verwendet Verbindungstracking, um Antworten für Traffic zuzulassen, der mit Regeln für zustandsbehafteten Zugriff übereinstimmt. Jede Compute-Instanz hat eine maximale Anzahl gleichzeitiger Verbindungen, die basierend auf der Ausprägung der Instanz überwacht werden können. Wenn Sie das Trackinglimit für Instanzverbindungen erreichen, werden alle neuen Verbindungen zur Instanz gelöscht.

Um mit der Konsole zu prüfen, ob neue Verbindungen gelöscht werden, prüfen Sie die VNIC-Metriken der Instanz:

Bestätigen Sie, dass Sie das Compartment anzeigen, das die gewünschte Instanz enthält.
Öffnen Sie das Navigationsmenü, und klicken Sie auf Compute. Klicken Sie unter Compute auf Instanzen.
Klicken Sie auf die Instanz, um deren Details anzuzeigen.
Klicken Sie unter Ressourcen auf Angehängte VNICs.

Die primäre VNIC und alle sekundären VNICs, die an die Instanz angehängt sind, werden angezeigt.
Klicken Sie auf die gewünschte VNIC.
Unter Metriken sind vier Tabellen für das Verbindungstracking relevant:
- INGRESS PACKETS DROPPED BY FULL CONNECTION TRACKING TABLE
  Ein anderer Wert als Null gibt an, dass die Trackingtabelle voll ist.
- EGRESS PACKETS DROPPED BY FULL CONNECTION TRACKING TABLE
  Ein anderer Wert als Null gibt an, dass die Trackingtabelle voll ist.
- CONNECTION TRACKING TABLE UTILIZATION
  Der Wert 100% gibt an, dass die Trackingtabelle voll ist.
- CONNECTION TRACKING TABLE FULL
  Der Wert 1/True gibt an, dass die Trackingtabelle voll ist.

Wenn die Trackingtabelle voll ist, können Sie das Problem der ausgefallenen Verbindungen und gelöschten Paketen lösen, indem Sie eine der folgenden Änderungen implementieren:

Regeln für zustandsbehafteten Ingress in zustandslose Regeln ändern (erstellen Sie eine entsprechende Regel für zustandslosen Egress, um Antworten zuzulassen)
Zu einer größeren Compute-Ausprägung mit höherem Verbindungslimit wechseln

Subnetze oder VCNs löschen

In diesem Thema wird erläutert, warum ein Subnetz oder VCN möglicherweise nicht gelöscht werden kann.

Denken Sie daran:

Um ein VCN zu löschen, muss es zunächst leer sein und darf keine zugehörigen Ressourcen oder angehängten Gateways enthalten (Beispiel: kein Internetgateway, dynamisches Routinggateway usw.).
Damit die Subnetze eines VCN gelöscht werden können, müssen diese leer sein (sie dürfen z.B. keine VNICs oder Resolver-Endpunkte enthalten).

Option "Alle löschen"

Die Konsole stellt den einfachen Prozess "Alle löschen" bereit. Damit werden die ausgewählten Compartments gescannt und dann das VCN mit den zugehörigen Netzwerkressourcen (Subnetze, Routentabellen, Sicherheitslisten, Sets von DHCP-Optionen, Internetgateway usw.) gelöscht. Wenn das VCN an ein dynamisches Routinggateway (DRG) angehängt ist, wird der Anhang gelöscht, das DRG bleibt jedoch bestehen.

Der Prozess "Alle löschen" löscht jeweils eine Ressource. Das Löschen eines VCN mit vielen Compartments und Ressourcen dauert länger als das Löschen eines VCN mit nur wenigen Compartments. In einem Statusbericht werden die Ergebnisse des Scans nach Ressourcen und des Löschens dieser Ressourcen angezeigt.

Hinweis

Stellen Sie vor der Verwendung des Prozesses "Alle löschen" sicher, dass keine Ressourcen wie Compute-Instanzen, Load Balancer, OCI-Datenbanksysteme oder verwaiste Mountziele in einem der Subnetze vorhanden sind. Wenn eine dieser Ressourcen vorhanden ist, wird der Löschprozess beim Löschen des Subnetzes der Ressource gestoppt. Gelöschte VCN-Ressourcen können nicht mehr abgerufen werden. Weitere Informationen finden Sie unter Subnetze oder VCNs löschen.

Wenn ein Subnetz noch Ressourcen enthält oder Sie nicht zum Löschen einer bestimmten Netzwerkressource berechtigt sind, wird der Prozess "Alle löschen" gestoppt und eine Fehlermeldung zurückgegeben, die die OCIDs der blockierenden Ressourcen und Subnetze enthält, die mit der Detailseite für diese Ressource verlinkt sind. In einigen Fällen müssen Sie sich an den Mandantenadministrator wenden, damit Sie die verbleibenden Ressourcen löschen können, wenn Sie nicht über die erforderlichen Berechtigungen verfügen.

Das Subnetz ist nicht leer

Der häufigste Grund, weswegen ein Subnetz (und somit ein VCN) nicht gelöscht werden kann, ist das Vorhandensein von mindestens einer der folgenden Ressourcen im Subnetz:

Load Balancer
Verwaistes Mountziel im Dateispeicher
Bastion
OCI-Datenbanksysteme (Exadata Database Service auf dedizierter Infrastruktur, Autonomous Database auf dedizierter Exadata-Infrastruktur oder Base Database-Systeme)

Hinweis

Beim Erstellen einer der oben genannten Ressourcen geben Sie ein VCN und ein Subnetz dafür an. Der relevante Service erstellt mindestens eine VNIC im Subnetz und hängt die VNIC an die Ressource an. Der Service verwaltet die VNICs für Sie, sodass sie Ihnen in der Konsole nicht unmittelbar angezeigt werden. Die VNIC ermöglicht es der Ressource, mit anderen Ressourcen über das Netzwerk zu kommunizieren. Zwar ist in dieser Dokumentation häufig die Rede davon, dass sich die Ressource selbst im Subnetz befindet, doch ist es vielmehr die an die Ressource angehängte VNIC. In dieser Dokumentation wird der Begriff übergeordnete Ressource verwendet, um auf diesen Ressourcentyp zu verweisen.

Wenn das Subnetz leer ist und Sie versuchen, es zu löschen, wechselt sein Status kurzfristig zu TERMINATING und anschließend zu TERMINATED.

Wenn das Subnetz nicht leer ist, erhalten Sie stattdessen eine Fehlermeldung, die besagt, dass noch Ressourcen vorhanden sind, die Sie zuerst löschen müssen. Die Fehlermeldung enthält die OCID einer VNIC im Subnetz (möglicherweise sind mehr vorhanden, die Fehlermeldung gibt jedoch nur die OCID einer einzelnen VNIC an).

Sie können den Vorgang GetVnic mit der VNIC-OCID über die Oracle Cloud Infrastructure-Befehlszeilenschnittstelle (CLI) oder über ein anderes SDK oder einen anderen Client aufrufen. Die Antwort enthält den Anzeigenamen der VNIC. Je nach Typ der übergeordneten Ressource kann der Anzeigename angeben, zu welcher übergeordneten Ressource die VNIC gehört. Sie können dann diese übergeordnete Ressource löschen oder sich mit Ihrem Administrator in Verbindung setzen, um zu bestimmen, wer der Eigentümer der Ressource ist. Wenn die übergeordnete Ressource der VNIC gelöscht wird, wird die angehängte VNIC ebenfalls aus dem Subnetz gelöscht. Wenn VNICs im Subnetz verbleiben, wiederholen Sie den Vorgang zum Bestimmen und Löschen jeder übergeordneten Ressource, bis das Subnetz leer ist. Anschließend können Sie das Subnetz löschen.

Beispiel: Wenn Sie die CLI verwenden, rufen Sie mit dem folgenden Befehl Informationen zur VNIC ab.

oci network vnic get --vnic-id <VNIC_OCID>

Beispiel für Load Balancer

Im Folgenden sehen Sie eine CLI-Beispielantwort für eine VNIC, die zu einem Load Balancer gehört. Der Anzeigename zeigt die OCID des Load Balancers an:

{
  "data": {
    "availability-domain": "fooD:PHX-AD-1", 
    "compartment-id": "ocid1.compartment.oc1..<unique_id_1>", 
    "defined-tags": {}, 
    "display-name": "VNIC for LB ocid1.loadbalancer.oc1.phx.<unique_id_2>", 
    "freeform-tags": {}, 
    "hostname-label": null, 
    "id": "ocid1.vnic.oc1.phx.<unique_id_3>", 
    "is-primary": false, 
    "lifecycle-state": "AVAILABLE", 
    "mac-address": "00:00:17:00:BB:CA", 
    "private-ip": "10.0.0.6", 
    "public-ip": null, 
    "skip-source-dest-check": false, 
    "subnet-id": "ocid1.subnet.oc1.phx.<unique_id_4>", 
    "time-created": "2019-05-11T04:28:31.950000+00:00"
  }, 
  "etag": "5d8213fa"
}

Beispiel für File Storage

Hier sehen Sie ein Beispiel für eine VNIC, die zu einem File Storage-Mountziel gehört:

"display-name": "fss-<integer>",

Auch wenn der Anzeigename keine OCID enthält, geben die Zeichen fss an, dass die Ressource für den File Storage-Service bestimmt ist.

Beispiel für Database

Hier sehen Sie ein Beispiel für den Anzeigenamen einer VNIC, die zu einem DB-System gehört:

"display-name": "ocid1.dbnode.oc1.phx.<unique_id>",

Eine Netzwerksicherheitsgruppe ist nicht leer

Ein weiterer Grund, weswegen ein VCN nicht gelöscht werden kann, ist das Vorhandensein einer oder mehrerer Netzwerksicherheitsgruppen (NSGs) im VCN, die noch nicht leer sind. Um eine NSG zu löschen, darf sie keine VNICs (oder übergeordneten Ressourcen mit VNICs) enthalten. Mit der Konsole oder der REST-API können Sie bestimmen, welche übergeordneten Ressourcen sich in einer NSG befinden. Weitere Informationen finden Sie unter NSG löschen.

Es sind Ressourcen in Compartments vorhanden, auf die Sie keinen Zugriff haben

Möglicherweise können Sie nicht alle Ressourcen in einem Subnetz oder VCN sehen. Dies liegt daran, dass Subnetze und VCNs Ressourcen in mehreren Compartments enthalten können und Sie möglicherweise nicht auf alle Compartments zugreifen können. Beispiel: Das Subnetz kann Instanzen enthalten, die Ihr Team verwaltet, aber auch DB-Systeme, die von einem anderen Team verwaltet werden. Weiteres Beispiel: Das VCN enthält möglicherweise Sicherheitslisten oder ein Gateway in einem Compartment, das von einem anderen Team verwaltet wird. Möglicherweise müssen Sie sich an den Mandantenadministrator wenden, um herauszufinden, wer der Eigentümer der Ressourcen im Subnetz oder im VCN ist.

Wiederverwendung eines LPGs nicht erfolgreich

Details

Ein für eine bestimmte lokale Peering-Verbindung erstelltes LPG kann nicht für eine neue und andere lokale Peering-Verbindung verwendet werden.

Wenn Sie dies versuchen, wird möglicherweise die Fehlermeldung The Local Peering Gateway with ID <LPG_OCID> has already been connected angezeigt, wenn:

LPG 1 in VCN 1 wurde einmal erfolgreich mit LPG 2 in VCN 2 verbunden.
VCN 1 (einschließlich LPG 1) wird anschließend gelöscht. Der LPG 2-Peering-Status ändert sich in "widerrufen" oder "vernichtet".
Sie versuchen, LPG 2 mit LPG 3 zu verbinden.

Sie können auch eine etwas andere Meldung (A peering with VCN <VCN_OCID> has already been established) sehen, wenn:

LPG 1 in VCN 1 wurde einmal erfolgreich mit LPG 2 in VCN 2 verbunden.
LPG 2 wird anschließend gelöscht. Der Peering-Status von LPG 1 ändert sich in "widerrufen" oder "vernichtet".
Sie versuchen, LPG 1 mit LPG 3 zu verbinden (dies könnte ein neues LPG in VCN 2 oder einem anderen VCN sein).

Vorgeschlagene Lösung

Führen Sie folgende Aktionen aus:

Löschen Sie das LPG, das Sie neu verwenden möchten.
Wenn dieser Löschfehler mit 409 - Local Peering Gateway <LPG_OCID> is associated with one or more entities that are in use auftritt, wird das LPG wahrscheinlich in Routingregeln in mindestens einer Routentabelle angegeben. Prüfen Sie die Routentabellen für Ihr VCN, entfernen Sie diese Routen aus den relevanten Routentabellen, und versuchen Sie dann erneut, das LPG zu löschen.
Erstellen Sie ein neues LPG, und stellen Sie ein Peering mit einem neuen LPG im gewünschten VCN her.

Oracle Cloud Infrastructure - Dokumentation