Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Problembehandlung bei VPC-Netzwerken

Netzwerküberwachung und Fehlerbehebung

CloudTrail Protokollierung

Alle Konfigurations-API-Operationen und Workflow-Läufe, die VPC-Netzwerke verwenden, sind angemeldet CloudTrail. Wird verwendet CloudTrail , um Konfigurationsänderungen zu überprüfen und nachzuverfolgen, welche Läufe VPC-Netzwerke verwenden.

Fehlerbehebung mit ENI-Flow-Logs

Wenn Ihr Workflow auf externe Ressourcen über das Internet zugreift, können Sie VPC Flow Logs verwenden, um Konnektivität zu überprüfen und Probleme zu diagnostizieren. HealthOmics stellt elastische Netzwerkschnittstellen (ENIs) in Ihren VPC-Subnetzen bereit, um den Datenverkehr von Ihren Workflow-Aufgaben weiterzuleiten. Indem Sie die zugehörigen Flussprotokolle untersuchen ENIs, können Sie den Netzwerkverkehr zu und von externen Zielen verfolgen.

Einrichtung von Flow-Logs zur Fehlerbehebung

Option 1: Flow-Logs auf VPC-Ebene (zur laufenden Überwachung)

Aktivieren Sie Flow-Logs auf Ihrer VPC, um den Datenverkehr aus allen HealthOmics Workflow-Läufen automatisch zu erfassen. Dies ist am besten, wenn Sie viele Workflow-Läufe haben und umfassende Transparenz wünschen, ohne einzelne ENIs Workflow-Läufe nachverfolgen zu müssen.

Fragen Sie CloudWatch Flow-Logs mithilfe von Logs Insights nach Zeitfenster, Ziel-IP oder Verkehrsmustern ab. Sie müssen kein bestimmtes ENI identifizieren IDs.

Option 2: Flow-Logs auf ENI-Ebene (für gezielte Problembehebung)

Aktivieren Sie Flow-Logs nur ENIs dann, wenn Sie nur wenige HealthOmics ENIs in Ihrem Konto haben. Dies ist der kostengünstigste Ansatz und macht es einfach, den Datenverkehr für bestimmte Workflow-Läufe zu isolieren.

Grundlegendes zum VPC Flow Log-Format

VPC Flow Logs verwenden ein durch Leerzeichen getrenntes Format mit den folgenden Feldern:

version account_id interface_id srcaddr dstaddr srcport dstport protocol packets bytes start end action log_status

Feldbeschreibungen:

Beispiele für Flow-Logeinträge:

2 074296239033 eni-0e57c5476efeac402 10.0.130.58 13.226.238.96 40565 443 6 13 1502 1774338927 1774338929 ACCEPT OK
2 074296239033 eni-0e57c5476efeac402 13.226.238.96 10.0.130.58 443 40565 6 8 1024 1774338928 1774338930 ACCEPT OK

Diese Einträge zeigen eine erfolgreiche bidirektionale HTTPS-Kommunikation. Schlüssel IPs: 10.0.130.58 ist der Kunde, von dem ENI HealthOmics in Ihrem Konto erstellt wurde, und 13.226.238.96 ist die externe öffentliche Domain, auf die Ihr Workflow zugreift. Der erste Eintrag ist ausgehender Verkehr und der zweite ist der Rückverkehr. Beide zeigen ACCEPT an, was darauf hinweist, dass der Verkehr von Sicherheitsgruppen zugelassen wurde.

Abfragen von Flow-Logs in CloudWatch Logs Insights

Wenn Flow-Logs in CloudWatch Logs veröffentlicht werden, verwenden Sie CloudWatch Logs Insights, um die Daten abzufragen und zu analysieren.

Finden Sie abgelehnten Traffic (beginnen Sie hier)

fields @timestamp, interfaceId, srcAddr, dstAddr, srcPort, dstPort, protocol, action
| filter action = "REJECT"
| sort @timestamp desc

Wenn dies zu Ergebnissen führt, liegt möglicherweise ein Verbindungsproblem vor. Die abgelehnten Einträge zeigen, welcher Datenverkehr von Sicherheitsgruppen oder Netzwerken blockiert wird ACLs.

Finden Sie den Verkehr zu einer bestimmten externen IP

Lösen Sie die Domain zunächst mit nslookup oder in eine IP-Adresse aufdig:

$ nslookup ftp.ncbi.nlm.nih.gov
Server:  127.53.53.53
Address: 127.53.53.53#53

Non-authoritative answer:
ftp.ncbi.nlm.nih.gov    canonical name = ftp.wip.ncbi.nlm.nih.gov.
Name:    ftp.wip.ncbi.nlm.nih.gov
Address: 130.14.250.10
Name:    ftp.wip.ncbi.nlm.nih.gov
Address: 130.14.250.11

Der „Server“ und die „Adresse“ oben sind Ihr DNS-Resolver. Die Adressen unter „Nicht autoritative Antwort“ (130.14.250.10 und 130.14.250.11) sind die tatsächlichen Adressen für die Domain. IPs

Fragen Sie Flow-Logs mit einem Präfix ab, das einer beliebigen IP in diesem Bereich entspricht:

fields @timestamp, interfaceId, srcAddr, dstAddr, srcPort, dstPort, protocol, action
| filter dstAddr like "130.14.250"
| sort @timestamp desc

Dies entspricht jeder IP, die mit 130.14.250 beginnt, und erfasst den gesamten Datenverkehr IPs in diesem Subnetz.

Finden Sie HTTPS-Verkehr zu externen Zielen

fields @timestamp, interfaceId, srcAddr, dstAddr, srcPort, dstPort, protocol, action
| filter dstPort = 443 and protocol = 6
| filter not (dstAddr like /^10\./ or dstAddr like /^172\./ or dstAddr like /^192\.168\./)
| sort @timestamp desc

Der zweite Filter schließt private IP-Bereiche aus und zeigt nur Datenverkehr zu externen (öffentlichen) Zielen an.

Allgemeine Ablaufprotokollmuster und Probleme

Bewährte Methoden für die Fehlerbehebung bei Flow-Protokollen

Fehlerbehebung bei der Konfiguration

Die Konfiguration blieb im Status CREATING hängen

Ursache: Die Bereitstellung von Netzwerkressourcen kann mehrere Minuten dauern.

Lösung: Warten Sie bis zu 10 Minuten. Wenn der Status nicht zu AKTIV wechselt, überprüfen Sie Folgendes:

Die Ausführung kann mit dem VPC-Netzwerk nicht gestartet werden

Ursache: Die Konfiguration ist möglicherweise nicht AKTIV, oder es liegen Probleme mit der Netzwerkverbindung vor.

Lösung:

Konfiguration kann nicht gelöscht werden

Ursache: Die Konfiguration wird von aktiven Workflow-Ausführungen verwendet.

Lösung: Warten Sie, bis alle Läufe, die die Konfiguration verwenden, abgeschlossen sind, und versuchen Sie dann erneut, den Löschvorgang durchzuführen.

Die mit dem Dienst verknüpfte Rolle kann nicht gelöscht werden

Ursache: In Ihrem Konto sind aktive VPC-Konfigurationen vorhanden.

Lösung: Löschen Sie zuerst alle VPC-Konfigurationen und dann die serviceverknüpfte Rolle.

Der Workflow kann keine Verbindung zur externen Ressource herstellen

Ursache: Fehlkonfiguration der Sicherheitsgruppe oder der Routingtabelle.

Lösung:

Probleme mit der Netzwerkleistung

Symptom: Langsame Datenübertragung oder Workflow-Timeouts.

Ursache: Einschränkungen des Netzwerkdurchsatzes oder Überlastung des NAT-Gateways.

Lösung:

Der Workflow kann das Internet nicht erreichen

Ursache: Die privaten Subnetze haben möglicherweise keine Route zu einem NAT-Gateway, oder Sicherheitsgruppenregeln blockieren möglicherweise ausgehenden Datenverkehr.

Lösung:

Die Workflow-Ausführung schlägt mit Verbindungsfehlern fehl

Ursache: Der Netzwerkverkehr ist möglicherweise blockiert oder falsch konfiguriert.

Lösung: