Trafficflüsse

Auf dieser Seite wird beschrieben, wie VPC-Flusslogs Logs für häufige Traffic-Flüsse meldet. Beispiele finden Sie in den folgenden Abschnitten:

• VM-Flüsse, GKE-Flüsse und Hybrid-Konnektivitätsflüsse beschreiben Flüsse innerhalb von Trusted Cloud by S3NS und Flüsse zwischen Trusted Cloud und Ressourcen außerhalb von Trusted Cloud. Bei Beispielen für Datenflüsse zwischen verschiedenenTrusted Cloud -Projekten wird davon ausgegangen, dass VPC-Flusslogs auf Projektebene konfiguriert sind.
• Unter Flüsse zwischen VPC-Netzwerken in verschiedenen Projekten wird beschrieben, wie projektübergreifende Flüsse annotiert werden, wenn VPC-Flusslogs auf Organisationsebene konfiguriert sind.

VM-Datenflüsse

In den folgenden Abschnitten finden Sie Beispiele dafür, wie VPC-Flusslogs Traffic-Datenflüsse von und zu VM-Instanzen annotieren.

VM-zu-VM-Datenflüsse im derselben VPC-Netzwerk

Bei VM-zu-VM-Datenflüssen im selben VPC-Netzwerk werden Fluss-Logs sowohl von der anfragenden als auch von der antwortenden VM gemeldet, wenn sich beide VMs in Subnetzen befinden, für die VPC-Fluss-Logs 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	Annotationen
Request	10.10.0.2	10.50.0.2	1.224	src_instance.* src_vpc.* dest_instance.* dest_vpc.*
antworten	10.50.0.2	10.10.0.2	5.342	src_instance.* src_vpc.* dest_instance.* dest_vpc.*

Wie von antwortender VM gemeldet (10.50.0.2)
Anfrage/Antwort	connection.src_ip	connection.dest_ip	bytes_sent	Annotationen
Request	10.10.0.2	10.50.0.2	1.224	src_instance.* src_vpc.* dest_instance.* dest_vpc.*
antworten	10.50.0.2	10.10.0.2	5.342	src_instance.* src_vpc.* dest_instance.* dest_vpc.*

VM-zu-Extern-IP-Adressflüsse

Für Datenflüsse, die das Internet zwischen einer VM in einem VPC-Netzwerk und einem Endpunkt mit einer externen IP-Adresse durchlaufen, werden nur Flusslogs von der VM gemeldet, die sich im VPC-Netzwerk befindet:

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

In diesem Beispiel tauscht die VM 10.10.0.2 Pakete über das Internet mit einem Endpunkt aus, der die externe IP-Adresse 203.0.113.5 hat. Der ausgehende Traffic von 1.224 Byte, der von 10.10.0.2 an 203.0.113.5 gesendet wurde, wird von der Quell-VM 10.10.0.2 gemeldet. Der eingehende Traffic von 5.342 Byte, der von 203.0.113.5 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	Annotationen
Request	10.10.0.2	203.0.113.5	1.224	src_instance.* src_vpc.* dest_location.* internet_routing_details.*
antworten	203.0.113.5	10.10.0.2	5.342	src_location.* dest_instance.* dest_vpc.*

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

Bei VM-zu-VM-Datenflüssen für freigegebene VPC können Sie VPC-Flusslogs für das Subnet 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 nicht 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

Wenn sich die beiden VMs nicht im selben Trusted Cloud by S3NS -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	Annotationen
source	10.10.0.2	10.50.0.2	1.224	src_instance.* src_vpc.*
Ziel	10.50.0.2	10.10.0.2	5.342	dest_instance.* dest_vpc.*

VM-zu-VM-Flows über Private Service Connect

VPC-Flow-Logs enthalten Anmerkungen zu Flows zwischen Private Service Connect-Nutzern und veröffentlichten Diensten. Im folgenden Beispiel wird beschrieben, wie VPC-Flusslogs Logeinträge für Consumer- und Producer-VMs mit Anmerkungen versehen.

Traffic-Flüsse zu veröffentlichten Private Service Connect-Diensten werden sowohl von Nutzer- als auch von Produzenten-VMs gemeldet, sofern sich beide VMs in Subnetzen befinden, für die VPC-Fluss-Logs aktiviert sind. In diesem Beispiel sendet die Consumer-VM 10.10.0.2 eine Anfrage mit 1.224 Byte an den Private Service Connect-Endpunkt 10.10.0.3. Im VPC des Erstellers wird die Quell-IP-Adresse der Anfrage in eine IP-Adresse im Subnetz des Dienstanhangs übersetzt, die in diesem Beispiel 10.40.0.2 ist. Die Ziel-IP-Adresse der Anfrage wird in die IP-Adresse des internen Passthrough-Network Load Balancers, 10.50.0.3, übersetzt. Die Anfrage erreicht dann die Backend-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. Die Logs der Nutzer-VM sind im Nutzerprojekt und die Logs der Ersteller-VM im Erstellerprojekt verfügbar.

Wie von Nutzer-VM gemeldet (10.10.0.2)
Anfrage/Antwort	connection.src_ip	connection.dest_ip	bytes_sent	Annotationen
Request	10.10.0.2	10.10.0.3	1.224	src_instance.* src_vpc.* psc.reporter psc.psc_endpoint.* psc.psc_attachment.*
antworten	10.10.0.3	10.10.0.2	5.342	dest_instance.* dest_vpc.* psc.reporter psc.psc_endpoint.* psc.psc_attachment.*

Wie von Producer-VM gemeldet (10.50.0.2)
Anfrage/Antwort	connection.src_ip	connection.dest_ip	bytes_sent	Annotationen
Anfrage	10.40.0.2	10.50.0.3	1.224	dest_instance.* dest_vpc.* psc.reporter psc.psc_attachment.*
antworten	10.50.0.3	10.40.0.2	5.342	src_instance.* src_vpc.* psc.reporter psc.psc_attachment.*

VM-zu-Google-API-Datenflüsse

Bei VM-Traffic zu Google APIs über die externe IP-Adresse der VM, den privater Google-Zugriff oder einen Private Service Connect-Endpunkt werden Logdatensätze in VPC-Flusslogs mit Google API-Informationen versehen.

Im folgenden Beispiel wird beschrieben, wie VPC-Flusslogs Logdatensätze für eine VM annotieren, die über einen Private Service Connect-Endpunkt auf eine globale Google API zugreift.

Trafficflüsse zu einer Google API werden von Consumer-VMs gemeldet, sofern sich die VM in einem Subnetz befindet, für das VPC-Flusslogs aktiviert sind. In diesem Beispiel sendet die Nutzer-VM 10.10.0.2 eine Anfrage mit 1.224 Byte an den Private Service Connect-Endpunkt 10.10.110.10. Die Anfrage wird an den entsprechenden Google-Dienst weitergeleitet, z. B. Cloud Storage. Cloud Storage antwortet auf die Anfrage mit einer Antwort, die 5.342 Byte enthält. Sowohl die Anfrage als auch die Antwort werden von der anfragenden VM aufgezeichnet.

Wie von Nutzer-VM gemeldet (10.10.0.2)
Anfrage/Antwort	connection.src_ip	connection.dest_ip	bytes_sent	Annotationen
Request	10.10.0.2	10.10.110.10	1.224	src_instance.* src_vpc.* dest_google_service.* psc.reporter psc.psc_endpoint.*
antworten	10.10.110.10	10.10.0.2	5.342	src_google_service.* dest_instance.* dest_vpc.* psc.reporter psc.psc_endpoint.*

VM-Datenflüsse über Cloud Load Balancing

VPC-Flusslogs annotieren Traffic, der über einen Passthrough-Network Load Balancer, einen Proxy-Network Load Balancer oder einen Application Load Balancer gesendet wird. In den folgenden Beispielen wird davon ausgegangen, dass diese Load-Balancer als interne Load-Balancer konfiguriert sind.

VM-zu-VM-Datenflüsse über einen internen Passthrough Network Load Balancer

Wenn Sie dem Backend-Dienst für einen internen Passthrough Network Load Balancer eine VM hinzufügen,fügt Trusted Cloud die IP-Adresse des Load-Balancers 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 Passthrough Network Load Balancer gesendete VM-zu-VM-Datenflüsse werden sowohl von der Quelle als auch vom Ziel gemeldet.

Wie von Client-VM gemeldet (192.168.1.2)
Anfrage/Antwort	connection.src_ip	connection.dest_ip	bytes_sent	Annotationen
Anfrage	192.168.1.2	10.240.0.200	1.224	src_instance.* src_vpc.* load_balancing.forwarding_rule_project_id load_balancing.reporter load_balancing.type load_balancing.scheme load_balancing.forwarding_rule_name load_balancing.backend_service_name load_balancing.vpc.*
antworten	10.240.0.200	192.168.1.2	5.342	dest_instance.* dest_vpc.* load_balancing.forwarding_rule_project_id load_balancing.reporter load_balancing.type load_balancing.scheme load_balancing.forwarding_rule_name load_balancing.backend_service_name load_balancing.vpc.*

Wie von Backend-VM gemeldet (10.240.0.3)
Anfrage/Antwort	connection.src_ip	connection.dest_ip	bytes_sent	Annotationen
Anfrage	192.168.1.2	10.240.0.200	1.224	src_instance.* src_vpc.* dest_instance.* dest_vpc.* load_balancing.* (alle Felder außer „url_map_name“)
antworten	10.240.0.200	192.168.1.2	5.342	src_instance.* src_vpc.* dest_instance.* dest_vpc.* load_balancing.* (alle Felder außer „url_map_name“)

In der Anfrage, die der Load-Balancer an die Back-End-VM weiterleitet, ist die Quell-IP-Adresse auf die IP-Adresse der Client-VM festgelegt. Das bedeutet, dass die Backend-VM Informationen zu src_instance und dest_instance für die Client-VM bereitstellen kann. Im Gegensatz zur Backend-VM kann die Client-VM jedoch keine src_instance- und dest_instance-Informationen zur Backend-VM in ihren Bericht aufnehmen, da sie die Anfrage an die IP-Adresse des Load-Balancers und nicht an die der Backend-VM sendet und die Antwort von der IP-Adresse des Load-Balancers und nicht von der der Backend-VM empfängt.

VM-Datenflüsse über einen internen Proxy-Network Load Balancer oder einen internen Application Load Balancer

Traffic, der über einen internen Proxy-Network Load Balancer oder einen internen Application Load Balancer geleitet wird, wird von Client-VMs gemeldet, sofern sich die Client-VM in einem Subnetz befindet, für das VPC-Fluss-Logs aktiviert sind. Eine Client-VM mit der IP-Adresse 10.10.0.2 sendet beispielsweise eine Anfrage mit 1.224 Byte an den Load-Balancer-Endpunkt 10.10.0.3. Die Anfrage erreicht dann ein Back-End. Das Backend antwortet auf die Anfrage mit einer Antwort, die 5.342 Byte enthält. Sowohl die Anfrage als auch die Antwort werden auf der Client-VM aufgezeichnet. Die Logs der Client-VM sind im Projekt Trusted Cloud verfügbar, zu dem die VM gehört.

Wie von Client-VM gemeldet (10.10.0.2)
Anfrage/Antwort	connection.src_ip	connection.dest_ip	bytes_sent	Annotationen
Request	10.10.0.2	10.10.0.3	1.224	src_instance.* src_vpc.* load_balancing.forwarding_rule_project_id load_balancing.reporter load_balancing.type load_balancing.scheme load_balancing.url_map_name (für Application Load Balancer) load_balancing.forwarding_rule_name load_balancing.vpc.*
antworten	10.10.0.3	10.10.0.2	5.342	dest_instance.* dest_vpc.* load_balancing.forwarding_rule_project_id load_balancing.reporter load_balancing.type load_balancing.scheme load_balancing.url_map_name (für Application Load Balancer) load_balancing.forwarding_rule_name load_balancing.vpc.*

GKE-Datenflüsse

In den folgenden Abschnitten finden Sie Beispiele dafür, wie VPC-Flusslogs GKE-Traffic von und zu Pods annotieren.

Pod-zu-ClusterIP-Datenfluss

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	Annotationen
SRC	10.4.0.2	10.4.0.3	1.224	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	1.224	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

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 Passthrough Network 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 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	Annotationen
DEST	203.0.113.1	35.35.35.35	1.224	src_location.* dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.service.*
SRC	10.0.12.2	10.4.0.2	1.224	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	1.224	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

Eine Verbindung von einer externen IP-Adresse zu einem Ziel für eingehenden Traffic wird beim Cloud Load Balancing-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 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. 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	Annotationen
DEST	130.211.0.1	10.0.12.2	1.224	dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.service.*
SRC	10.0.12.2	10.4.0.2	1.224	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	1.224	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

Anfragen von einer externen IP-Adresse an ein Ingress-Ziel, 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	Annotationen
DEST	130.211.0.1	10.4.0.2	1.224	dest_instance.* dest_vpc.* dest_gke_details.cluster.* dest_gke_details.pod.* dest_gke_details.service.*

Pod zu externen Datenflüssen

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-Adresse 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	Annotationen
SRC	10.0.12.2	203.0.113.1	1.224	src_instance.* src_vpc.* src_gke_details.cluster.* dest_location.* internet_routing_details.*

Diagramme: Hybridkonnektivität

Bei Hybridkonnektivität über VLAN-Anhänge für Cloud Interconnect und Cloud VPN-Tunnel werden in VPC-Flusslogs die folgenden Flüsse mit Anmerkungen versehen:

• Flüsse zwischen VM-Instanzen, einschließlich Instanzen, die als GKE-Knoten verwendet werden, und On-Premise-Endpunkten
• Abläufe zwischen Google-Diensten und lokalen Endpunkten
• Transitflüsse zwischen lokalen Endpunkten

Im folgenden Beispiel wird beschrieben, wie VPC-Flusslogs Datenflüsse zwischen einer VM-Instanz in einem VPC-Netzwerk und einem lokalen Endpunkt annotieren. Das Netzwerk ist über einen VLAN-Anhang für Cloud Interconnect mit dem Endpunkt verbunden.

Für Datenflüsse zwischen einer VM in einem VPC-Netzwerk und einem lokalen Endpunkt mit einer internen IP-Adresse werden Flusslogs nur vonTrusted Cloud gemeldet. Die folgenden Ressourcen melden Flow-Logs:

• Die VM. Meldet Flusslogs, wenn für das Subnetz, mit dem die VM verbunden ist, VPC-Flusslogs aktiviert sind.
• Das Gateway, das das VPC-Netzwerk mit dem lokalen Endpunkt verbindet. Meldet Flusslogs, wenn für das Gateway (in diesem Beispiel der VLAN-Anhang) VPC-Flusslogs aktiviert sind.

Im obigen Diagramm sendet der lokale Endpunkt 10.30.0.2 eine Anfrage mit 1.224 Byte an die VM 10.0.0.2 im VPC-Netzwerk. Die VM 10.0.0.2 antwortet auf die Anfrage mit einer Antwort, die 5.243 Byte enthält. Sowohl die Anfrage als auch die Antwort werden sowohl vom VLAN-Anhang als auch von der VM aufgezeichnet.

Wie vom VLAN-Anhang gemeldet
Anfrage/Antwort	connection.src_ip	connection.dest_ip	bytes_sent	Annotationen
Anfrage	10.30.0.2	10.0.0.2	1.224	src_gateway.* dest_instance.* dest_vpc.*
antworten	10.0.0.2	10.30.0.2	5.342	src_instance.* src_vpc.* dest_gateway.*

Wie von VM gemeldet (10.0.0.2)
Anfrage/Antwort	connection.src_ip	connection.dest_ip	bytes_sent	Annotationen
Anfrage	10.30.0.2	10.0.0.2	1.224	src_gateway.* dest_instance.* dest_vpc.*
antworten	10.0.0.2	10.30.0.2	5.342	src_instance.* src_vpc.* dest_gateway.*

Flows zwischen VPC-Netzwerken in verschiedenen Projekten

Wenn VPC-Flusslogs für eine Organisation konfiguriert sind und projektübergreifende Anmerkungen aktiviert sind (Standardeinstellung), werden Datenflüsse zwischen VPC-Netzwerken in verschiedenen Projekten auf dieselbe Weise wie Datenflüsse zwischen VPC-Netzwerken im selben Projekt annotiert. Logdatensätze für diese Datenflüsse enthalten Informationen zu beiden Seiten der Verbindung.

Wenn projektübergreifende Annotationen deaktiviert sind, enthalten Log-Einträge nur Informationen zum Reporter des Traffic-Flusses.

Projektübergreifende Annotationen aktiviert

Im folgenden Beispiel wird beschrieben, wie VPC-Flusslogs Logdatensätze für VM-zu-VM-Datenflüsse zwischen Projekten mit Anmerkungen versehen, wenn projektübergreifende Anmerkungen aktiviert sind. Projektübergreifende Anmerkungen sind für Traffic-Flüsse über freigegebene VPC, VPC-Netzwerk-Peering und Network Connectivity Center verfügbar.

VM 10.0.0.2 sendet eine Anfrage mit 1.224 Byte an VM 10.0.0.1.2. VM 10.0.0.1.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.0.0.2)
Anfrage/Antwort	connection.src_ip	connection.dest_ip	bytes_sent	Annotationen
Anfrage	10.0.0.2	10.0.1.2	1.224	src_instance.* src_vpc.* dest_instance.* dest_vpc.*
antworten	10.0.1.2	10.0.0.2	5.342	src_instance.* src_vpc.* dest_instance.* dest_vpc.*

Wie von antwortender VM gemeldet (10.0.1.2)
Anfrage/Antwort	connection.src_ip	connection.dest_ip	bytes_sent	Annotationen
Anfrage	10.0.0.2	10.0.1.2	1.224	src_instance.* src_vpc.* dest_instance.* dest_vpc.*
antworten	10.0.1.2	10.0.0.2	5.342	src_instance.* src_vpc.* dest_instance.* dest_vpc.*

Projektübergreifende Annotationen deaktiviert

Im folgenden Beispiel wird beschrieben, wie VPC-Flusslogs Logeinträge für VM-zu-VM-Datenflüsse zwischen Projekten annotieren, wenn projektübergreifende Anmerkungen deaktiviert sind.

VM 10.0.0.2 sendet eine Anfrage mit 1.224 Byte an VM 10.0.0.1.2. VM 10.0.0.1.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. Informationen zur anderen VM werden jedoch nicht bereitgestellt.

Wie von anfragender VM gemeldet (10.0.0.2)
Anfrage/Antwort	connection.src_ip	connection.dest_ip	bytes_sent	Annotationen
Anfrage	10.0.0.2	10.0.1.2	1.224	src_instance.* src_vpc.*
antworten	10.0.1.2	10.0.0.2	5.342	dest_instance.* dest_vpc.*

Wie von antwortender VM gemeldet (10.0.1.2)
Anfrage/Antwort	connection.src_ip	connection.dest_ip	bytes_sent	Annotationen
Anfrage	10.0.0.2	10.0.1.2	1.224	dest_instance.* dest_vpc.*
antworten	10.0.1.2	10.0.0.2	5.342	src_instance.* src_vpc.*

Nächste Schritte

• VPC-Flusslogs konfigurieren
• Zugriff auf Flusslogs