Trafficflüsse
Auf dieser Seite wird beschrieben, wie VPC-Flusslogs für allgemeine Anwendungsfälle Flusslogs meldet. In den folgenden Abschnitten finden Sie Beispiele für Traffic-Datenflüsse, die von VPC-Flusslogs als Stichprobe verwendet werden.
VM-Datenflüsse
In den folgenden Abschnitten finden Sie Beispiele dafür, wie VPC-Flusslogs Traffic erfassen, der von VM-Instanzen gesendet und empfangen wird. Informationen dazu, wie VPC-Flusslogs Flussprotokolle für Google Kubernetes Engine-Pods (GKE) erfassen, finden Sie unter GKE-Flüsse.
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.* dest_instance.* src_vpc.* dest_vpc.* |
| antworten | 10.50.0.2 | 10.10.0.2 | 5.342 |
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 | Annotationen |
| Request | 10.10.0.2 | 10.50.0.2 | 1.224 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* |
| antworten | 10.50.0.2 | 10.10.0.2 | 5.342 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* |
VM-zu-externe 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 |
dest_instance.* dest_vpc.* src_location.* |
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_idunddest_vpc.project_idstehen für das Hostprojekt, da das VPC-Subnetz zum Hostprojekt gehört.src_instance.project_idunddest_instance.project_idsind 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 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 | 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-Zugriffe mit Cloud Load Balancing
Bei Flusen über Cloud Load Balancing werden in VPC-Fluss-Logs Anmerkungen zu Traffic hinzugefügt, 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 Google 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 (192.168.1.2) gemeldet | ||||
|---|---|---|---|---|
| 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 der Backend-VM (10.240.0.3) gemeldet | ||||
|---|---|---|---|---|
| Anfrage/Antwort | connection.src_ip | connection.dest_ip | Byte | Annotationen |
| Anfrage | 192.168.1.2 | 10.240.0.200 | 1.224 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* load_balancing.* (alle Felder außer „url_map_name“) |
| antworten | 10.240.0.200 | 192.168.1.2 | 5.342 |
src_instance.* dest_instance.* src_vpc.* dest_vpc.* load_balancing.* (alle Felder außer „url_map_name“) |
In der Anfrage, die der Load Balancer an die Back-End-VM verteilt, wird die Quell-IP-Adresse auf die IP-Adresse der Client-VM festgelegt. Das bedeutet, dass die Backend-VM src_instance- und dest_instance-Informationen zur Client-VM bereitstellen kann. Im Gegensatz zur Back-End-VM kann die Client-VM jedoch keine src_instance- und dest_instance-Informationen zur Back-End-VM in ihren Bericht aufnehmen, da sie die Anfrage an die IP-Adresse des Load Balancers sendet und die Antwort von dort empfängt, nicht von der Back-End-VM.
VM-zu-interner Proxy-Network Load Balancer und VM-zu-interner Application Load Balancer-Datenflüsse
Trafficflüsse über einen internen Proxy-Network Load Balancer oder einen internen Application Load Balancer werden von Client-VMs gemeldet, sofern sich die Client-VM in einem Subnetz befindet, für das VPC-Traffic-Logs aktiviert sind. Beispiel: Eine Client-VM mit der IP-Adresse 10.10.0.2 sendet 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 Protokolle der Client-VM sind im Google Cloud-Projekt 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.* |
VM-zu-VM-Traffic über Private Service Connect
Bei VM-zu-VM-Traffic über Private Service Connect werden in VPC-Flussprotokollen Abläufe zwischen Private Service Connect-Nutzern und veröffentlichten Diensten erfasst.
Private Service Connect-Endpunkt zu einem veröffentlichten Dienst
Trafficflüsse zu von Private Service Connect veröffentlichten Diensten werden sowohl von Nutzer- als auch von Produzenten-VMs erfasst, sofern sich beide VMs in Subnetzen befinden, für die VPC-Fluss-Logs 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.0.3. Im VPC des Erstellers wird die Quell-IP-Adresse der Anfrage in eine IP-Adresse im Subnetz des Dienstanhangs übersetzt, in diesem Beispiel 10.40.0.2. 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 der Nutzer-VM (10.10.0.2) gemeldet | ||||
|---|---|---|---|---|
| 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 der VM des Erzeugers 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-Flü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 in VPC-Flußprotokollen Protokolleinträge mit Google API-Informationen versehen. Im folgenden Abschnitt wird ein Beispiel dafür gezeigt, wie VPC-Flow-Logs Protokolleinträge für eine VM annotieren, die über einen Private Service Connect-Endpunkt auf eine globale Google API zugreift.
VM zu einer globalen Google API über Private Service Connect
Trafficflüsse zu einer Google API werden von Nutzer-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. an 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 der Nutzer-VM (10.10.0.2) gemeldet | ||||
|---|---|---|---|---|
| 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.* psc.reporter psc.psc_endpoint.* dest_google_service.* |
| antworten | 10.10.110.10 | 10.10.0.2 | 5.342 |
src_google_service.* dest_instance.* dest_vpc.* psc.reporter psc.psc_endpoint.* |
GKE-Datenflüsse
In den folgenden Abschnitten finden Sie Beispiele dafür, wie VPC-Flusslogs GKE-Traffic von und zu Pods als Stichprobe verwenden.
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 externe 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 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-Anmerkungen 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.* |
Hybridkonnektivitätsflüsse
Bei Traffic zwischen Google Cloud und lokalen Netzwerken werden in VPC-Flusslogs Flüsse zwischen VM-Instanzen – einschließlich Instanzen, die als GKE-Knoten verwendet werden – und lokalen Endpunkten, zwischen Google APIs und lokalen Endpunkten sowie Transit-Traffic zwischen lokalen Endpunkten kommentiert. Im folgenden Beispiel wird beschrieben, wie VPC-Flussprotokolle Abläufe zwischen VM-Instanzen in einem VPC-Netzwerk und einem lokalen Endpunkt annotieren.
Für Datenflüsse zwischen einer VM in einem VPC-Netzwerk und einem lokalen Endpunkt mit einer internen IP-Adresse werden Flusslogs nur von Google Cloud gemeldet. Die folgenden Ressourcen enthalten Ablaufprotokolle:
- Die VM Meldet Flussprotokolle, 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 Flussprotokolle, wenn für das Gateway VPC-Flusslogs aktiviert sind.
Im obigen Diagramm sendet der lokale Endpunkt 10.30.0.2 eine Anfrage mit 1.224 Byte über Cloud Interconnect 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 für Cloud Interconnect 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.10.0.2 | 1.224 |
reporter src_gateway.* dest_instance.* dest_vpc.* |
| antworten | 10.10.0.2 | 10.30.0.2 | 5.342 |
reporter src_instance.* src_vpc.* dest_gateway.* |
| Wie von VM (10.10.0.2) gemeldet | ||||
|---|---|---|---|---|
| Anfrage/Antwort | connection.src_ip | connection.dest_ip | bytes_sent | Annotationen |
| Anfrage | 10.30.0.2 | 10.10.0.2 | 1.224 |
reporter src_gateway.* dest_instance.* dest_vpc.* |
| antworten | 10.10.0.2 | 10.30.0.2 | 5.342 |
reporter src_instance.* src_vpc.* dest_gateway.* |