Paketspiegelung

Auf dieser Seite erhalten Sie einen Überblick über die Paketspiegelung.

Bei der Paketspiegelung wird Traffic bestimmter Instanzen in Ihrem VPC-Netzwerk (Virtual Private Cloud) geklont und zur Prüfung weitergeleitet. Bei der Paketspiegelung werden alle Traffic- und Paketdaten erfasst, einschließlich Nutzlasten und Header. Die Erfassung kann sowohl für ausgehenden als auch für eingehenden Traffic, nur für eingehenden Traffic oder nur für ausgehenden Traffic konfiguriert werden.

Die Spiegelung erfolgt in den VM-Instanzen, nicht im Netzwerk. Daher wird durch die Paketspiegelung zusätzliche Bandbreite auf den VMs verbraucht.

Die Paketspiegelung ist nützlich, wenn Sie den Sicherheitsstatus beobachten und analysieren müssen. Es wird der gesamte Traffic exportiert, nicht nur der Traffic zwischen den Sampling-Zeiträumen. Sie können beispielsweise eine Sicherheitssoftware verwenden, die gespiegelten Traffic analysiert, um alle Bedrohungen oder Anomalien zu erkennen. Außerdem können Sie den gesamten Datenverkehr untersuchen, um Probleme mit der Anwendungsleistung festzustellen. Weitere Informationen finden Sie in den Beispielen für Anwendungsfälle.

Funktionsweise

Bei der Paketspiegelung wird der Traffic aus gespiegelten Quellen kopiert und an ein Collector-Ziel gesendet. Zur Konfiguration der Paketspiegelung erstellen Sie eine Paketspiegelungsrichtlinie, in der die Quelle und das Ziel angegeben ist.

• Gespiegelte Quellen sind Compute Engine-VM-Instanzen, die Sie durch Angabe von Subnetzen, Netzwerk-Tags oder Instanznamen auswählen können. Wenn Sie ein Subnetz angeben, werden alle vorhandenen und zukünftigen Instanzen in diesem Subnetz gespiegelt. Sie können einen oder mehrere Quelltypen angeben. Wenn eine Instanz mit mindestens einem davon übereinstimmt, wird sie gespiegelt.

  Bei der Paketspiegelung wird Traffic von der Netzwerkschnittstelle einer Instanz in dem Netzwerk erfasst, in dem die Paketspiegelungsrichtlinie gilt. Hat eine Instanz mehrere Netzwerkschnittstellen, werden die anderen Schnittstellen nur dann gespiegelt, wenn eine andere Richtlinie für diesen Zweck konfiguriert wurde.

• Ein Collector-Ziel ist eine Instanzgruppe hinter einem internen Load-Balancer. Instanzen in der Instanzgruppe werden als Collector-Instanzen bezeichnet.

  Wenn Sie das Collector-Ziel angeben, geben Sie den Namen einer Weiterleitungsregel ein, die dem internen Passthrough Network Load Balancer zugeordnet ist. Danach leitet Google Cloud den gespiegelten Traffic an die Collector-Instanzen weiter. Ein interner Load-Balancer für die Paketspiegelung ähnelt anderen internen Load-Balancern, mit der Ausnahme, dass für die Paketspiegelung die Weiterleitungsregel konfiguriert werden muss. Nicht gespiegelter Traffic, der an den Load-Balancer gesendet wird, wird verworfen.

Filtern

Standardmäßig wird bei der Paketspiegelung der gesamte IPv4-Traffic von gespiegelten Instanzen erfasst. Statt den gesamten IPv4-Traffic zu erfassen, können Sie Filter verwenden, um den erfassten Traffic auf den gesamten oder einen Teil des IPv6-Traffics auszuweiten. Mithilfe von Filtern können Sie den gespiegelten Traffic eingrenzen und so die Bandbreite begrenzen, die von gespiegelten Instanzen verwendet wird.

Sie können Filter konfigurieren, um Traffic nach Protokoll, CIDR-Bereichen (IPv4, IPv6 oder beide), der Richtung des Traffics (nur für eingehenden Traffic, nur für ausgehenden Traffic, beide) oder einer Kombination dieser Kriterien zu erfassen.

Richtlinienreihenfolge

Es können mehrere Paketspiegelungsrichtlinien auf eine Instanz angewendet werden. Die Priorität einer Paketspiegelungsrichtlinie ist immer 1000 und kann nicht geändert werden. Identische Richtlinien werden nicht unterstützt. Google Cloud kann Traffic an alle Load-Balancer senden, die mit identischen Paketspiegelungsrichtlinien konfiguriert wurden. Erstellen Sie Richtlinien, deren Filter keine Überschneidungen bei den Adressbereichen haben, damit der gespiegelte Traffic vorhersehbar und konsistent an einen Load-Balancer gesendet wird. Wenn sich Bereiche überschneiden, legen Sie eindeutige Filterprotokolle fest.

Je nach Filter der jeweiligen Richtlinie wählt Google Cloud für jeden Ablauf eine Richtlinie aus. Wenn Sie unterschiedliche Richtlinien haben, verwendet Google Cloud die Richtlinie, die dem gespiegelten Traffic entspricht. Beispielsweise könnten Sie eine Richtlinie haben, die den Filter 198.51.100.3/24:TCP enthält, und eine weitere Richtlinie mit dem Filter 2001:db8::/64:TCP:UDP. Da sich die Richtlinien unterscheiden, gibt es keinen Zweifel darüber, welche Richtlinie von Google Cloud verwendet wird.

Wenn sich Richtlinien jedoch überschneiden, wertet Google Cloud die Filter aus, um die zu verwendende Richtlinie auszuwählen. Beispiel: Sie haben zwei Richtlinien, eine mit einem Filter für 10.0.0.0/24:TCP und eine andere mit einem Filter für 10.0.0.0/16:TCP. Bei diesen Richtlinien liegen Überschneidungen in den CIDR-Bereichen vor.

Bei der Auswahl einer Richtlinie priorisiert Google Cloud Richtlinien, indem die CIDR-Bereichsgröße des Filters verglichen wird.

Google Cloud wählt eine Richtlinie anhand eines Filters aus:

• Wenn Richtlinien unterschiedliche, aber sich überschneidende CIDR-Bereiche und dieselben Protokolle haben, wählt Google Cloud die Richtlinie aus, in der der CIDR-Bereich am genauesten angegeben ist. Angenommen, das Ziel für ein TCP-Paket, das von einer gespiegelten Instanz abgeht, lautet 10.240.1.4 und es gibt zwei Richtlinien mit den folgenden Filtern: 10.240.1.0/24:ALL und 10.240.0.0/16:TCP. Da für 10.240.1.4 die genaueste Übereinstimmung 10.240.1.0/24:ALL ist, verwendet Google Cloud die Richtlinie mit dem Filter 10.240.1.0/24:ALL.

• Wenn Richtlinien denselben CIDR-Bereich mit sich überschneidenden Protokollen angeben, wählt Google Cloud eine Richtlinie mit dem spezifischsten Protokoll aus. Die folgenden Filter haben beispielsweise denselben Bereich, aber die Protokolle überschneiden sich: 10.240.1.0/24:TCP und 10.240.1.0/24:ALL. Für übereinstimmenden TCP-Traffic verwendet Google Cloud die Richtlinie 10.240.1.0/24:TCP. Die Richtlinie 10.240.1.0/24:ALL gilt für übereinstimmenden Traffic für alle anderen Protokolle.

• Wenn Richtlinien denselben CIDR-Bereich, aber unterschiedliche Protokolle haben, überschneiden sich diese Richtlinien nicht. Google Cloud verwendet die Richtlinie, die dem Protokoll des gespiegelten Traffics entspricht. Beispiel: Sie haben möglicherweise eine Richtlinie für 2001:db8::/64:TCP und eine weitere für 2001:db8::/64:UDP. Abhängig vom Protokoll des gespiegelten Traffics verwendet Google Cloud entweder die TCP- oder die UDP-Richtlinie.

• Wenn Richtlinien mit Überschneidungen denselben genauen Filter enthalten, sind sie identisch. In diesem Fall wählt Google Cloud möglicherweise jedes Mal dieselbe Richtlinie oder eine andere Richtlinie aus, wenn der übereinstimmende Traffic anhand dieser Richtlinien neu bewertet wird. Wir empfehlen, identische Paketspiegelungsrichtlinien nicht zu erstellen.

VPC-Flusslogs

VPC-Flusslogs protokollieren keine gespiegelten Pakete. Wenn sich eine Collector-Instanz in einem Subnetz befindet, für das VPC-Flusslogs aktiviert sind, wird der an die Collector-Instanz gesendete Traffic protokolliert, einschließlich des Traffics von gespiegelten Instanzen. Das heißt, wenn die ursprüngliche IPv4- oder IPv6-Zieladresse mit der IPv4- oder IPv6-Adresse der Collector-Instanz übereinstimmt, wird der Fluss protokolliert.

Weitere Informationen zu VPC-Flusslogs finden Sie unter VPC-Flusslogs verwenden.

Haupteigenschaften

In der folgenden Liste werden Einschränkungen oder Verhaltensweisen bei der Paketspiegelung beschrieben, die Ihnen vor der Verwendung unbedingt bekannt sein müssen:

• In jeder Paketspiegelungsrichtlinie werden gespiegelte Quellen und ein Collector-Ziel definiert. Du musst die folgenden Regeln einhalten:

  • Alle gespiegelten Quellen müssen sich im selben Projekt, VPC-Netzwerk und in Google Cloud befinden.
  • Ein Collector-Ziel muss sich in derselben Region wie die gespiegelten Quellen befinden. Ein Collector-Ziel kann sich entweder im selben VPC-Netzwerk wie die gespiegelten Quellen oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering mit dem Netzwerk der gespiegelten Quellen verbunden ist.
  • Jede Spiegelungsrichtlinie kann nur auf ein einzelnes Collector-Ziel verweisen. Auf ein einzelnes Collector-Ziel kann jedoch von mehreren Spiegelungsrichtlinien verwiesen werden.

• Alle Layer-4-Protokolle werden von der Paketspiegelung unterstützt.

• Traffic in derselben Netzwerkschnittstelle einer VM-Instanz kann nicht gespiegelt und erfasst werden, da dies eine Spiegelungsschleife zur Folge hätte.

• Wenn Sie Traffic zwischen Pods auf demselben GKE-Knoten (Google Kubernetes Engine) spiegeln möchten, müssen Sie für den Cluster die knoteninterne Sichtbarkeit aktivieren.

• Verwenden Sie Filter, um die IPv6-CIDR-Bereiche des IPv6-Traffics anzugeben, den Sie spiegeln möchten, um IPv6-Traffic zu spiegeln. Sie können den gesamten IPv6-Traffic mit einem CIDR-Bereichsfilter von ::/0 spiegeln. Sie können den gesamten IPv4- und IPv6-Traffic mit dem folgenden durch Kommas getrennten CIDR-Bereichsfilter spiegeln: 0.0.0.0/0,::/0.

• Durch die Spiegelung von Traffic wird Bandbreite in der gespiegelten Instanz verbraucht. Wenn in einer gespiegelten Instanz beispielsweise der eingehende Traffic 1 Gbit/s und der ausgehende Traffic 1 Gbit/s ausmacht, beträgt der Traffic in den Instanzen insgesamt 1 Gbit/s eingehenden und 3 Gbit/s ausgehenden Traffic (1 Gbit/s regulärer ausgehender Traffic und 2 Gbit/s gespiegelter ausgehender Traffic). Sie können Filter verwenden, um den erfassten Traffic einzuschränken.

• Die Kosten für die Paketspiegelung hängen davon ab, welchen Umfang der ausgehende Traffics von einer gespiegelten Instanz zu einer Instanzgruppe hat und ob der Traffic zwischen Zonen übertragen wird.

• Die Paketspiegelung wird sowohl auf eingehenden als auch auf ausgehenden Traffic angewendet. Wenn zwei VM-Instanzen, die gespiegelt werden, sich gegenseitig Traffic senden, erfasst Google Cloud zwei Versionen desselben Pakets. Sie können dieses Verhalten ändern, indem Sie festlegen, dass nur eingehende oder nur ausgehende Pakete gespiegelt werden.

• Es gibt eine maximale Anzahl von Paketspiegelungsrichtlinien, die Sie für ein Projekt erstellen können. Weitere Informationen finden Sie bei den Kontingenten pro Projekt auf der Seite Kontingente.

• Wie viele gespiegelte Quellen Sie maximal für eine Paketspiegelungsrichtlinie angeben können, hängt vom Quelltyp ab:

  • 5 Subnetze
  • 5 Tags
  • 50 Instanzen

• Die maximale Anzahl an Paketspiegelungsfiltern beträgt 30, also die Anzahl der IPv4- und IPv6-Adressbereiche multipliziert mit der Anzahl der Protokolle. Sie können beispielsweise 30 Bereiche und 1 Protokoll angeben, also 30 Filter. Sie können jedoch nicht 30 Bereiche und 2 Protokolle angeben, also 60 Filter und damit mehr als die maximale Anzahl.

• Bei der Paketspiegelung wird Ihnen die verarbeitete Datenmenge in Rechnung gestellt. Weitere Informationen finden Sie in den Preisen von Paketspiegelung.

  Außerdem werden Ihnen alle erforderlichen Komponenten und ausgehender Traffic in Rechnung gestellt, die mit der Paketspiegelung zusammenhängen. Beispiel: Die Instanzen, mit denen Traffic erfasst wird, werden zum regulären Preis abgerechnet. Wenn der Traffic bei der Paketspiegelung zwischen Zonen übertragen wird, entstehen Ihnen außerdem Kosten für den ausgehenden Traffic. Einzelheiten zu den Preisen finden Sie auf der zugehörigen Preisseite.

• Gespiegelter Traffic wird nur verschlüsselt, wenn die VM diesen Traffic auf Anwendungsebene verschlüsselt. Während VM-zu-VM-Verbindungen in VPC-Netzwerken und Peering-VPC-Netzwerken verschlüsselt werden, erfolgt die Ver- und Entschlüsselung in den Hypervisoren. Aus Sicht der VM ist dieser Traffic nicht verschlüsselt.

Anwendungsfälle

In den folgenden Abschnitten wird anhand von realen Szenarien beschrieben, in welchen Fällen Sie die Paketspiegelung verwenden könnten.

Unternehmenssicherheit

Sicherheits- und Netzwerktechnikteams müssen dafür Sorge tragen, dass sie alle Anomalien und Bedrohungen erkennen, die auf Sicherheitsverletzungen und Angriffe hindeuten könnten. Sie spiegeln den gesamten Traffic, sodass sie verdächtige Datenströme umfassend analysieren können. Da sich Angriffe über mehrere Pakete erstrecken können, müssen die Sicherheitsteams in der Lage sein, alle Pakete jedes Datenstroms abzurufen.

Für die folgenden Sicherheitstools zum Beispiel müssen Sie mehrere Pakete erfassen:

• Bei IDS (Intrusion Detection System) müssen mehrere Pakete eines einzelnen Datenstroms mit einer Signatur übereinstimmen, sodass das jeweilige Tool anhaltende Bedrohungen erkennen kann.

• DPI-Engines (Deep Packet Inspection) prüfen Paketnutzlasten, um Protokollanomalien zu erkennen.

• Bei der Netzwerkforensik für PCI-Compliance und andere regulatorische Anwendungsfälle müssen die meisten Pakete geprüft werden. Die Paketspiegelung bietet eine Lösung zum Erfassen verschiedener Angriffsvektoren, z. B. unregelmäßige Kommunikation oder versuchte, aber erfolglose Kommunikation.

Monitoring der Anwendungsleistung

Netzwerktechniker können gespiegelten Traffic nutzen, um Leistungsprobleme zu beheben, die von Anwendungs- und Datenbankteams gemeldet wurden. Um Netzwerkprobleme zu erkennen, können Netzwerktechniker nachsehen, welche Daten weitergeleitet werden, statt sich auf Anwendungslogs verlassen zu müssen.

Beispielsweise können Netzwerktechniker Daten der Paketspiegelung nutzen, um die folgenden Aufgaben auszuführen:

• Analyse von Protokollen und Verhaltensweisen, sodass sie Probleme wie Paketverlust oder TCP-Zurücksetzungen finden und beheben können.

• Analyse der Traffic-Muster von Remote Desktop, VoIP und anderen interaktiven Anwendungen in Echtzeit. Netzwerktechniker können nach Problemen suchen, die sich nachteilig auf die Nutzer der Anwendung auswirken, z. B. mehrere erneute Paketsendungen oder mehr erneute Verbindungen als erwartet.

Beispiel für Collector-Ziel-Topologien

Die Paketspiegelung können Sie mit verschiedenen Konfigurationen nutzen. In den folgenden Beispielen sind die Speicherorte der Collector-Ziele sowie die Richtlinien für verschiedene Paketspiegelungskonfigurationen dargestellt, z. B. VPC-Netzwerk-Peering und freigegebene VPC.

Collector-Ziel im selben Netzwerk

Im folgenden Beispiel sehen Sie eine Paketspiegelungskonfiguration, bei der sich die gespiegelte Quelle und das Collector-Ziel im selben VPC-Netzwerk befinden.

Paketspiegelungsrichtlinie, bei der sich alle Ressourcen im selben VPC-Netzwerk befinden (zum Vergrößern anklicken)

Im obigen Diagramm ist die Paketspiegelungsrichtlinie so konfiguriert, dass mirrored-subnet gespiegelt und der gespiegelte Traffic an den internen Passthrough Network Load Balancer gesendet wird. Google Cloud spiegelt den Traffic für vorhandene und zukünftige Instanzen im Subnetz. Der gesamte Traffic in und aus Richtung Internet, lokale Hosts oder Google-Dienste wird gespiegelt.

Collector-Ziel in einem Peer-Netzwerk

Sie können ein zentralisiertes Collector-Modell erstellen, bei dem Instanzen in verschiedenen VPC-Netzwerken gespiegelten Traffic an ein Collector-Ziel in einem zentralen VPC-Netzwerk senden. Auf diese Weise können Sie einen einzelnen Ziel-Collector verwenden.

Im folgenden Beispiel befindet sich der interne Passthrough Network Load Balancer collector-load-balancer in der Region us-central1 im VPC-Netzwerk network-a in project-a. Dieser Ziel-Collector kann von zwei Paketspiegelungsrichtlinien verwendet werden:

• policy-1 erfasst Pakete aus gespiegelten Quellen in der Region us-central1 im network-a-VPC-Netzwerk in project-a und sendet sie an das Ziel collector-load-balancer.

• policy-2 erfasst Pakete aus gespiegelten Quellen in der Region us-central1 im network-b-VPC-Netzwerk in project-b und sendet sie an dasselbe collector-load-balancer-Ziel.

Es sind zwei Spiegelungsrichtlinien erforderlich, da gespiegelte Quellen in verschiedenen VPC-Netzwerken vorhanden sind.

Paketspiegelungsrichtlinien in einem zentralen Netzwerk, das über Peering mit anderen Netzwerken verbunden ist, die gespiegelte Quellen enthalten (zum Vergrößern anklicken)

Im obigen Diagramm erfasst das Collector-Ziel gespiegelten Traffic aus Subnetzen in zwei verschiedenen Netzwerken. Alle Ressourcen (Quelle und Ziel) müssen sich in derselben Region befinden. Die Einrichtung in network-a ähnelt dem Beispiel, bei dem sich die gespiegelte Quelle und das Collector-Ziel im selben VPC-Netzwerk befinden. policy-1 ist so konfiguriert, dass Traffic von subnet-a erfasst und an collector-ilb gesendet wird.

policy-2 ist in project-a konfiguriert, gibt jedoch subnet-b als gespiegelte Quelle an. Da zwischen network-a und network-b eine Peering-Verbindung besteht, kann der Ziel-Collector Traffic von subnet-b erfassen.

Die Netzwerke befinden sich in unterschiedlichen Projekten und haben möglicherweise unterschiedliche Inhaber. Jeder Inhaber kann die Paketspiegelungsrichtlinie erstellen, wenn er die entsprechenden Berechtigungen hat:

• Wenn die Inhaber von project-a die Paketspiegelungsrichtlinie erstellen, müssen sie im Netzwerk, Subnetz oder in Instanzen die Rolle compute.packetMirroringAdmin haben, um die Spiegelung in project-b festzulegen.

• Wenn die Inhaber von project-b die Paketspiegelungsrichtlinie erstellen, benötigen Sie die Rolle compute.packetMirroringUser in project-a.

Weitere Informationen zum Aktivieren privater Verbindungen zwischen zwei VPC-Netzwerken finden Sie unter VPC-Netzwerk-Peering.

Freigegebene VPC

In den folgenden Szenarien mit freigegebener VPC befinden sich alle gespiegelten Instanzen für das Collector-Ziel im selben freigegebenen VPC-Netzwerk. Die Ressourcen befinden sich zwar alle im selben Netzwerk, können allerdings in verschiedenen Projekten enthalten sein, z. B. im Hostprojekt oder in verschiedenen anderen Dienstprojekten. In den folgenden Beispielen wird gezeigt, wo Paketspiegelungsrichtlinien erstellt werden müssen und wer sie erstellen darf.

Befinden sich sowohl die gespiegelten Quellen als auch das Collector-Ziel im selben Projekt (Host- oder Dienstprojekt), erfolgt die Einrichtung auf ähnliche Weise, als befände sich alles im selben VPC-Netzwerk. Der Projektinhaber kann alle Ressourcen erstellen und die erforderlichen Berechtigungen in diesem Projekt festlegen.

Weitere Informationen finden Sie unter Freigegebene VPC.

Collector-Ziel im Dienstprojekt

Im folgenden Beispiel befindet sich das Collector-Ziel in einem Dienstprojekt, das ein Subnetz im Hostprojekt verwendet. In diesem Fall befindet sich die Richtlinie auch im Dienstprojekt. Die Richtlinie könnte auch im Hostprojekt enthalten sein.

Collector-Ziel im Dienstprojekt (zum Vergrößern anklicken)

Im obigen Diagramm enthält das Dienstprojekt die Collector-Instanzen, die das Collector-Subnetz im freigegebenen VPC-Netzwerk nutzen. Die Paketspiegelungsrichtlinie wurde im Dienstprojekt erstellt und ist so konfiguriert, dass sie Instanzen spiegelt, die eine Netzwerkschnittstelle in subnet-mirrored haben.

Die Paketspiegelungsrichtlinie kann von Nutzern des Dienst- oder Hostprojekts erstellt werden. Dazu müssen Nutzer die Rolle compute.packetMirroringUser im Dienstprojekt haben, in dem sich das Collector-Ziel befindet. Außerdem müssen die Nutzer dazu die Rolle compute.packetMirroringAdmin in den gespiegelten Quellen haben.

Collector-Ziel im Hostprojekt

Im folgenden Beispiel befindet sich das Collector-Ziel im Hostprojekt und die gespiegelten Instanzen in den Dienstprojekten.

Dieses Beispiel lässt sich auf Szenarien anwenden, in denen Entwickler Anwendungen in Dienstprojekten bereitstellen und das freigegebene VPC-Netzwerk nutzen. Sie müssen weder die Netzwerkinfrastruktur noch die Paketspiegelung verwalten. Stattdessen ist ein zentrales Netzwerk- oder Sicherheitsteam, das die Kontrolle über das Hostprojekt und das freigegebene VPC-Netzwerk hat, für die Bereitstellung von Paketspiegelungsrichtlinien zuständig.

Collector-Ziel im Hostprojekt (zum Vergrößern anklicken)

Im obigen Diagramm wird die Paketspiegelungsrichtlinie in dem Hostprojekt erstellt, in dem sich das Collector-Ziel befindet. Die Richtlinie ist so konfiguriert, dass Instanzen im gespiegelten Subnetz gespiegelt werden. VM-Instanzen in Dienstprojekten können das gespiegelte Subnetz verwenden und ihr Traffic wird gespiegelt.

Die Paketspiegelungsrichtlinie kann von Nutzern des Dienst- oder Hostprojekts erstellt werden. Dazu müssen die Nutzer im Dienstprojekt die Rolle compute.packetMirroringUser im Hostprojekt haben. Nutzer im Hostprojekt benötigen die Rolle compute.packetMirroringAdmin für gespiegelte Quellen in den Dienstprojekten.

VM-Instanzen mit mehreren Schnittstellen

In eine Paketspiegelungsrichtlinie können Sie VM-Instanzen mit mehreren Netzwerkschnittstellen aufnehmen. Da mit einer Richtlinie Ressourcen aus einem einzelnen Netzwerk gespiegelt werden können, können Sie keine Richtlinie erstellen, mit der Traffic für alle Netzwerkschnittstellen einer Instanz gespiegelt werden kann. Wenn Sie mehr als eine Netzwerkschnittstelle einer Instanz mit mehreren Netzwerkschnittstellen spiegeln möchten, müssen Sie für jede Schnittstelle eine Paketspiegelungsrichtlinie erstellen, da jede Schnittstelle eine Verbindung zu einem eindeutigen VPC-Netzwerk herstellt.

Nächste Schritte

• Wie Sie Paketspiegelungsrichtlinien erstellen und verwalten, erfahren Sie unter Paketspiegelung verwenden.
• Wie Sie Messwerte aufrufen und bestehende Paketspiegelungsrichtlinien prüfen, erfahren Sie unter Paketspiegelung beobachten.
• Informationen zu internen Passthrough Network Load Balancer finden Sie unter Übersicht über den internen Passthrough Network Load Balancer.
• Eine Liste der Partneranbieter finden Sie unter Paketspiegelungspartneranbieter.