VPC-Flusslogs – Übersicht

VPC-Flusslogs zeichnen eine Stichprobe von Netzwerkflüssen auf, die von VM-Instanzen gesendet und empfangen werden, einschließlich Instanzen, die als Google Kubernetes Engine-Knoten verwendet werden. Diese Logs können für Netzwerk-Monitoring, Forensik, Echtzeit-Sicherheitsanalysen und Kostenoptimierung verwendet werden.

Sie können sich die Flusslogs in Cloud Logging ansehen und in jedes Ziel exportieren, das vom Cloud Logging-Export unterstützt wird.

Flusslogs werden durch Verbindung von Compute Engine-VMs aggregiert und in Echtzeit exportiert. Wenn Sie Pub/Sub abonnieren, können Sie Flusslogs mithilfe von APIs für Echtzeitstreaming analysieren.

Haupteigenschaften

  • VPC-Flusslogs sind Teil der Andromeda-Software, die VPC-Netzwerken zugrunde liegt. VPC-Flusslogs weisen keine Verzögerung oder Leistungseinbußen auf, wenn sie aktiviert sind.
  • VPC-Flusslogs funktionieren in Verbindung mit VPC-Netzwerken, nicht mit Legacy-Netzwerken. Sie aktivieren oder deaktivieren VPC-Flusslogs pro Subnetz. Wenn VPC-Flusslogs für ein Subnetz aktiviert sind, werden Daten von allen VM-Instanzen in diesem Subnetz erfasst.
  • VPC-Flusslogs zeichnen Stichproben der TCP-, UDP-, ICMP-, ESP- und GRE-Flüsse jeder VM auf. Sowohl ein- als auch ausgehende Datenströme werden erfasst. Diese Flüsse können zwischen der VM und einer anderen VM, einem Host in Ihrem lokalen Rechenzentrum, einem Google-Dienst oder einem Host im Internet erfolgen. Wenn ein Fluss durch Stichproben erfasst wird, erstellen VPC-Flusslogs ein Log für den Fluss. Jeder Flusseintrag enthält die im Abschnitt Eintragsformat beschriebenen Daten.
  • VPC-Flusslogs interagieren so mit Firewallregeln:
    • Ausgehende Pakete werden vor ausgehenden Firewallregeln als Stichprobe erfasst. Selbst wenn eine Firewallregel für ausgehenden Traffic ausgehende Pakete ablehnt, können diese Pakete von VPC-Flusslogs als Stichprobe verwendet werden.
    • Eingehende Pakete werden nach eingehenden Firewallregeln als Stichprobe erfasst. Wenn eine eingehende Firewallregel eingehende Pakete ablehnt, werden diese Pakete nicht von VPC-Flusslogs als Stichprobe verwendet.
  • Sie können Filter in VPC-Flusslogs verwenden, um nur bestimmte Logs zu generieren.
  • VPC-Flusslogs unterstützen VMs mit mehreren Netzwerkschnittstellen. Sie müssen VPC-Flusslogs für jedes Subnetz in jeder VPC aktivieren, die eine Netzwerkschnittstelle enthält.
  • Wenn Sie Datenflüsse zwischen Pods auf demselben GKE-Knoten (Google Kubernetes Engine) protokollieren möchten, müssen Sie für den Cluster die knoteninterne Sichtbarkeit aktivieren.

Anwendungsfälle

Netzwerküberwachung

VPC-Flusslogs bietet Ihnen Echtzeitinformationen zum Netzwerkdurchsatz und zur Netzwerkleistung. Sie haben folgende Möglichkeiten:

  • Überwachung des VPC-Netzwerks
  • Durchführung von Netzwerkdiagnosen
  • Filterung der Flusslogs nach VMs und nach Anwendungen, um Trafficänderungen zu verstehen
  • Informationen zum Trafficwachstum für Kapazitätsprognosen

Netzwerknutzung verstehen und Kosten des Netzwerk-Traffics senken

Sie können die Netzwerknutzung mithilfe von VPC-Flusslogs analysieren. Für folgende Netzwerkflüsse ist eine Analyse möglich:

  • Traffic zwischen Regionen und Zonen
  • Traffic in bestimmte Länder im Internet
  • Top Talkers

Auf der Grundlage der Analyse lassen sich dann die Kosten des Netzwerk-Traffics optimieren.

Netzwerkforensik

Sie können VPC-Flusslogs für die Netzwerkforensik nutzen. Zum Beispiel haben Sie bei einem Vorfall die Möglichkeit, Folgendes zu überprüfen:

  • Welche IPs haben mit wem und wann kommuniziert?
  • Wurden IPs gefährdet (durch die Analyse aller eingehenden und ausgehenden Netzwerkflüsse)?

Echtzeit-Sicherheitsanalyse

Sie können die APIs für Echtzeitstreaming (über Pub/Sub) nutzen und in SIEM-Systeme (Security Information and Event Management) einbinden. Auf diese Weise werden Echtzeitüberwachung, Ereigniskorrelation, Analysen und Sicherheitswarnungen ermöglicht.

Logerfassung

Flusslogs werden in bestimmten Intervallen für jede VM-Verbindung erfasst. Alle für ein bestimmtes Intervall und für eine bestimmte Verbindung erfassten Pakete werden für den jeweiligen Zeitraum (Aggregationsintervall) in einem einzigen Flusslogeintrag aggregiert. Diese Daten werden anschließend an Logging gesendet.

Logs werden standardmäßig 30 Tage lang in Logging gespeichert. Wenn Sie Logs länger aufbewahren möchten, können Sie entweder eine benutzerdefinierte Aufbewahrungsdauer festlegen oder sie in eine unterstützte Aufbewahrungsdauer exportieren.

Log-Sampling und -verarbeitung

Google Cloud nimmt Stichproben von ausgehenden und eingehenden Paketen einer VM, um Flusslogs zu generieren. Nicht jedes Paket wird in einem eigenen Logeintrag erfasst. Etwa eines von zehn Paketen wird erfasst, aber diese Abtastrate kann je nach Auslastung der VM geringer sein. Sie können diese Rate nicht anpassen.

Nachdem die Flusslogs erstellt wurden, werden sie von Google Cloud gemäß dem folgenden Verfahren verarbeitet:

  1. Filter: Sie können festlegen, dass nur Logs generiert werden, die bestimmten Kriterien entsprechen. Sie können beispielsweise so filtern, dass nur Logs für eine bestimmte VM oder nur Logs mit einem bestimmten Metadatenwert generiert werden und der Rest verworfen wird.
  2. Aggregation: Die Informationen für die Stichprobenpakete werden über ein konfigurierbares Aggregationsintervall zusammengefasst. Daraus ergibt sich ein Flusslogeintrag.
  3. Flusslog-Probenahme: Dies ist ein zweiter Probenahmeprozess. Von den Flusslogeinträgen werden weitere Stichproben gemäß einem konfigurierbaren Parameter für die Abtastrate erstellt.
  4. Metadaten: Wenn diese Option deaktiviert ist, werden alle Metadatenannotationen verworfen. Wenn Sie Metadaten behalten möchten, können Sie angeben, dass alle Felder oder eine bestimmte Gruppe von Feldern beibehalten werden. Weitere Informationen finden Sie unter Metadatenannotationen.
  5. In Logging schreiben: Die endgültigen Logeinträge werden in Cloud Logging geschrieben.

Da VPC-Flusslogs nicht jedes Paket erfassen, werden verpasste Pakete durch Interpolation aus den erfassten Paketen kompensiert. Dies geschieht bei Paketen, die aufgrund von anfänglichen und benutzerdefinierten Einstellungen für die Probenahme verpasst wurden.

Obwohl Google Cloud nicht jedes Paket erfasst, können die erfassten Logeinträge recht umfangreich sein. Sie können die Sichtbarkeit des Traffics und die Speicherkosten auf Ihre Bedürfnisse abstimmen, indem Sie die folgenden Aspekte der Logerfassung anpassen:

  • Aggregationsintervall: Paketstichproben für ein Zeitintervall werden in einem einzigen Logeintrag zusammengefasst. Dieses Zeitintervall kann 5 Sekunden (Standardeinstellung), 30 Sekunden, 1 Minute, 5 Minuten, 10 Minuten oder 15 Minuten sein.
  • Abtastrate: Vor dem Schreiben in Logging können die Logs abgetastet werden, um deren Anzahl zu reduzieren. Standardmäßig wird das Volumen der Logeinträge auf 0,50 (50 %) skaliert, was bedeutet, dass die Hälfte der Einträge beibehalten wird. Sie können einen Wert zwischen 1.0 (100 %, alle Logeinträge werden beibehalten) und 0.0 (0 %, keine Logeinträge werden beibehalten) festlegen.
  • Metadatenannotationen: Standardmäßig werden Flusslogeinträge mit Metadaten versehen, beispielsweise mit den Namen der Quell- und Ziel-VMs oder der geografischen Region externer Quellen und Ziele. Metadatenannotationen können deaktiviert werden. Sie können auch nur bestimmte Annotationen angeben, um Speicherplatz zu sparen.
  • Filter: Standardmäßig werden Logs für jeden Fluss im Subnetz generiert. Sie können Filter so einrichten, dass nur Logs generiert werden, die bestimmten Kriterien entsprechen.

Metadatenannotationen

Logdatensätze umfassen Basisfelder und Metadatenfelder. Unter Eintragsformat wird angezeigt, welche Felder vom Typ Metadaten sind und welche Typ Basis sind. Die Basisfelder sind immer enthalten. Sie können festlegen, welche Metadatenfelder beibehalten werden.

  • Wenn Sie alle Metadaten auswählen, sind alle Metadatenfelder im Eintragsformat für VPC-Flusslogs enthalten. Wenn dem Eintragsformat neue Metadatenfelder hinzugefügt werden, enthalten die Flusslogs automatisch die neuen Felder.

  • Wenn Sie keine Metadaten auswählen, werden alle Metadatenfelder weggelassen.

  • Wenn Sie benutzerdefinierte Metadaten auswählen, können Sie die Metadatenfelder, die Sie vom übergeordneten Feld einschließen möchten, angeben, z. B. src_vpc, oder ihren vollständigen Namen angeben, z. B. src_vpc.project_id.

    Wenn dem Eintragsformat neue Metadatenfelder hinzugefügt werden, enthalten die Flusslogs diese Felder nur, wenn es sich um ein neues Feld in einem übergeordneten Feld handelt, das Sie angegeben haben.

    • Wenn Sie benutzerdefinierte Metadaten mithilfe von übergeordneten Feldern festlegen, werden den neuen Audit-Logs automatisch die neuen Felder hinzugefügt, wenn dem Eintragsformat in dem übergeordneten Feld neue Metadatenfelder hinzugefügt werden.

    • Wenn Sie benutzerdefinierte Metadaten mit dem vollständigen Namen des Felds angeben, enthalten die Flusslogs keine neuen Felder, wenn dem übergeordneten Feld neue Metadatenfelder hinzugefügt werden.

Informationen zum Anpassen von Metadatenfeldern finden Sie in der gcloud- oder API-Anleitung zum Aktivieren des VPC-Flusslogs beim Erstellen eines Subnetzes.

GKE-Annotationen

Flüsse, die einen Endpunkt in einem GKE-Cluster haben, können mit GKE-Annotationen annotiert werden. Diese können Details zum Cluster, Pod und Dienst des Endpunkts enthalten.

GKE-Dienstannotationen

Traffic, der an einen ClusterIP, NodePort oder LoadBalancer gesendet wird, kann Dienstannotationen empfangen. Wenn er an einen NodePort oder LoadBalancer gesendet wird, empfängt der Fluss die Dienstannotation in beiden Hops der Verbindung.

Traffic, der direkt an den Dienstport eines Pods gesendet wird, wird mit einer Dienstannotation am Zielendpunkt annotiert.

Traffic, der an den Dienstport eines Pods gesendet wird, der mehr als einen Dienst am selben Dienstport unterstützt, wird mit mehreren Diensten am Zielendpunkt annotiert. Dies ist auf zwei Dienste beschränkt. Ist dies der Fall, wird der Endpunkt mit einer speziellen MANY_SERVICES-Markierung versehen.

Pod-Annotationen zu Internettraffic

Der Traffic zwischen einem Pod und dem Internet erhält standardmäßig keine Pod-Annotationen. Bei Paketen im Internet übersetzt der Masquerade-Agent die Pod-IP-Adresse in die Knoten-IP-Adresse, bevor VPC-Flusslogs das Paket sehen. Daher werden in den VPC-Flusslogs keine Informationen über den Pod erkannt und es können keine Pod-Annotationen hinzugefügt werden.

Aufgrund der Masquerade sind Pod-Annotationen nur sichtbar, wenn sich die Ziele entweder innerhalb der Standardziele ohne Masquerade oder in einer benutzerdefinierten nonMasqueradeCIDRs-Liste befinden. Wenn Sie Internetziele in eine benutzerdefinierte nonMasqueradeCIDRs-Liste aufnehmen, müssen Sie eine Möglichkeit bereitstellen, damit die internen Pod-IP-Adressen übersetzt werden können, bevor sie im Internet bereitgestellt werden. Für private und nicht private Cluster können Sie Cloud NAT verwenden. Weitere Informationen finden Sie unter GKE-Interaktion.

Eintragsformat

Logdatensätze umfassen Basisfelder – die wichtigsten Felder jedes Logdatensatzes – sowie Metadatenfelder, die zusätzliche Informationen enthalten. Metadatenfelder können weggelassen werden, um Speicherkosten zu sparen.

Einige Logfelder haben ein Mehrfeldformat mit mehr als einem Datenelement in einem bestimmten Feld. Das Feld connection hat beispielsweise das Format IpConnection. Dieses Format enthält die Quell- und Ziel-IP-Adresse sowie Protokoll und Port in einem einzigen Feld. Diese Felder mit Mehrfeldformat werden unter der Eintragsformattabelle beschrieben.

Feld Feldformat Feldtyp: Basis- oder optionale Metadaten
connection IpConnection
5-Tupel, das diese Verbindung beschreibt.
Basis
Startzeit string
Zeitstempel (RFC 3339-Datumsstring-Format) des ersten beobachteten Pakets während des aggregierten Zeitintervalls.
Basis
end_time string
Zeitstempel (RFC 3339-Datumsstring-Format) des letzten beobachteten Pakets während des aggregierten Zeitintervalls.
Basis
bytes_sent int64
Anzahl der Byte, die von der Quelle an das Ziel gesendet werden.
Basis
packets_sent int64
Anzahl der Pakete, die von der Quelle an das Ziel gesendet werden.
Basis
rtt_msec int64
Latenz, gemessen während des Zeitintervalls, nur für TCP-Flüsse. Die gemessene Latenz ist die Zeit, die zwischen dem Senden einer SEQ und dem Empfang einer entsprechenden ACK vergangen ist. Das Latenzergebnis ist die Summe der Netzwerk-RTT und der durch die Anwendung verbrauchten Zeit.
Basis
reporter string
Die Seite, die den Datenfluss gemeldet hat. Kann entweder SRC oder DEST sein.
Basis
src_instance InstanceDetails
Wenn die Quelle der Verbindung eine VM in der gleichen VPC war, wird dieses Feld mit VPC-Instanzdetails gefüllt. In einer freigegebenen VPC-Konfiguration entspricht project_id dem Projekt, zu dem die Instanz gehört (normalerweise das Dienstprojekt).
Metadaten
dest_instance InstanceDetails
Wenn das Ziel der Verbindung eine VM in der gleichen VPC war, wird dieses Feld mit VPC-Instanzdetails gefüllt. In einer freigegebenen VPC-Konfiguration entspricht project_id dem Projekt, zu dem die Instanz gehört (normalerweise das Dienstprojekt).
Metadaten
src_vpc VpcDetails
Wenn die Quelle der Verbindung eine VM in der gleichen VPC war, wird dieses Feld mit VPC-Netzwerkdetails gefüllt. In einer freigegebenen VPC-Konfiguration entspricht project_id der ID des Hostprojekts.
Metadaten
dest_vpc VpcDetails
Wenn das Ziel der Verbindung eine VM in der gleichen VPC war, wird dieses Feld mit VPC-Netzwerkdetails gefüllt. In einer freigegebenen VPC-Konfiguration entspricht project_id der ID des Hostprojekts.
Metadaten
src_location GeographicDetails
Wenn die Quelle der Verbindung außerhalb der VPC lag, wird dieses Feld mit verfügbaren Standortmetadaten gefüllt.
Metadaten
dest_location GeographicDetails
Wenn das Ziel der Verbindung außerhalb der Google-VPC lag, wird dieses Feld mit verfügbaren Standortmetadaten gefüllt.
Metadaten
src_gke_details GkeDetails
GKE-Metadaten für Quellendpunkte. Nur verfügbar, wenn der Endpunkt GKE ist.
Metadaten
dest_gke_details GkeDetails
GKE-Metadaten für Zielendpunkte. Nur verfügbar, wenn der Endpunkt GKE ist.
Metadaten

Feldformat von IpConnection

Feld Typ Beschreibung
src_ip String IP-Adresse der Quelle
src_port int32 Quellport
dest_ip String IP-Adresse des Ziels
dest_port int32 Zielport
protocol int32 Die IANA-Protokollnummer

Feldformat von InstanceDetails

Feld Typ Beschreibung
project_id string ID des Projekts, das die VM enthält
vm_name string Instanzname der VM
region string Region der VM
zone string Zone der VM

Feldformat von VpcDetails

Feld Typ Beschreibung
project_id String ID des Projekts, das die VPC enthält
vpc_name String VPC, in der die VM ausgeführt wird
subnetwork_name String Subnetzwerk, auf dem die VM ausgeführt wird

Feldformat von GeographicDetails

Feld Typ Beschreibung
continent string Kontinent für externe Endpunkte
country String Land für externe Endpunkte, dargestellt als Ländercodes gemäß ISO 3166-1 Alpha-3.
Region string Region für externe Endpunkte
city string Stadt für externe Endpunkte
asn int32 Die Nummer des autonomen Systems (Autonomous System Number, ASN) des externen Netzwerks, zu dem der Endpunkt gehört.

Feldformat von GkeDetails

Feld Typ Beschreibung
Cluster ClusterDetails GKE-Clustermetadaten.
Pod PodDetails GKE-Pod-Metadaten, die ausgefüllt werden, wenn die Quelle oder das Ziel des Traffics ein Pod ist.
Dienst ServiceDetails GKE-Dienstmetadaten, die nur in Dienstendpunkten ausgefüllt werden. Der Eintrag enthält bis zu zwei Dienste. Wenn mehr als zwei relevante Dienste vorhanden sind, enthält dieses Feld einen einzelnen Dienst mit einer speziellen MANY_SERVICES-Markierung.

Feldformat von ClusterDetails

Feld Typ Beschreibung
cluster_name String Name des GKE-Clusters.
cluster_location String Speicherort des Clusters. Dies kann eine Zone oder Region sein, je nachdem, ob der Cluster zonal oder regional ist.

PodDetails-Feldformat

Feld Typ Beschreibung
pod_name String Name des Pods.
pod_namespace String Namespace des Pods.

Feldformat von ServiceDetails

Feld Typ Beschreibung
service_name String Name des Dienstes, Wenn mehr als zwei relevante Dienste vorhanden sind, wird das Feld auf eine spezielle MANY_SERVICES-Markierung gesetzt.
service_namespace String Namespace des Dienstes.

Beispiel:

Wenn zwei Dienste vorhanden sind, sieht das Dienstfeld so aus:

service: [
 0: {
  service_name: "my-lb-service"
  service_namespace: "default"
 }
 1: {
  service_name: "my-lb-service2"
  service_namespace: "default"
 }
]

Wenn mehr als zwei Dienste vorhanden sind, sieht das Dienstfeld so aus:

service: [
 0: {
  service_name: "MANY_SERVICES"
 }
]

Logfilterung

Wenn Sie VPC-Flusslogs aktivieren, können Sie einen Filter anhand von Basis- und Metadatenfeldern festlegen, die nur Logs beibehalten, die dem Filter entsprechen. Alle anderen Logs werden verworfen, bevor sie in Logging geschrieben werden. Dadurch sparen Sie Geld und können die benötigte Zeit für die Suche nach den gewünschten Informationen reduzieren.

Sie können nach einer beliebigen Teilmenge von Feldern aus dem Eintragsformat filtern.

Bei der VPC-Flusslog-Filterung wird CEL verwendet, eine eingebettete Ausdruckssprache für attributbasierte logische Ausdrücke. Weitere Informationen finden Sie unter Unterstützte CEL-Operatoren.

Weitere Informationen zu CEL finden Sie in der CEL-Einführung und in der Sprachdefinition. Das Generierungsfilter-Feature unterstützt eine begrenzte Teilmenge der CEL-Syntax.

Beispiel 1: Beschränken Sie die Logerfassung auf eine bestimmte VM mit dem Namen my-vm. In diesem Fall werden nur Logs aufgezeichnet, bei denen das Feld src_instance, das von der Quelle des Traffics gemeldet wird, my-vm ist, oder das Feld dst_instance, das vom Ziel des Traffics gemeldet wird, my-vm ist.

gcloud compute networks subnets update my-subnet \
--logging-filter-expr="(src_instance.vm_name == 'my-vm' && reporter=='SRC') || (dest_instance.vm_name == 'my-vm' && reporter=='DEST')"

Beispiel 2: Beschränken Sie die Logerfassung auf Pakete, deren Quell-IP-Adressen im Subnetz 10.0.0.0/8 enthalten sind.

gcloud compute networks subnets update my-subnet \
--logging-filter-expr="inIpRange(connection.src_ip, '10.0.0.0/8')"

Unterstützte logische CEL-Operatoren

Ausdruck Unterstützte Datentypen Beschreibung
true, false Boolean Boolesche Konstanten
x == y x != y Boolean, Int, String Vergleichsoperatoren Beispiel: connection.protocol == 6
x && y x || y Boolean Boolesche Logic-Operatoren Beispiel: connection.protocol == 6 && src_instance.vm_name == "vm_1"
!x Boolean Negation
1, 2.0, 0, ... Int Konstante numerische Literale
x + y String String-Verkettung
"foo", 'foo', ... String Konstantes Stringliteral
x.lower() String Gibt den Kleinbuchstabenwert des Strings zurück
x.upper() String Gibt den Großbuchstabenwert des Strings zurück
x.contains(y) String Gibt "true" zurück, wenn der String den angegebenen Teilstring enthält
x.startsWith(y) String Gibt "true" zurück, wenn der String mit dem angegebenen Teilstring beginnt.
x.endsWith(y) String Gibt "true" zurück, wenn der String mit dem angegebenen Teilstring endet.
inIpRange(X, Y) String Gibt "true" zurück, wenn X eine IP-Adresse und Y ein IP-Bereich ist, der X enthält.
Beispiel: inIpRange("1.2.3.1", "1.2.3.0/24")
x.containsFieldValue(y) x: list
y: map(string, string)
Gibt "true" zurück, wenn die Liste ein Objekt mit Feldern enthält, die mit den angegebenen Schlüssel/Wert-Paaren übereinstimmen.
Beispiel: dest_gke_details.service.containsFieldValue({'service_name': 'service1', 'service_namespace': 'namespace1'})

Zugriffsmuster – Beispiele

In diesem Abschnitt wird das Funktionsprinzip von VPC-Flusslogs für die folgenden Anwendungsfälle erläutert:

VM-zu-VM-Datenflüsse in derselben VPC

VM-Datenflüsse innerhalb einer VPC (zum Vergrößern anklicken)
VM-Datenflüsse innerhalb einer VPC (zum Vergrößern anklicken)

Bei VM-zu-VM-Datenflüssen in derselben VPC werden Flusslogs sowohl von der anfragenden als auch von der antwortenden VM gemeldet. Dafür müssen sich beide VMs in Subnetzen befinden, für die VPC-Flusslogs aktiviert sind. In diesem Beispiel sendet die VM 10.10.0.2 eine Anfrage mit 1.224 Byte an die VM 10.50.0.2, die sich ebenfalls in einem Subnetz befindet, für das Logging aktiviert ist. 10.50.0.2 antwortet auf die Anfrage mit einer Antwort, die 5.342 Byte enthält. Sowohl die Anfrage als auch die Antwort werden von den anfragenden und den antwortenden VMs aufgezeichnet.

Wie von anfragender VM gemeldet (10.10.0.2)
Anfrage/Antwort connection.src_ip connection.dest_ip bytes_sent VPC-Annotationen
Anfrage 10.10.0.2 10.50.0.2 1224 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*
Antwort 10.50.0.2 10.10.0.2 5342 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*
Wie von antwortender VM gemeldet (10.50.0.2)
Anfrage/Antwort connection.src_ip connection.dest_ip Byte VPC-Annotationen
Anfrage 10.10.0.2 10.50.0.2 1224 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*
Antwort 10.50.0.2 10.10.0.2 5342 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*

VM-zu-Extern-Datenflüsse

VM-zu-Extern-Datenflüsse (zum Vergrößern anklicken)
VM-zu-Extern-Datenflüsse (zum Vergrößern anklicken)

Für Datenflüsse zwischen einer VM und einer externen Entität werden Flusslogs nur von der VM gemeldet:

  • Bei ausgehenden Datenflüssen werden die Logs von der VM gemeldet, die die Quelle des Traffics ist.
  • Bei eingehenden Datenflüssen werden die Logs von der VM gemeldet, die das Ziel des Traffics ist.

Das gilt für:

  • Traffic zwischen einem VPC-Netzwerk und einem lokalen Netzwerk über Cloud VPN oder Cloud Interconnect.
  • Traffic zwischen VMs und Standorten im Internet.

In diesem Beispiel sind die VM 10.10.0.2 und der lokale Endpunkt 10.30.0.2 über ein VPN-Gateway oder Cloud Interconnect verbunden. Der ausgehende Traffic von 1.224 Byte, der von 10.10.0.2 an 10.30.0.2 gesendet wurde, wird von der Quell-VM 10.10.0.2 gemeldet. Der eingehende Traffic von 5.342 Byte, der von 10.30.0.2 an 10.10.0.2 gesendet wurde, wird vom Ziel des Traffics, der VM 10.10.0.2, gemeldet.

Anfrage/Antwort connection.src_ip connection.dest_ip bytes_sent VPC-Annotationen
Anfrage 10.10.0.2 10.30.0.2 1224 src_instance.*
src_vpc.*
dest_location.*
Antwort 10.30.0.2 10.10.0.2 5342 dest_instance.*
dest_vpc.*
src_location.*

VM-zu-VM-Datenflüsse für freigegebene VPC

Freigegebene VPC-Datenflüsse (zum Vergrößern anklicken)
Freigegebene VPC-Datenflüsse (zum Vergrößern anklicken)

Bei VM-zu-VM-Datenflüssen für freigegebene VPC können Sie VPC-Flusslogs für das Subnetz im Hostprojekt aktivieren. Beispiel: Das Subnetz 10.10.0.0/20 gehört zu einem freigegebenen VPC-Netzwerk, das in einem Hostprojekt definiert ist. Sie können Flusslogs von VMs sehen, die zu diesem Subnetz gehören, einschließlich solcher, die von Dienstprojekten erstellt wurden. In diesem Beispiel heißen die Dienstprojekte "Webserver", "Empfehlung", "Datenbank".

Bei VM-zu-VM-Datenflüssen werden, wenn sich beide VMs im selben Projekt oder – im Fall eines freigegebenen Netzwerks – im selben Hostprojekt befinden, Anmerkungen für die Projekt-ID und dergleichen für den anderen Endpunkt in der Verbindung bereitgestellt. Wenn sich die andere VM in einem anderen Projekt befindet, werden keine Annotationen für die andere VM bereitgestellt.

Die folgende Tabelle zeigt einen Datenfluss, der entweder in 10.10.0.10 oder 10.10.0.20 gemeldet wird.

  • src_vpc.project_id und dest_vpc.project_id stehen für das Hostprojekt, da das VPC-Subnetz zum Hostprojekt gehört.
  • src_instance.project_id und dest_instance.project_id sind für die Dienstprojekte bestimmt, da die Instanzen zu den Dienstprojekten gehören.
connection
.src_ip
src_instance
.project_id
src_vpc
.project_id
connection
.dest_ip
dest_instance
.project_id
dest_vpc
.project_id
10.10.0.10 webserver host_project 10.10.0.20 Empfehlung host_project

Dienstprojekte sind keine Inhaber des freigegebenen VPC-Netzwerks und haben keinen Zugriff auf die Flusslogs des freigegebenen VPC-Netzwerks.

VM-zu-VM-Datenflüsse für VPC-Netzwerk-Peering

VPC-Netzwerk-Peering-Datenflüsse (zum Vergrößern klicken)
VPC-Netzwerk-Peering-Datenflüsse (zum Vergrößern klicken)

Wenn sich die beiden VMs nicht im selben Google Cloud-Projekt befinden, werden VM-zu-VM-Datenflüsse für Peering-VPC-Netzwerke auf die gleiche Weise wie für externe Endpunkte gemeldet. Projekt- und andere Annotationsinformationen für die andere VM werden nicht bereitgestellt. Wenn sich beide VMs in demselben Projekt befinden, auch wenn sie sich in verschiedenen Netzwerken befinden, werden Projekt- und andere Annotationsinformationen auch für die andere VM angegeben.

In diesem Beispiel sind die Subnetze der VM 10.10.0.2 im Projekt "analytics-prod" und der VM 10.50.0.2 im Projekt "webserver-test" über VPC-Netzwerk-Peering verbunden. Wenn im Projekt "analytics-prod" VPC-Flusslogs aktiviert sind, wird der von 10.10.0.2 an 10.50.0.2 gesendete Traffic (1.224 Byte) von der VM 10.10.0.2 gemeldet, die die Quelle des Datenflusses ist. Der von 10.50.0.2 an 10.10.0.2 gesendete Traffic (5.342 Byte) wird auch von der VM 10.10.0.2 gemeldet, die das Ziel des Datenflusses ist.

In diesem Beispiel sind VPC-Flusslogs im Projekt "webserver-test" nicht aktiviert, also werden von der VM 10.50.0.2 keine Logs aufgezeichnet.

reporter connection.src_ip connection.dest_ip bytes_sent VPC-Annotationen
Quelle 10.10.0.2 10.50.0.2 1224 src_instance.*
src_vpc.*
Ziel 10.50.0.2 10.10.0.2 5342 dest_instance.*
dest_vpc.*

VM-zu-VM-Datenflüsse für internes TCP/UDP-Load-Balancing

Datenflüsse für das interne TCP/UDP-Load-Balancing (zum Vergrößern klicken)
Datenflüsse für das interne TCP/UDP-Load-Balancing (zum Vergrößern klicken)

Wenn Sie dem Back-End-Dienst für einen internen TCP/UDP-Load-Balancer eine VM hinzufügen, fügt die Linux- oder Windows-Gastumgebung die IP-Adresse des Load-Balancings zur lokalen Routingtabelle der VM hinzu. Dadurch kann die VM Anfragepakete mit Zielen akzeptieren, die auf die IP-Adresse des Load-Balancers festgelegt sind. Wenn die VM antwortet, sendet sie ihre Antwort direkt. Als Quell-IP-Adresse für die Antwortpakete wird jedoch die IP-Adresse des Load Balancers festgelegt und nicht die VM, deren Last ausgeglichen wird.

Über einen internen TCP/UDP-Load-Balancer gesendete VM-zu-VM-Datenflüsse werden sowohl von der Quelle als auch vom Ziel gemeldet. Als Beispiel für ein HTTP-Anfrage/Antwort-Paar werden in der folgenden Tabelle die Felder der beobachteten Einträge im Flusslog beschrieben. Sehen Sie sich dazu auch die folgende Netzwerkkonfiguration an:

  • Browserinstanz bei 192.168.1.2
  • Interner TCP/UDP-Load-Balancer unter 10.240.0.200
  • Webserverinstanz bei 10.240.0.3
Traffic-Richtung reporter connection.src_ip connection.dest_ip connection.src_instanz connection.dest_instance
Anfrage SRC 192.168.1.2 10.240.0.200 Browserinstanz
Anfrage DEST 192.168.1.2 10.240.0.200 Browserinstanz Webserverinstanz
Antwort SRC 10.240.0.3 192.168.1.2 Webserverinstanz Browserinstanz
Antwort DEST 10.240.0.200 192.168.1.2 Browserinstanz

Die anfragende VM weiß nicht, welche VM auf die Anfrage antworten wird. Da die andere VM eine Antwort mit der IP des internen Load-Balancers als Quelladresse sendet, weiß die anfragende VM nicht, welche VM reagiert hat. Deshalb kann die anfragende VM dest_instance-Daten nicht in ihren Bericht aufnehmen, sondern nur src_instance-Daten. Da die antwortende VM die IP-Adresse der anderen VM kennt, kann sie die Daten von src_instance und dest_instance bereitstellen.

Pod-zu-ClusterIP-Datenfluss

Pod-zu-Cluster-IP-Datenfluss (zum Vergrößern klicken)
IP-Datenfluss von Pod zu Cluster (zum Vergrößern klicken)

In diesem Beispiel wird der Traffic vom Client-Pod (10.4.0.2) an cluster-service (10.0.32.2:80) gesendet. Das Ziel wird in die ausgewählte Server-Pod-IP-Adresse (10.4.0.3) des Zielports (8080) aufgelöst.

An Knotenrändern wird der Fluss zweimal mit der übersetzten IP-Adresse und dem Port erfasst. Für beide Stichprobenpunkte bestimmen wir, dass der Ziel-Pod den Dienst cluster-service auf Port 8080 sichert, und annotieren den Eintrag mit den Dienst- und Pod-Details. Wenn der Traffic an einen Pod auf demselben Knoten weitergeleitet wird, verlässt der Traffic den Knoten nicht und wird nicht erfasst.

In diesem Beispiel werden die folgenden Einträge gefunden.

reporter connection.src_ip connection.dst_ip bytes_sent VPC-Annotationen
SRC 10.4.0.2 10.4.0.3 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
src_gke_details.pod.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*
DEST 10.4.0.2 10.4.0.3 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
src_gke_details.pod.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*

Externe GKE-LoadBalancer-Datenflüsse

Externe Load-Balancer-Datenflüsse (zum Vergrößern klicken)
Externe Load-Balancer-Datenflüsse (zum Vergrößern klicken)

Traffic von einer externen IP-Adresse an einen GKE-Dienst (35.35.35.35) wird zur Weiterleitung an einen Knoten im Cluster weitergeleitet, in diesem Beispiel 10.0.12.2. Standardmäßig verteilen Netzwerk-Load-Balancer den Traffic auf alle Knoten im Cluster, auch auf diejenigen, die keinen relevanten Pod ausführen. Der Traffic benötigt möglicherweise zusätzliche Hops, um zum entsprechenden Pod zu gelangen. Weitere Informationen finden Sie unter Netzwerke außerhalb des Clusters.

Der Traffic wird dann vom Knoten (10.0.12.2) an den ausgewählten Server-Pod (10.4.0.2) weitergeleitet. Beide Hops werden protokolliert, da alle Knotenkanten erfasst werden. Wenn der Traffic an einen Pod auf demselben Knoten wie 10.4.0.3 weitergeleitet wird, wird der zweite Hop nicht protokolliert, da er den Knoten nicht verlässt. Der zweite Hop wird von den Stichprobenpunkten der beiden Knoten protokolliert. Der zweite Hop wird von den Stichprobenpunkten beider Knoten protokolliert. Für den ersten Hop haben wir den Dienst anhand der IP-Adresse und des Dienstports des Load-Balancers (80) ermittelt. Beim zweiten Hop haben wir festgestellt, dass der Ziel-Pod den Dienst am Zielport (8080) gesichert.

In diesem Beispiel werden die folgenden Einträge gefunden.

reporter connection.src_ip connection.dst_ip bytes_sent VPC-Annotationen
DEST 203.0.113.1 35.35.35.35 1224 src_location.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.service.*
SRC 10.0.12.2 10.4.0.2 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*
DEST 10.0.12.2 10.4.0.2 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*

Eingehende GKE-Flüsse

Eingehende Datenflüsse (zum Vergrößern anklicken)
Eingehende Datenflüsse (zum Vergrößern klicken)

Eine Verbindung von einer öffentlichen IP-Adresse zu einem Ziel für eingehenden Traffic wird beim Load-Balancer-Dienst beendet. Die Verbindung wird einem NodePort-Dienst gemäß der URL zugeordnet. Zur Verarbeitung der Anfrage stellt der Load-Balancer (130.211.0.1) eine Verbindung zu einem der Clusterknoten (10.0.12.2) her, um das Routing über den NodePort des Dienstes durchzuführen. Standardmäßig erstellt der GKE-Ingress-Controller beim Erstellen eines Ingress-Objekts einen HTTP(S)-Load-Balancer, der den Traffic auf alle Knoten im Cluster verteilt, auch auf diejenigen, die keinen relevanten Pod ausführen. Der Traffic benötigt möglicherweise zusätzliche Hops, um zum entsprechenden Pod zu gelangen. Weitere Informationen finden Sie unter Netzwerkübersicht. Der Traffic wird dann vom Knoten (10.0.12.2) an den ausgewählten Server-Pod (10.4.0.2) weitergeleitet.

Beide Hops werden protokolliert, da alle Knotenkanten erfasst werden. Für den ersten Hop haben wir den Dienst mit dem NodePort des Dienstes (60000) bestimmt. Für den zweiten Hop bestimmen wir, dass der Ziel-Pod den Dienst am Zielport (8080) sichert. Der zweite Hop wird durch die Stichprobenpunkte beider Knoten protokolliert. In einem Fall, in dem der Traffic jedoch an einen Pod auf demselben Knoten weitergeleitet wird (10.4.0.3), wird der zweite Hop nicht protokolliert, da der Traffic den Knoten nicht verlassen hat.

In diesem Beispiel werden die folgenden Einträge gefunden.

reporter connection.src_ip connection.dst_ip bytes_sent VPC-Annotationen
DEST 130.211.0.1 10.0.12.2 1224 dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.service.*
SRC 10.0.12.2 10.4.0.2 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*
DEST 10.0.12.2 10.4.0.2 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*

Eingehende GKE-Datenflüsse mit containernativem Load-Balancing

Eingehende Datenflüsse mit containernativem Load-Balancing (zum Vergrößern klicken)
Eingehende Datenflüsse mit containernativem Load-Balancing (zum Vergrößern klicken)

Anfragen von einer öffentlichen IP-Adresse an ein Ingress, das containernatives Load-Balancing verwendet, werden am Load-Balancer beendet. Bei diesem Ingress-Typ sind Pods Kernobjekte für das Load-Balancing. Eine Anfrage wird dann direkt vom Load-Balancer (130.211.0.1) an einen ausgewählten Pod (10.4.0.2) gesendet. Wir stellen fest, dass der Ziel-Pod den Dienst am Zielport (8080) sichert.

In diesem Beispiel wird der folgende Eintrag gefunden.

reporter connection.src_ip connection.dst_ip bytes_sent VPC-Annotationen
DEST 130.211.0.1 10.4.0.2 1224 dest_instance.*
dest_vpc.*
dest_gke_details.cluster.*
dest_gke_details.pod.*
dest_gke_details.service.*

Pod zu externen Datenflüssen

Pod zu externem Datenfluss (zum Vergrößern klicken)
Pod zu externem Datenfluss (zum Vergrößern klicken)

Der Traffic von einem Pod (10.4.0.3) zu einer externen IP-Adresse (203.0.113.1) wird durch IP-Masquerade geändert, sodass die Pakete von der Knoten-IP (10.0.12.2) statt von der Pod-IP gesendet werden. Standardmäßig ist der GKE-Cluster so konfiguriert, dass der Traffic zu externen Zielen maskiert wird. Weitere Informationen finden Sie unter Agent für IP-Masquerade.

Wenn Sie Pod-Annotationen für diesen Traffic ansehen möchten, können Sie den Masquerade-Agent so konfigurieren, dass er Pod-IP-Adressen nicht maskiert. In diesem Fall können Sie Cloud NAT konfigurieren, der die Pod-IP-Adressen verarbeitet, um Traffic zum Internet zuzulassen. Weitere Informationen zu Cloud NAT mit GKE finden Sie unter GKE-Interaktion.

In diesem Beispiel wird der folgende Eintrag gefunden.

reporter connection.src_ip connection.dst_ip bytes_sent VPC-Annotationen
SRC 10.0.12.2 203.0.113.1 1224 src_instance.*
src_vpc.*
src_gke_details.cluster.*
dest_location.*

Preise

Es gelten die Standardpreise für Logging, BigQuery oder Pub/Sub. Die Preisgestaltung für VPC-Flusslogs wird unter Netzwerktelemetrie-Preise beschrieben.

FAQ

  • Unterstützen VPC-Flusslogs sowohl zulässigen als auch abgelehnten Traffic, der auf Firewallregeln basiert?

    • VPC-Flusslogs umfassen Traffic aus der Sicht einer VM. Der gesamte ausgehende Traffic von einer VM wird in Logs erfasst, auch wenn er durch eine ablehnende Firewallregel blockiert wird. Eingehender Traffic wird in Logs erfasst, wenn dies durch eine Firewall-Zulassungsregel für eingehenden Traffic erlaubt ist. Der durch eine Firewall-Ablehnungsregel für eingehenden Traffic blockierte eingehende Traffic wird nicht in Logs erfasst.
  • Funktionieren VPC-Flusslogs bei VM-Instanzen mit mehreren Schnittstellen?

  • Funktionieren VPC-Flusslogs bei Legacy-Netzwerken?

Weitere Informationen