Grundlegende Netzwerkprobleme in Oracle Cloud Infrastructure beheben

Einführung

In Oracle Cloud Infrastructure (OCI) erfordert die Diagnose von Netzwerkkonnektivitätsproblemen einen Einblick in die Konfiguration und den Datenfluss über mehrere Komponenten hinweg. OCI Network Command Center-Tools wie Network Visualizer, Network Path Analyzer und VCN-Flowlogs bieten umfassende Einblicke in das Layout, Routing und Ablaufverhalten von Netzwerkressourcen. Diese Tools ermöglichen die schnelle Identifizierung von Fehlkonfigurationen, fehlenden Routen und Kommunikationsfehlern über virtuelle Cloud-Netzwerke (VCNs), Subnetze und Gateways in einer OCI-Netzwerkumgebung.

In diesem Tutorial werden wir uns auf grundlegende Fehlerbehebungstechniken für allgemeine Konnektivitätsprobleme konzentrieren. Während es zeigt, wie diese Tools effektiv genutzt werden können, um die Fehlerbehebung zu vereinfachen und Probleme effizient zu lösen, besteht das Ziel auch darin, ein umfassenderes Verständnis dafür zu entwickeln, wie Konnektivitätsherausforderungen angegangen und analysiert werden können, und nicht nur, wie die Tools selbst verwendet werden.

Ziele

Mit dem Network Visualizer-Tool können Sie das Netzwerklayout auf regionaler, VCN- und Subnetzebene untersuchen.
Analysieren Sie Verkehrswertpfade mit dem Network Path Analyzer-Tool, um zu verstehen, wie Pakete das Netzwerk durchlaufen und Fehler identifizieren.
Interpretieren Sie das VCN-Flowlogs-Tool, um Verkehrsflussdatensätze zu prüfen und Konnektivitätsprobleme oder ungewöhnliches Verhalten zu erkennen.
Identifizieren und beheben Sie Fehler in Netzwerkkonfigurationen, fehlenden Routen und Kommunikationsfehlern.

Voraussetzungen

Sie kennen grundlegende OCI-Netzwerkkomponenten wie VCN, Subnetze, Gateways, Sicherheitslisten und Routentabellen.
Sie haben Zugriff auf einen OCI-Mandanten mit konfigurierten Netzwerkressourcen.
Für Ihren Benutzeraccount sind Oracle Cloud Infrastructure Identity and Access Management-(OCI IAM-)Policys erforderlich, um VCN-Komponenten zu verwalten. Außerdem können Sie Network Visualizer, Network Path Analyzer und VCN-Flowlogs verwenden.

Um eine einfache Apache-Website zu erstellen, führen Sie die folgenden Befehle in Ihrem virtuellen Oracle Linux-Testrechner (vM) aus, und befolgen Sie einige der bevorstehenden Beispiele.

sudo dnf install httpd --assumeyes
sudo systemctl enable httpd
sudo systemctl start httpd
sudo firewall-offline-cmd --add-service=http
sudo systemctl restart firewalld
sudo vi /var/www/html/index.html

'<!doctype html><html><body><h1>Test Apache Website.. it's reachable!</h1></body></html>'

Aufgabe 1: Netzwerk-Setup mit Network Visualizer anzeigen

Bevor Sie anfangen, in das zu graben, was kaputt ist, hilft es, einen Schritt zurück zu gehen und einen klaren Überblick über Ihre Netzwerkumgebung zu erhalten. Der Network Visualizer in OCI bietet eine grafische Darstellung Ihrer VCN-Topologie. Sie kann zwar Probleme nicht direkt beheben, bietet jedoch eine klare, konsolidierte Ansicht der gesamten Netzwerkarchitektur in einem bestimmten Compartment, das Sie auswählen.

Dieser visuelle Kontext zeigt, wie alles an einem Ort verbunden ist (VCNs, Subnetze, Gateways, Routentabellen, Sicherheitslisten). Dadurch ist es einfacher, alles zu erkennen, was aussieht, wie eine fehlende Route oder ein VCN, das nicht mit einem dynamischen Routinggateway (DRG) verknüpft ist. In komplexen Setups kann es Ihnen viel Raten ersparen. Es ist nicht immer eine Lösung, aber es ist ein solider erster Schritt, der Sie in die richtige Richtung weisen kann, bevor Sie in die Details gelangen.

In diesem Tutorial haben wir die Funktionsweise von Network Visualizer im folgenden Diagramm zusammengefasst. Weitere Informationen finden Sie unter Netzwerkvisualisierung.

Beispiel

Als Beispiel verwenden wir die folgende Architektur.

In diesem Beispielfall traten zwei Probleme in der Umgebung auf. Wir werden sehen, wie der Network Visualizer hilft, sie zu identifizieren und zu lösen.

Problemfall 1: VM-1 kann kein Ping für VM-2 ausführen.
Problemfall 2: VM-2 kann das Internet nicht erreichen.

Nehmen wir an einer kurzen Einführung in unsere Netzwerkumgebung mit Network Visualizer in der OCI-Konsole teil, die der Architektur entsprechen sollte.

Erste Ebene: Regionale Netzwerktopologie

Diese Topologie umfasst DRGs, VCNs, CPEs und verschiedene Gateways.

Melden Sie sich bei der OCI-Konsole an.
1. Stellen Sie sicher, dass Sie in der richtigen Region sind.
2. Klicken Sie in der oberen linken Ecke auf das Hamburger-Menü (≡).
3. Klicken Sie auf Networking.
4. Klicken Sie auf Network Visualizer.

Dies ist die erste Ansicht, die angezeigt wird, wenn Sie auf Network Visualizer zugreifen. Lassen Sie uns es aufschlüsseln.
1. Wählen Sie das Compartment aus, in dem sich die Netzwerkkomponenten befinden. Wenn Sie nicht sicher sind, wo sich Ihre Ressourcen befinden, wählen Sie das übergeordnete Compartment (oder Root Compartment) aus, und wählen Sie Untergeordnete Compartments einbeziehen aus.
2. Notieren Sie sich die VCNs VCN-1 und VCN-2 sowie den Adressblock IPv4 für jedes VCN.
3. Beachten Sie die Netzwerkgateways, wie:
  - Ein DRG, das mehrere Anhänge (VCNs, RPC und IPSec) enthält.
  - Ein NAT-Gateway in VCN-2.
4. Außerdem sehen Sie einen Remote Peering Connect (RPC), der die VCNs in der Region Jeddah mit einer anderen Region (Riyadh) verbindet.
5. Außerdem ist eine IPSec-Verbindung zum On-Premise-Netzwerk vorhanden. Sie können die öffentliche IP des CPE-Geräts des Kunden (210.20.x.x) und den On-Premise-Netzwerkadressblock anzeigen, der privat mit unseren VCNs kommuniziert (172.16.16.10/32).

Klicken Sie auf VCN-2.
Gehen wir nun näher auf die VCN-Topologie ein, beginnend mit der Routingkarte.

Zweite Ebene: VCN-Topologie

Diese Topologie umfasst Subnetze, VLANs und Gateways zu anderen Ressourcen. Zusätzlich zu den vom Subnetz verwendeten Sicherheitsregeln (Sicherheitsliste oder NSG).

Wir befinden uns in der Kartenansicht des VCN-Routings.
VCN-2 besteht aus einem privaten Subnetz.
In der Routentabelle des Subnetzes wird eine Regel angezeigt, die Traffic, der als nächster Hop an VCN-1 bestimmt ist, an das DRG sendet.

Wechseln Sie zur VCN-Mappingansicht Sicherheit.
In dieser Ansicht wird auch angezeigt, dass VCN-2 aus einem privaten Subnetz besteht.
Außerdem sind Sicherheitslisten und Netzwerksicherheitsgruppen (NSGs), die an das private Subnetz angehängt sind, in diesem Modus sichtbar.

Klicken Sie auf das private Subnetz.
Gehen wir nun genauer auf die Subnetztopologie ein, beginnend mit der Bestandsübersicht.

Dritte Ebene: Subnetztopologie

Diese Topologie zeigt die Ressourceninformationen zu OCI Compute-Instanzen, OCI Load Balancern, OCI File Storage Service und OCI Kubernetes Engine-(OKE-)Clustern im Subnetz sowie die Sicherheitsregeln an, die von der Ressource verwendet werden.

Wir befinden uns in der Subnetz-Map-Ansicht Bestand.
In diesem Subnetz (VM-2) ist nur eine Compute-Instanz vorhanden. Klicken Sie darauf.
Einige Informationen zur VM, wie Compartment, IPs und mehr, werden angezeigt.

Wechseln Sie zur Sicherheitszuordnungsansicht des Subnetzes.
In diesem Subnetz (VM-2) ist nur eine Compute-Instanz vorhanden.
Wir sehen, welche Sicherheitslisten und NSGs VM-2 verwendet.

Zusammenfassung:

Wir haben untersucht, wie unsere Netzwerkumgebung aussieht und welche Komponenten beteiligt sind. Was sind Ihrer Meinung nach die Ursachen für das oben erwähnte Problem?

Problemfall 1: VM-1 kann kein Ping für VM-2 ausführen.

Beachten Sie in der First Level: Regional Network Topology, dass VCN-1 nicht an das DRG angehängt ist. Damit der Kommunikationsfluss zwischen VM-1 und VM-2 stattfinden kann, müssen Sie VCN-1 anhängen und die erforderliche Routingregel hinzufügen, um den Trafficfluss zu aktivieren.

Wenn Sie VCN-1 anhängen und die folgende Routingregel hinzufügen (Ziel: VCN-2, nächster Hop:-DRG), sollte das Problem behoben werden. Das bedeutet, dass das Routing in VCN-2 bereits ordnungsgemäß konfiguriert ist und ICMP-Typ 8 in beiden Sicherheitslisten zulässig ist.
Problemfall 2: VM-2 kann das Internet nicht erreichen.

Beachten Sie in der zweiten Ebene: VCN-Topologie, dass das private Subnetz von VCN-2 nur eine Route zum DRG, aber keine Routen zum NAT-Gateway aufweist, wodurch VM-2 keine Internetverbindung hat.

Wenn Sie die folgende Routingregel hinzufügen (Ziel: 0.0.0.0/0, Nächster Hop: NAT-Gateway), sollte das Problem behoben werden. Angenommen, Egress-Traffic ist bereits in der Sicherheitsliste zulässig.

Network Visualizer kann Ihnen helfen, offensichtliche Probleme zu erkennen, die durch Fehlkonfigurationen verursacht werden, wie wir im Beispiel gesehen haben. Aber selbst wenn es kein klares Problem offenbart, liegt sein wirklicher Wert darin, Ihnen eine ganzheitliche Sicht auf Ihre Umgebung zu geben. Diese Big-Picture-Perspektive hilft Ihnen, das aktuelle Setup zu validieren und gibt Ihnen einen soliden Ausgangspunkt, bevor Sie tiefer in komplexere Probleme eintauchen.

Aufgabe 2: Netzwerkkonfiguration validieren

Nachdem Sie einen klaren Überblick über Ihre Netzwerkumgebung und die Komponenten erhalten haben, ist der nächste wesentliche Schritt, die tatsächliche Konfiguration zu validieren. Viele Konnektivitätsprobleme führen zu einem einfachen Problem: einer fehlenden Route, zu strengen Sicherheitsregeln oder einem Subnetz, das einfach mit der falschen Routentabelle oder Sicherheitsliste verknüpft ist.

Bevor Sie in eine tiefere Fehlerbehebung wie das Überprüfen von Protokollen oder das Ausführen von Paketerfassungen einsteigen, müssen Sie sicherstellen, dass alles wie erwartet konfiguriert ist. Dieser Schritt kann oft die Ursache frühzeitig aufdecken und Ihnen helfen, später unnötige Untersuchungen zu vermeiden.

Beispiel

Als Beispiel verwenden wir die folgende Architektur.

Lassen Sie uns zunächst die wichtigsten Routing- und Sicherheitskomponenten beschreiben, die bei der Validierung der Konfiguration eine zentrale Rolle spielen:

Routingregeln:
- On Premise:
  - RT-0: Routing des On-Premises-CPE-(Customer Premises Equipment-)Geräts (oder Multicloud), im Falle einer FastConnect- oder IPSec-Verbindung (siehe Anbieter: Cisco, Fortinet usw.).
- OCI-VCN-Routentabellen: Im VCN vorhanden und zum Senden von Traffic aus dem VCN (z.B. an das Internet, an ein On-Premise-Netzwerk oder an ein Peer-VCN) verwendet. Diese Routentabellen enthalten Regeln, die ähnlich wie herkömmliche Netzwerkroutingregeln aussehen und agieren, mit denen Sie möglicherweise bereits vertraut sind.
  - RT-1-2-3: VCN-Routingtabellen, die der Subnetzebene zugewiesen sind, um abgehenden Traffic weiterzuleiten.
  - RT-2a: VCN-Routingtabellen, die dem DRG-Anhang VCN-2 zugewiesen sind, der für Transitrouting-Szenarios erforderlich ist. In diesem Beispiel wird er als Ingress-Routentabelle verwendet, um Traffic vom DRG zur Prüfung durch die Firewall weiterzuleiten.
  - RT-2b: Die VCN-Routingtabelle, die an das NAT-Gateway angehängt ist. In diesem Beispiel wird sie als Ingress-Routentabelle verwendet, um Antworttraffic, der aus dem Internet zurückkehrt, zur Prüfung an die Firewall weiterzuleiten.
- OCI-DRG-Routentabellen: Sind im DRG vorhanden und werden verwendet, um Pakete, die in das DRG eingehen, über den Anhang weiterzuleiten.
  - RT-10-20-30: DRG-Routingtabellen für VCN-Anhänge, um Traffic vom VCN weiterzuleiten.
  - RT-40-50: DRG-Routingtabellen für RPC-Anhänge, um Traffic aus der anderen Region weiterzuleiten.
  - RT-60: DRG RT für IPSec-Anhang, um Traffic von On-Premises oder einem Multicloud-Netzwerk weiterzuleiten.
Sicherheitsregeln:
- On Premise:
  - FW-0: Kontrollieren und schränken Sie den Trafficfluss zu und von OCI auf dem On-Premise-CPE-Gerät (oder Multicloud) ein, falls eine FastConnect- oder IPSec-Verbindung besteht (siehe Anbieter: Cisco, Fortinet usw.).
- OCI-VCN-Sicherheitslisten: fungieren als virtuelle Firewalls für VCN-basierte Ressourcen mit Ingress- und Egress-Regeln, die angeben, welche Traffictypen ein- und ausgehen dürfen. Sicherheitslisten werden auf Subnetzebene konfiguriert. Das bedeutet, dass alle VNICs in einem Subnetz demselben Set von Sicherheitslisten unterliegen.
  - SL-1-2-3: Sicherheitslisten, die der Subnetzebene zugewiesen sind, um Ingress- und Egress-Traffic in jedem Subnetz zu steuern.
Hinweis: NSGs sind ein weiterer Typ von virtuellen Firewalls, die in OCI verfügbar sind. Sie funktionieren ähnlich wie Sicherheitslisten, bieten jedoch eine genauere Kontrolle, da sie auf Ressourcenebene angewendet werden. Dies ist nützlich, wenn zwei Ressourcen im selben Subnetz unterschiedliche Sicherheitsmaßnahmen erfordern. NSGs werden in diesem Tutorial jedoch nicht verwendet. Weitere Informationen finden Sie unter Vergleich von Sicherheitslisten und Netzwerksicherheitsgruppen.
- OCI Network Firewall oder eine Firewall eines Drittanbieters: fungiert als zentralisierter, zustandsbehafteter Prüfpunkt für Traffic zwischen Subnetzen, VCNs und externen Netzwerken und erzwingt erweiterte Sicherheits-Policys über grundlegende Sicherheitslistenregeln hinaus.
  - FW-2: Kontrolliert und prüft den gesamten Nord-Süd- und Ost-West-Datenverkehr in einer OCI-Netzwerkumgebung.

Wir verstehen, wie Routing und Sicherheit in der gesamten Umgebung angewendet werden. Schauen wir uns den folgenden Beispielfall genauer an, in dem vier Probleme aufgetreten sind. Durch die Anwendung eines gesunden Menschenverstandes werden wir herausfinden, welche Konfigurationen überprüft werden müssen und wo für jedes Problembehebungsszenario.

Hinweis:

Wenn NSGs verwendet werden, prüfen Sie die Konfigurationen, die auf jede VNIC angewendet wurden, die an jede VM angehängt ist.

In diesem Beispiel fungiert VM-2 als Firewall eines Drittanbieters (FortiGate). Es ist bereits so konfiguriert, dass Traffic ordnungsgemäß weitergeleitet wird.

Problemfall 1: VM-1 kann keinen Ping-Vorgang für VM-3 ausführen (andere Regionen, Firewall sollte den Traffic NICHT prüfen).
- Routing:
  - Anforderung: RT-1 > RT-10 > RT-40.
  - Antwort: RT-3 > RT-30 > RT-50.
- Sicherheit: ICMP-Typ 8 muss einen erfolgreichen Ping-Vorgang zulassen.
  - Anforderung: SL-1 (Egress-Regeln) > SL-3 (Ingress-Regeln).
  - Antwort: SL-3 (Egress-Regeln) > SL-1 (Ingress-Regeln).
Problemfall 2: VM-1 kann das Internet nicht erreichen (VM-2-Firewall muss den Traffic prüfen).
- Routing:
  - Anforderung: RT-1 > RT-10 > RT-2a > FW-2 internes Routing > RT-2.
  - Antwort: RT-2b > FW-2-Routing > RT-2 > RT-20.
- Sicherheit:
  - Anforderung: SL-1 (Egress-Regeln) > SL-2 (Ingress- und Egress-Regeln) > FW-2 (Ingress- und Egress-Regeln).
  - Antwort: SL-2 (Ingress- und Egress-Regeln) > FW-2 (Ingress- und Egress-Regeln) > SL-1 (Ingress-Regeln).
Problemfall 3: VM2 kann das Internet nicht erreichen.
- Routing:
  - Anforderung: RT-2.
  - Antwort: Es ist kein Routing erforderlich.
- Sicherheit:
  - Anforderung: SL-2 (Egress-Regeln).
  - Antwort: SL-2 (Ingress-Regeln).
Problemfall 4: On-Premise kann kein Ping für VM-1 ausführen (Firewall muss den Traffic prüfen).
- Routing:
  - Anforderung: RT-0 (On-Premises-CPE) > RT-60 > RT-2a > FW-2 internes Routing > RT-2 > RT-20.
  - Antwort: RT-1 > RT-10 > RT-2a > FW-2 internes Routing > RT-2 > RT-20.
- Sicherheit:
  - Anforderung: FW-0 (Egress-Regeln) > SL-2 (Ingress- und Egress-Regeln) > FW-2 (Ingress- und Egress-Regeln) > SL-1 (Ingress-Regeln).
  - Antwort: SL-1 (Egress-Regeln) > SL-2 (Ingress- und Egress-Regeln) > FW-2 (Ingress- und Egress-Regeln) > FW-0 (Ingress-Regeln).

Es ist wichtig zu verstehen, wie der Datenverkehr im gesamten Netzwerk verwaltet und gesteuert wird. Indem Sie den Pfadverkehr verfolgen, der erforderlich sein sollte, können Sie schnell erkennen, wo Probleme auftreten können und welche Einstellungen bei der Fehlerbehebung überprüft werden müssen.

Aufgabe 3: Netzwerkpfad-Analyzer verwenden

Sie haben das gesamte Netzwerksetup geprüft und die Konfiguration von Routing- und Sicherheitsregeln manuell geprüft. Das Problem bleibt jedoch bestehen. Vielleicht haben Sie einige Konfigurationsdetails übersehen. Was ist der nächste Schritt?

Hier kommt Network Path Analyzer ins Spiel. Betrachten Sie es als Ihren virtuellen Netzwerkdetektiv, der Ihre OCI-Netzwerkrouting- und -Sicherheitskonfiguration in Echtzeit prüft. Es sammelt und analysiert sie, um zu bestimmen, wie die Pfade zwischen der Quelle und dem Ziel funktionieren oder fehlschlagen. Es wird kein tatsächlicher Datenverkehr gesendet. Stattdessen wird die Konfiguration geprüft und zur Bestätigung der Erreichbarkeit verwendet.

Anstatt manuelle Konnektivitätstests wie Ping oder Telnet von einzelnen VMs oder Datenbanken durchzuführen, können Sie mit Network Path Analyzer die Konfiguration von Kommunikationspfaden direkt in der OCI-Konsole überprüfen und einen effizienteren und zentralisierten Ansatz zur Fehlerbehebung anbieten.

Network Path Analyzer unterstützt die folgenden Szenarios:

OCI zu OCI.
OCI zu On-Premises.
Von On Premise zu OCI.
Internet zu OCI.
OCI zum Internet.

Beispiel 1

Als Beispiel verwenden wir die folgende Architektur.

Es ist ein Netzwerkproblem aufgetreten, und wir verwenden Network Path Analyzer, um die Ursache zu verfolgen und zu beheben.

Problem: VM-1 kann nicht auf eine Website zugreifen, die auf VM-2 (OCI zu OCI) gehostet wird.

Melden Sie sich bei der OCI-Konsole an, gehen Sie zu VM-2, und führen Sie den folgenden Befehl aus, um zu prüfen, ob die Website lokal ausgeführt wird.
```
curl localhost
```
Navigieren Sie zur OCI-Konsole, navigieren Sie zu VM-1, und führen Sie denselben Befehl aus, um die Konnektivität zu VM-2 zu testen.
```
curl 192.168.0.20
```
Sie sehen, dass die Anforderung nicht erfolgreich ist. In den nächsten Schritten werden wir Network Path Analyzer verwenden, um die Ursache zu untersuchen.
Gehen Sie zur OCI-Konsole.
1. Stellen Sie sicher, dass Sie in der richtigen Region sind.
2. Klicken Sie in der oberen linken Ecke auf das Hamburger-Menü (≡).
3. Klicken Sie auf Networking.
4. Klicken Sie auf Network Path Analyzer.
Klicken Sie auf Pfadanalyse erstellen.
Konfigurieren Sie nun die Details des zu testenden Netzwerkflusses.
1. Geben Sie Name als test-vm1-to-vm2-port80 ein.
2. Wählen Sie Protokoll als TCP aus.
Wir beginnen mit dem Ausfüllen der Quellinformationen, die in diesem Fall VM-1 ist.
1. Wählen Sie OCI-Ressource suchen aus.
2. Wählen Sie Quelltyp als Compute-Instanz (VNIC) aus.
3. Wählen Sie VM-1 aus der Liste.
4. Wählen Sie VNIC aus, die den Traffic generiert (dieser wird bereits automatisch gefüllt, wenn die VM nur eine VNIC enthält).
5. Wählen Sie Quelladresse IPv4 10.0.0.10 aus (dies wird auch automatisch ausgefüllt, wenn nur eine IPv4-Adresse vorhanden ist).
1. Klicken Sie auf Erweiterte Einstellungen anzeigen.
2. Hier können Sie bei Bedarf den Quellport angeben. In diesem Beispiel lassen Sie ihn auf Jeden Port verwenden gesetzt.
Als Nächstes füllen wir die Zielinformationen aus, die in diesem Fall VM-2 sind.
1. Wählen Sie OCI-Ressource suchen aus.
2. Wählen Sie Quelltyp als Compute-Instanz (VNIC) aus.
3. Wählen Sie VM-2 aus der Liste.
4. Wählen Sie VNIC aus, die den Traffic generiert (dieser wird bereits automatisch gefüllt, wenn die VM nur eine VNIC enthält).
5. Wählen Sie Quelladresse IPv4 als 192.168.0.20 aus (dies wird auch automatisch ausgefüllt, wenn nur eine IPv4-Adresse vorhanden ist).
6. Geben Sie unter Zielport den Wert 80 ein.
1. Um sowohl Vorwärts- als auch Rückwärtsverkehr zu analysieren, behalten Sie die Richtung als Bidirektional bei.
2. Klicken Sie auf Analyse ausführen.
1. Die Verbindungsdetails werden angezeigt, wenn die Analyse ausgeführt wird.
2. Scrollen Sie nach unten, um den Fortschritt der Analyse zu verfolgen, und warten Sie, bis sie abgeschlossen ist. Dies kann ein oder zwei Minuten dauern.
Die Analyse ist abgeschlossen. Beginnen wir mit der Prüfung des Ergebnisses Forward path.
1. Die Analyse gibt an, dass VM-2 nach zwei erfolgreichen Hops nicht erreichbar ist.
2. Das Löschen erfolgt zwischen dem DRG und VM-2.
3. Um weitere Informationen zu erhalten, klicken Sie auf Diagramminformationen anzeigen.
4. In dieser Tabelle werden der Routingablauf und die Sicherheitsprüfungen bei jedem Schritt im Pfad aufgeführt.
5. Wenn Sie die Ansicht vergrößern, wird der Traffic zwischen dem DRG und VM-2 abgelehnt.
1. Blenden Sie dasselbe Segment ein, um weitere Details zu erhalten.
2. Beachten Sie, dass Routing erfolgreich weitergeleitet wurde.
3. Der Datenverkehr wird jedoch aufgrund einer fehlenden Sicherheitsregel abgelehnt:
  1. (3.a) Egress-Traffic ist erlaubt, hier keine Probleme.
  2. (3.b) Ingress-Traffic wird abgelehnt, weil es keine Regel gibt, die dies zulässt. Die mit dem Subnetz VM-2 verknüpfte Sicherheitsliste wird angezeigt (Standardsicherheitsliste für VCN-2), notieren Sie sich diese, da wir sie in den nächsten Schritten prüfen werden. An dieser Stelle haben wir die Ursache des Problems identifiziert.
1. Der Rückgabepfad wird nicht analysiert, da die Prüfung des Weiterleitungspfads nicht erfolgreich war.
2. Klicken Sie auf Analyse speichern.
3. Sie können die Analyse jederzeit erneut aufrufen und ausführen. Wir werden es später in diesem Tutorial erneut ausführen, nachdem wir das Problem behoben haben.
1. Navigieren Sie zu VCN-2, wo sich die Ziel-VM befindet.
2. Klicken Sie auf Sicherheit.
3. Klicken Sie auf Standardsicherheitsliste für VCN-2.
Hinweis: Sicherheitslisten werden auf Subnetzebene ausgeführt. Das bedeutet, dass jeder von diesen Regeln zulässige Traffic für alle VNICs in diesem Subnetz gilt.
1. Klicken Sie auf Sicherheitsregeln.
2. In der Tabelle wird angezeigt, welcher Traffic zulässig ist. Alles andere, einschließlich HTTP, wird standardmäßig abgelehnt, da es keine Regel gibt, die es zulässt. Deshalb kann VM-1 nicht auf die Website zugreifen, die auf VM-2 gehostet wird.
3. Um dies zu beheben, klicken Sie auf Ingress-Regeln hinzufügen.
1. Geben Sie 10.0.0.0/16 in das Feld Quell-CIDR ein (dies ist das CIDR für VCN-1).
2. Wählen Sie TCP als IP-Protokoll aus.
3. Setzen Sie 80 auf Zielport.
4. Klicken Sie auf Ingress-Regeln hinzufügen.
Melden Sie sich bei VM-1 an, und führen Sie denselben Befehl aus, um die Konnektivität zu VM-2 zu testen.
```
curl 192.168.0.20
```
Sie sollten jetzt sehen, dass die Website erreichbar ist.
Gehen Sie zur Analyse zurück, um eine weitere Ausführung auszuführen, und prüfen Sie, ob das Problem behoben ist.
Klicken Sie auf Analysieren.
Warten Sie, bis die Analyse abgeschlossen ist.
Die Analyse ist abgeschlossen. Prüfen Sie das Ergebnis Forward path.
1. Im Status wird jetzt Erreichbar angezeigt.
2. Hop 3 ist jetzt erfolgreich, weil wir eine Sicherheitsregel hinzugefügt haben, die HTTP-Traffic zulässt.
3. Klicken Sie auf Diagramminformationen anzeigen.
4. Sie können sehen, dass der Sicherheitsstatus für Hop 3 jetzt Zulässig lautet (zuvor wurde er Abgelehnt).
Wenn wir den Rückkehrpfad überprüfen, können wir sehen, dass er auch erfolgreich ist.

Beispiel 2

Als Beispiel verwenden wir die folgende Architektur.

Es ist ein Netzwerkproblem aufgetreten, und wir verwenden Network Path Analyzer, um die Ursache zu verfolgen und zu beheben.

Problem: VM-2 kann telnet-Package (OCI zu Internet) nicht installieren.

Hinweis: Telnet ist ein Netzwerkprotokoll und ein Befehlszeilentool, mit dem Sie remote auf Geräte über ein Netzwerk zugreifen und diese verwalten können. Es wird auch für grundlegende Netzwerktests verwendet (z. B. um zu prüfen, ob ein Port geöffnet ist).

Prüfen Sie, ob telnet auf VM-2 installiert werden kann.
1. Melden Sie sich bei VM-2 an, und führen Sie den folgenden Befehl aus, um telnet zu installieren.
```
sudo yum install telnet
```
2. Geben Sie y ein, und drücken Sie die Eingabetaste, um fortzufahren.
3. Die Installation ist fehlgeschlagen. VM-2 versuchte, eine Verbindung zum regionalen YUM-Repository (yum.me-jeddah-1.oci.oraclecloud.com) herzustellen, konnte es jedoch nicht erreichen.
1. Führen Sie den folgenden Befehl aus, um die IP des yum-Repositorys zu suchen.
```
dig yum.me-jeddah-1.oci.oraclecloud.com
```
2. Notieren Sie sich die IP-Adressen. VM-2 kann diese öffentlichen IPs nicht erreichen. Dies deutet darauf hin, dass es keinen Internetzugriff über ein NAT-Gateway oder privaten Zugriff auf Oracle Services Network über ein Servicegateway zum Erreichen des yum-Repositorys hat, oder dass der abgehende Traffic blockiert wird. Um das Problem auf den Punkt zu bringen, werden wir in den nächsten Schritten mit der NPA-Analyse fortfahren.
Gehen Sie zur OCI-Konsole.
1. Stellen Sie sicher, dass Sie in der richtigen Region sind.
2. Klicken Sie in der oberen linken Ecke auf das Hamburger-Menü (≡).
3. Klicken Sie auf Networking.
4. Klicken Sie auf Network Path Analyzer.
Klicken Sie auf Pfadanalyse erstellen.
Konfigurieren Sie nun die Details des zu testenden Netzwerkflusses.
1. Geben Sie Name als test-vm2-to-internet-port443 ein.
2. Wählen Sie Protokoll als TCP aus.
Wir beginnen mit dem Ausfüllen der Quellinformationen, die in diesem Fall VM-2 ist.
1. Wählen Sie OCI-Ressource suchen aus.
2. Wählen Sie Quelltyp als Compute-Instanz (VNIC) aus.
3. Wählen Sie VM-2 aus der Liste.
4. Wählen Sie VNIC aus, die den Traffic generiert (dieser wird bereits automatisch gefüllt, wenn die VM nur eine VNIC enthält).
5. Wählen Sie Quelladresse IPv4 als 192.168.0.20 aus (dies wird auch automatisch ausgefüllt, wenn nur eine IPv4-Adresse vorhanden ist).
1. Klicken Sie auf Erweiterte Einstellungen anzeigen.
2. Hier können Sie bei Bedarf den Quellport angeben. In diesem Beispiel lassen Sie ihn auf Jeden Port verwenden gesetzt.
Als nächstes füllen wir die Zielinformationen aus, in diesem Fall das Internet, insbesondere die öffentlichen IPs des yum-Repositorys (192.29.119.92 und 192.29.125.93), die wir mit nur einer von ihnen testen werden.
1. Wählen Sie IP-Adresse eingeben aus.
2. Geben Sie die Zieladresse IPv4 192.29.119.92 ein.
3. Geben Sie als Zielport 443 ein, da der Zugriff auf das Repository über HTTPS erfolgt.
1. Um sowohl Vorwärts- als auch Rückwärtsverkehr zu analysieren, behalten Sie die Richtung als Bidirektional bei.
2. Klicken Sie auf Analyse ausführen.
1. Die Verbindungsdetails werden angezeigt, wenn die Analyse ausgeführt wird.
2. Scrollen Sie nach unten, um den Fortschritt der Analyse zu verfolgen, und warten Sie, bis sie abgeschlossen ist. Dies kann ein oder zwei Minuten dauern.
Die Analyse ist abgeschlossen. Beginnen wir mit der Prüfung des Ergebnisses Forward path.
1. Die Analyse zeigt, dass VM-2 das Internet nicht erreichen kann.
2. Dieses Segment hebt eine fehlende Konfiguration hervor, die verhindert, dass Traffic VCN-2 beendet.
3. Um weitere Informationen zu erhalten, klicken Sie auf Diagramminformationen anzeigen.
4. In dieser Tabelle werden der Routingablauf und die Sicherheitsprüfungen bei jedem Schritt im Pfad aufgeführt. Wie bemerkt, ist der Fluss direkt, da es keinen Zwischenhopf dazwischen gibt.
5. Wenn Sie vergrößern, wird angezeigt, dass für diesen Traffic Keine Route definiert ist.
1. Erweitern Sie dasselbe Segment, um weitere Informationen zu erhalten.
2. Es ist kein Routing konfiguriert, um Traffic über das Internet zu senden. Um dies zu beheben, müssen wir der Routentabelle des Subnetzes VM-2 (Standardroutentabelle für VCN-2) eine Regel hinzufügen. Notieren Sie sich diese Regel, da wir sie in den nächsten Aufgaben prüfen werden. An dieser Stelle haben wir die Ursache des Problems identifiziert.
3. Beachten Sie, dass die Sicherheit Zulässig ist.
  1. (3.a) Egress-Traffic ist erlaubt, hier keine Probleme.
  2. (3.b) Ingress-Traffic ist in diesem Fall nicht relevant, da sich das Szenario nur auf ausgehenden Traffic konzentriert.
1. Der Rückgabepfad wird nicht analysiert, da die Prüfung des Weiterleitungspfads nicht erfolgreich war.
2. Klicken Sie auf Analyse speichern.
3. Sie können die Analyse jederzeit erneut aufrufen und ausführen. Wir werden es später in diesem Tutorial erneut ausführen, nachdem wir das Problem behoben haben.
1. Navigieren Sie zu VCN-2, in dem sich die Quell-VM befindet.
2. Klicken Sie auf Routing.
3. Klicken Sie auf Standardroutentabelle für VCN-2.
Hinweis: Routentabellen werden auf Subnetzebene ausgeführt. Das bedeutet, dass alle in der Tabelle definierten Regeln für alle Ressourcen innerhalb dieses Subnetzes gelten. Routentabellen können auch mit bestimmten VNICs oder IP-Adressen über das Routing pro Ressource verknüpft werden. Dies ist jedoch für unser Tutorial nicht relevant. Weitere Informationen finden Sie unter Routing pro Ressource.
1. Klicken Sie auf Routingregeln.
2. Derzeit ist nur eine Routingregel konfiguriert, um Traffic an VCN-1 weiterzuleiten.
3. Um den Internetzugriff zu aktivieren, klicken Sie auf Routingregeln hinzufügen.
1. Wählen Sie unter "Zieltyp" die Option NAT-Gateway aus.
2. Geben Sie 0.0.0.0/0 als Ziel-CIDR-Block ein.
3. Wählen Sie das zuvor erstellte NAT-Gateway aus.
4. Klicken Sie auf Routingregeln hinzufügen.
Melden Sie sich bei VM-2 an, und versuchen Sie erneut, telnet zu installieren.
1. Führen Sie den folgenden Befehl aus.
```
sudo yum install telnet
```
2. Die Installation ist Complete!.
Gehen Sie zur Analyse zurück, um eine weitere Ausführung auszuführen, und prüfen Sie, ob das Problem behoben ist.
Klicken Sie auf Analysieren.
Warten Sie, bis die Analyse abgeschlossen ist.
Die Analyse ist abgeschlossen. Prüfen Sie das Ergebnis Forward path.
1. Im Status wird jetzt Erreichbar angezeigt.
2. Hop 2 ist jetzt erfolgreich, da eine Routingregel hinzugefügt wurde, die Traffic an das NAT-Gateway sendet.
3. Klicken Sie auf Diagramminformationen anzeigen.
4. Sie können sehen, dass der Routingstatus für Hop 2 jetzt Weitergeleitet lautet (zuvor war es Keine Route).
Wenn wir den Rückkehrpfad überprüfen, können wir sehen, dass er auch erfolgreich ist.

Aufgabe 4: VCN-Flowlogs analysieren

VCN-Flowlogs bieten einen zusätzlichen Einblick in das Trafficverhalten. Mit diesem Service können Sie einen Drilldown zum tatsächlichen Traffic durchführen, der auf jede VNIC trifft. Dabei wird angegeben, ob er basierend auf der Sicherheitsliste und den NSG-Regeln akzeptiert oder abgelehnt wurde. So können Sie sicherheitsrelevante Probleme beheben.

Neben der Fehlerbehebung sind VCN-Flowlogs für die Überwachung der Netzwerkaktivität von entscheidender Bedeutung, da sie Quell-/Ziel-IPs, Ports, Protokolle und Zeitstempel erfassen und die detaillierte Telemetrie bereitstellen, die auch für Audits und Sicherheitsuntersuchungen erforderlich ist.

Beispiel

Als Beispiel verwenden wir die folgende Architektur.

Hinweis: In diesem Beispiel konzentrieren wir uns nur auf die Protokollierung an dem Punkt Y, an dem sich das Ziel befindet. Sie können jedoch dieselben Schritte anwenden, um Logs an Punkt X (der Quelle des Traffics) zu aktivieren und zu analysieren, um einen zusätzlichen Einblick in den gesamten Trafficfluss zu erhalten.

Es ist ein Netzwerkproblem aufgetreten, und wir verwenden VCN-Flowlogs, um die Ursache zu verfolgen und zu beheben.

Problem: VM-1 kann nicht auf eine Website zugreifen, die auf VM-2 gehostet wird.

Melden Sie sich bei VM-2 an, und führen Sie den folgenden Befehl aus, um zu prüfen, ob die Website lokal ausgeführt wird.
```
curl localhost
```
Melden Sie sich bei VM-1 an, und führen Sie denselben Befehl aus, um die Konnektivität zu VM-2 zu testen.
```
curl 192.168.0.20
```
Sie sehen, dass die Anforderung nicht erfolgreich ist. In den nächsten Schritten verwenden wir VCN-2-Flowlogs, um die Ursache zu untersuchen.
Lassen Sie uns nun die Protokolle aktivieren. Zunächst erstellen wir einen Capture-Filter. Dabei handelt es sich um ein einfaches Regelset, das in OCI verwendet wird, um zu bestimmen, welcher Netzwerktraffic für das Logging erfasst oder an virtuelle Testzugriffspunkte (VTAPs) gespiegelt werden soll.
1. Melden Sie sich bei der OCI-Konsole an, und stellen Sie sicher, dass Sie sich in der richtigen Region befinden.
2. Klicken Sie in der oberen linken Ecke auf das Hamburger-Menü (≡).
3. Klicken Sie auf Networking.
4. Klicken Sie auf Filter erfassen.
Klicken Sie auf Erfassungsfilter erstellen.
1. Geben Sie vcn-2-private-sn-logs als Name ein.
2. Wählen Sie Flow-Log-Erfassungsfilter als Filtertyp aus.
3. Legen Sie die Samplingrate auf 100% fest. Dies definiert den Prozentsatz der Netzwerkflüsse, die erfasst werden sollen. In diesem Fall möchten wir den gesamten Datenverkehr protokollieren.
1. Behalten Sie bei allen anderen Einstellungen die Standardwerte bei.
2. Klicken Sie auf Erfassungsfilter erstellen.
Nachdem der Erfassungsfilter erstellt wurde, klicken Sie auf Kopieren, um die zugehörige OCID zu kopieren, wie Sie sie in den nächsten Schritten benötigen.
Jetzt können wir die Logs aktivieren.
1. Navigieren Sie zu VCN-2.
2. Öffnen Sie das private Subnetz, in dem sich VM-2 befindet.
3. Klicken Sie auf Monitoring.
4. Scrollen Sie nach unten zum Abschnitt Logs.
5. Klicken Sie auf die drei Punkte (••••) neben der Kategorie Ablauflogs.
6. Klicken Sie auf Log aktivieren.
1. Wählen Sie Loggruppe aus. Wenn noch keine Loggruppe vorhanden ist, erstellen Sie eine neue Loggruppe.
2. Logname wird automatisch ausgefüllt.
3. Fügen Sie die zuvor kopierte Erfassungsfilter-OCID ein.
4. Klicken Sie auf Log aktivieren.
Ablauflogs sind jetzt Aktiv.
Wiederholen Sie denselben Test, um Traffic zu generieren, indem Sie den folgenden Befehl in VM-1 ausführen.
```
curl 192.168.0.20
```
Kehren Sie zum Abschnitt Logs zurück, und klicken Sie auf Logname, der zuvor erstellt wurde.
1. Scrollen Sie nach unten, und Sie sehen Protokolle, die den Datenverkehr anzeigen, der in das Netzwerk eintritt oder dieses verlässt.
2. Klicken Sie auf Aktionen.
3. Klicken Sie auf Mit Logsuche explorieren, um erweiterte Filter anzuwenden und die Logergebnisse einzugrenzen.
1. Wenden Sie die folgenden Filter an, um die Testverbindung abzugleichen.
  - Quell-IP (VM-1): data.sourceAddress = '10.0.0.10'.
  - Ziel-IP (VM-2): data.destinationAddress = '192.168.0.20'.
  - Zielport (HTTP): data.destinationPort = 80.
2. Passen Sie den Zeitraum bei Bedarf in Nach Zeit filtern an, oder übernehmen Sie ihn als Standard Letzte 5 Minuten.
3. Klicken Sie auf Suchen.
1. Prüfen Sie die Ergebnisse, die Ihren Suchkriterien entsprechen.
2. Blenden Sie die Datensatzdetails ein.
Für diesen bestimmten Datensatz können Sie detaillierte Informationen zu diesem Verkehrswert anzeigen. Zu beachtende Schlüsselfelder:
1. Zeitstempel: Das genaue Datum und die genaue Uhrzeit, zu der der Traffic das Subnetz erreicht hat.
2. Verbindungsdetails: Beispiel: Quell-IP-Adresse, Ziel-IP-Adresse und Portnummer.
3. Aktion: Zeigt an, wie der Traffic verarbeitet wurde. In diesem Fall war er REJECT. Dadurch wird die Ursache des Problems bestätigt. Es ist keine Sicherheitsregel vorhanden, um HTTP-Traffic an VM-2 zuzulassen.
Damit HTTP-Traffic auf VM-2 zugreifen kann, haben Sie zwei Optionen:
- Sicherheitsliste: Wird auf Subnetzebene angewendet. Das bedeutet, dass alle VNICs in einem Subnetz demselben Set von Sicherheitslisten unterliegen.
- NSG: Wird auf Ressourcenebene (VNIC-Ebene) angewendet.
Hier wird er aus der Standardsicherheitsliste zugelassen, die bereits mit dem Subnetz VM-2 verknüpft ist.
1. Navigieren Sie zu VCN-2, wo sich die Ziel-VM befindet.
2. Klicken Sie auf Sicherheit.
3. Klicken Sie auf Standardsicherheitsliste für VCN-2.
1. Klicken Sie auf Sicherheitsregeln.
2. In der Tabelle wird angezeigt, welcher Traffic zulässig ist. Alles andere, einschließlich HTTP, wird standardmäßig abgelehnt, da es keine Regel gibt, die es zulässt. Deshalb kann VM-1 nicht auf die Website zugreifen, die auf VM-2 gehostet wird.
3. Um dies zu beheben, klicken Sie auf Ingress-Regeln hinzufügen.
1. Geben Sie 10.0.0.0/16 als Quell-CIDR ein (dies ist das CIDR für VCN-1).
2. Wählen Sie TCP als IP Protocol aus.
3. Setzen Sie 80 auf Zielport.
4. Klicken Sie auf Ingress-Regeln hinzufügen.
Melden Sie sich bei VM-1 an, und führen Sie denselben Befehl aus, um die Konnektivität zu VM-2 zu testen.
```
curl 192.168.0.20
```
Sie sollten jetzt sehen, dass die Website erreichbar ist.
Kehren Sie zu den Logs zurück, und wiederholen Sie dieselben Schritte wie zuvor, um eine neue Suche durchzuführen.
1. Wenden Sie die folgenden Filter an, um die Testverbindung abzugleichen.
  - Quell-IP (VM-1): data.sourceAddress = '10.0.0.10'.
  - Ziel-IP (VM-2): data.destinationAddress = '192.168.0.20'.
  - Zielport (HTTP): data.destinationPort = 80.
2. Passen Sie den Zeitbereich bei Bedarf an, oder übernehmen Sie ihn als Standardwert (Letzte 5 Minuten).
3. Klicken Sie auf Suchen.
1. Prüfen Sie die Ergebnisse, die Ihren Suchkriterien entsprechen.
2. Blenden Sie die Datensatzdetails ein.
Für diesen bestimmten Datensatz können Sie detaillierte Informationen zu diesem Verkehrswert anzeigen. Zu beachtende Schlüsselfelder:
1. Zeitstempel: Das genaue Datum und die genaue Uhrzeit, zu der der Traffic das Subnetz erreicht hat.
2. Verbindungsdetails: Beispiel: Quell-IP, Ziel-IP und Portnummer.
3. Aktion: Zeigt an, wie der Traffic verarbeitet wurde. Nachdem Sie das Problem behoben haben, sollten Sie jetzt sehen, dass der Traffic ACCEPT lautet.

Nächste Schritte

Wir haben untersucht, wie Sie grundlegende Netzwerkprobleme in OCI beheben können, indem wir Architektur-, Routing- und Sicherheitskonfigurationen untersuchen. Diese Kernprüfungen helfen bei der Lösung der häufigsten Konnektivitätsprobleme. Das nächste Tutorial konzentriert sich auf erweiterte Szenarien und realere Anwendungsfälle.

Bestätigungen

Authors - Anas Abdallah (Cloud Networking Specialist), Sachin Sharma (Cloud Networking Specialist)

Weitere Lernressourcen

Sehen Sie sich weitere Übungen zu docs.oracle.com/learn an, oder greifen Sie auf weitere kostenlose Lerninhalte im Oracle Learning YouTube-Kanal zu. Besuchen Sie außerdem education.oracle.com/learning-explorer, um ein Oracle Learning Explorer zu werden.

Die Produktdokumentation finden Sie im Oracle Help Center.

Titel und Copyright-Informationen

Troubleshoot Basic Network Issues in Oracle Cloud Infrastructure

G40749-01

Oracle und/oder verbundene Unternehmen.