À propos des flux de trafic

Cette page explique comment les journaux de flux VPC signalent les journaux de flux pour les cas d'utilisation courants. Consultez les sections suivantes pour obtenir des exemples de flux de trafic échantillonnés par les journaux de flux VPC.

Flux entre plusieurs VM au sein du même réseau VPC

Flux entre VM au sein d'un réseau VPC (cliquez pour agrandir).

Pour les flux entre plusieurs VM au sein d'un même réseau VPC, les journaux de flux sont transmis à la fois par la VM formulant la requête et par la VM formulant la réponse, tant que les journaux de flux VPC sont activés dans les sous-réseaux où se trouvent les deux VM. Dans cet exemple, la VM 10.10.0.2 envoie une requête contenant 1 224 octets à la VM 10.50.0.2, qui se trouve également dans un sous-réseau où la journalisation est activée. À son tour, 10.50.0.2 formule une réponse à la requête, contenant 5 342 octets. La requête et la réponse sont toutes deux enregistrées à partir de la VM formulant la requête et de la VM formulant la réponse.

Tel que transmis par la VM formulant la requête (10.10.0.2)
request/reply	connection.src_ip	connection.dest_ip	bytes_sent	Annotations
request	10.10.0.2	10.50.0.2	1 224	src_instance.* dest_instance.* src_vpc.* dest_vpc.*
réponse	10.50.0.2	10.10.0.2	5 342	src_instance.* dest_instance.* src_vpc.* dest_vpc.*

Tel que transmis par la VM formulant la réponse (10.50.0.2)
request/reply	connection.src_ip	connection.dest_ip	bytes	Annotations
request	10.10.0.2	10.50.0.2	1 224	src_instance.* dest_instance.* src_vpc.* dest_vpc.*
réponse	10.50.0.2	10.10.0.2	5 342	src_instance.* dest_instance.* src_vpc.* dest_vpc.*

Flux entre une VM et une adresse IP externe

Flux entre une VM et une adresse IP externe (cliquez pour agrandir).

Pour les flux qui transitent par Internet entre une VM située dans un réseau VPC et un point de terminaison doté d'une adresse IP externe, les journaux de flux ne sont transmis que par la VM située dans le réseau VPC :

• Pour les flux de sortie, les journaux sont transmis par la VM de réseau VPC qui est la source du trafic.
• Pour les flux d'entrée, les journaux sont transmis par la VM de réseau VPC qui est la destination du trafic.

Dans cet exemple, la VM 10.10.0.2 échange des paquets sur Internet avec un point de terminaison doté de l'adresse IP externe 203.0.113.5. La consignation du trafic sortant de 1 224 octets envoyé depuis 10.10.0.2 vers 203.0.113.5 est assurée par la VM source, 10.10.0.2. La consignation du trafic entrant de 5 342 octets envoyé depuis 203.0.113.5 vers 10.10.0.2 est assurée par la VM de destination du trafic, 10.10.0.2.

request/reply	connection.src_ip	connection.dest_ip	bytes_sent	Annotations
request	10.10.0.2	203.0.113.5	1 224	src_instance.* src_vpc.* dest_location.* internet_routing_details.*
réponse	203.0.113.5	10.10.0.2	5 342	dest_instance.* dest_vpc.* src_location.*

Flux entre une VM et un point de terminaison sur site

Flux entre une VM et un point de terminaison sur site (cliquez pour agrandir).

Pour les flux entre une VM située dans un réseau VPC et un point de terminaison sur site doté d'une adresse IP interne, les journaux de flux ne sont transmis que par la VM située dans le réseau VPC :

• Pour les flux de sortie, les journaux sont transmis par la VM de réseau VPC qui est la source du trafic.
• Pour les flux d'entrée, les journaux sont transmis par la VM de réseau VPC qui est la destination du trafic.

Dans cet exemple, la VM 10.10.0.2 et le point de terminaison sur site 10.30.0.2 sont connectés via une passerelle VPN ou Cloud Interconnect. La consignation du trafic sortant de 1 224 octets envoyé depuis 10.10.0.2 vers 10.30.0.2 est assurée par la VM source, 10.10.0.2. La consignation du trafic entrant de 5 342 octets envoyé depuis 10.30.0.2 vers 10.10.0.2 est assurée par la VM de destination du trafic, 10.10.0.2.

request/reply	connection.src_ip	connection.dest_ip	bytes_sent	Annotations
request	10.10.0.2	10.30.0.2	1 224	src_instance.* src_vpc.*
réponse	10.30.0.2	10.10.0.2	5 342	dest_instance.* dest_vpc.*

Flux entre plusieurs VM pour un VPC partagé

Flux pour un VPC partagé (cliquez pour agrandir).

Pour les flux entre plusieurs VM rattachées à un VPC partagé, vous pouvez activer les journaux de flux VPC pour le sous-réseau du projet hôte. Par exemple, le sous-réseau 10.10.0.0/20 appartient à un réseau VPC partagé défini dans un projet hôte. Vous pouvez afficher les journaux de flux des VM appartenant à ce sous-réseau, y compris ceux créés par des projets de service. Dans cet exemple, les projets de service sont appelés "web server" (serveur Web), "recommendation" (recommandation) et "database" (base de données).

Pour les flux entre plusieurs VM, si les deux VM se trouvent dans le même projet ou, dans le cas d'un réseau partagé, dans le même projet hôte, des annotations pour l'ID de projet et d'autres éléments sont fournies pour l'autre point de terminaison de la connexion. Si l'autre VM se trouve dans un projet différent, les annotations de l'autre VM ne sont pas fournies.

Le tableau suivant présente un flux tel que transmis par 10.10.0.10 ou 10.10.0.20.

• src_vpc.project_id et dest_vpc.project_id concernent le projet hôte, car le sous-réseau VPC appartient au projet hôte.
• src_instance.project_id et dest_instance.project_id concernent les projets de service, car les instances appartiennent aux projets de service.

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	serveur Web	host_project	10.10.0.20	recommendation	host_project

Les projets de service ne sont pas propriétaires du réseau VPC partagé et n'ont pas accès aux journaux de flux de ce réseau.

Flux entre plusieurs VM pour l'appairage de réseaux VPC

Flux pour l'appairage de réseaux VPC (cliquez pour agrandir).

À moins que les deux VM ne soient dans le même projet Google Cloud, la consignation des flux entre plusieurs VM pour les réseaux VPC appairés est assurée de la même manière que pour les points de terminaison externes. Les informations sur le projet et les autres annotations de l'autre VM ne sont pas fournies. Si les deux VM sont dans le même projet, des informations relatives à ce projet et à d'autres annotations sont également fournies pour l'autre VM, même si les deux se trouvent dans des réseaux différents.

Dans cet exemple, les sous-réseaux de la VM 10.10.0.2 dans le projet "analytics-prod" et de la VM 10.50.0.2 dans le projet "webserver-test" sont connectés via l'appairage de réseaux VPC. Si les journaux de flux VPC sont activés dans le projet "analytics-prod", le trafic (1 224 octets) envoyé depuis 10.10.0.2 vers 10.50.0.2 est transmis par la VM 10.10.0.2, qui est la source du flux. Le trafic (5 342 octets) envoyé depuis 10.50.0.2 vers 10.10.0.2 est également transmis par la VM 10.10.0.2, qui est la destination du flux.

Dans cet exemple, les journaux de flux VPC ne sont pas activés dans le projet "webserver-test". Ainsi, aucun journal n'est enregistré par la VM 10.50.0.2.

reporter	connection.src_ip	connection.dest_ip	bytes_sent	Annotations
source	10.10.0.2	10.50.0.2	1 224	src_instance.* src_vpc.*
destination	10.50.0.2	10.10.0.2	5 342	dest_instance.* dest_vpc.*

Flux entre plusieurs VM pour les équilibreurs de charge réseau internes à stratégie directe

Flux pour les équilibreurs de charge réseau passthrough internes (cliquez pour agrandir).

Lorsque vous ajoutez une VM au service de backend pour un équilibreur de charge réseau passthrough interne, l'environnement invité Linux ou Windows ajoute l'adresse IP de l'équilibreur de charge à la table de routage locale de la VM. Cet ajout permet à la VM d'accepter les paquets de requête dont les destinations sont l'adresse IP de l'équilibreur de charge. Lorsque la VM formule sa réponse, elle l'envoie directement. Cependant, l'adresse IP source des paquets de réponse est définie sur l'adresse IP de l'équilibreur de charge, et non sur la VM soumise à un équilibrage de charge.

Les flux entre plusieurs VM envoyés via un équilibreur de charge réseau interne à stratégie directe sont rapportés à la fois par la source et par la destination. Pour un exemple de paire requête/réponse HTTP, le tableau suivant explique les champs des entrées du journal de flux observées. Pour les besoins d'illustration de cet exemple, prenez en compte la configuration réseau suivante :

• Instance du navigateur à l'adresse 192.168.1.2
• Équilibreur de charge réseau interne à stratégie directe à l'adresse 10.240.0.200
• Instance du serveur Web à l'adresse 10.240.0.3

Sens du trafic	reporter	connection.src_ip	connection.dest_ip	connection.src_instance	connection.dest_instance
Requête	SRC	192.168.1.2	10.240.0.200	Instance du navigateur
Requête	DEST	192.168.1.2	10.240.0.200	Instance du navigateur	Instance du serveur Web
Réponse	SRC	10.240.0.3	192.168.1.2	Instance du serveur Web	Instance du navigateur
Réponse	DEST	10.240.0.200	192.168.1.2		Instance du navigateur

La VM formulant une requête ne sait pas quelle VM y répondra. De plus, comme l'autre VM formule sa réponse avec l'adresse IP de l'équilibreur de charge interne en tant qu'adresse source, elle ne sait pas quelle VM a formulé la réponse. Pour toutes ces raisons, la VM formulant la requête ne peut pas ajouter d'informations relatives à dest_instance à son rapport, mais uniquement des informations relatives à src_instance. Étant donné que la VM formulant la réponse connaît l'adresse IP de l'autre VM, elle peut fournir des informations relatives à la fois à src_instance et à dest_instance.

Flux entre le pod et ClusterIP

Flux entre un pod et l'adresse IP du cluster (cliquez pour agrandir).

Dans cet exemple, le trafic est envoyé du pod client (10.4.0.2) vers cluster-service (10.0.32.2:80). La destination est résolue en adresse IP du pod de serveur sélectionné (10.4.0.3) sur le port cible (8080).

Sur les arêtes des nœuds, le flux est échantillonné deux fois avec l'adresse IP et le port traduits. Pour les deux points d'échantillonnage, nous allons constater que le pod de destination effectue une sauvegarde du service cluster-service sur le port 8080, puis nous allons annoter l'enregistrement avec les détails du service, ainsi qu'avec les détails du pod. Si le trafic est acheminé vers un pod sur le même nœud, le trafic ne quitte pas le nœud et n'est pas échantillonné.

Dans cet exemple, les enregistrements suivants ont été trouvés.

reporter	connection.src_ip	connection.dst_ip	bytes_sent	Annotations
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.*

Flux pour l'équilibrage de charge externe GKE

Flux pour un équilibreur de charge externe (cliquez pour agrandir).

Le trafic provenant d'une adresse IP externe vers un service GKE (35.35.35.35) est acheminé vers un nœud du cluster (10.0.12.2, dans cet exemple) pour le routage. Par défaut, les équilibreurs de charge réseau externes à stratégie directe distribuent le trafic sur tous les nœuds du cluster, même ceux qui n'exécutent pas de pod pertinent. Le trafic peut prendre des sauts supplémentaires pour atteindre le pod approprié. Pour plus d'informations, consultez la section Mise en réseau à l'extérieur du cluster.

Le trafic est ensuite acheminé depuis le nœud (10.0.12.2) vers le pod de serveur sélectionné (10.4.0.2). Les deux sauts sont consignés, car toutes les arêtes des nœuds sont échantillonnées. Si le trafic est acheminé vers un pod sur le même nœud (10.4.0.3 dans cet exemple), le deuxième saut n'est pas consigné, car il ne quitte pas le nœud. Le deuxième saut est consigné par les points d'échantillonnage des deux nœuds. Pour le premier saut, nous identifions le service en fonction de l'adresse IP de l'équilibreur de charge et du port de service (80). Pour le deuxième saut, nous constatons que le pod de destination effectue une sauvegarde du service sur le port cible (8080).

Dans cet exemple, les enregistrements suivants ont été trouvés.

reporter	connection.src_ip	connection.dst_ip	bytes_sent	Annotations
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.*

Flux des Ingress GKE

Flux pour des objets Ingress (cliquez pour agrandir).

Une connexion depuis une adresse IP publique vers une destination Ingress est interrompue au niveau du service d'équilibrage de charge. La connexion est mappée à un service NodePort en fonction de l'URL. Pour diffuser la requête, l'équilibreur de charge (130.211.0.1) se connecte à l'un des nœuds de cluster (10.0.12.2) pour le routage à l'aide du NodePort du service. Par défaut, lors de la création d'un objet Ingress, le contrôleur GKE Ingress configure un équilibreur de charge HTTP(S) qui répartit le trafic entre tous les nœuds du cluster, même ceux qui n'exécutent pas de pod pertinent. Le trafic peut prendre des sauts supplémentaires pour atteindre le pod approprié. Pour plus d'informations, consultez la section Mise en réseau à l'extérieur du cluster. Le trafic est ensuite acheminé depuis le nœud (10.0.12.2) vers le pod de serveur sélectionné (10.4.0.2).

Les deux sauts sont consignés, car toutes les arêtes des nœuds sont échantillonnées. Pour le premier saut, nous identifions le service en fonction du NodePort (60000) du service. Pour le deuxième saut, nous constatons que le pod de destination effectue une sauvegarde du service sur le port cible (8080). Le deuxième saut est consigné par les points d'échantillonnage des deux nœuds. Cependant, dans le cas où le trafic est acheminé vers un pod sur le même nœud (10.4.0.3), le deuxième saut n'est pas consigné, car le trafic n'a pas quitté le nœud.

Dans cet exemple, les enregistrements suivants ont été trouvés.

reporter	connection.src_ip	connection.dst_ip	bytes_sent	Annotations
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.*

Flux des Ingress GKE utilisant l'équilibrage de charge natif en conteneur

Flux pour des objets Ingress utilisant l'équilibrage de charge natif en conteneurs (cliquez pour agrandir).

Les requêtes provenant d'une adresse IP publique vers un objet Ingress utilisant l'équilibrage de charge natif en conteneurs sont interrompues au niveau de l'équilibreur de charge. Dans ce type d'objet Ingress, les pods sont des objets principaux pour l'équilibrage de charge. Une requête est ensuite envoyée directement depuis l'équilibreur de charge (130.211.0.1) à un pod sélectionné (10.4.0.2). Nous constatons que le pod de destination effectue une sauvegarde du service sur le port cible (8080).

Dans cet exemple, l'enregistrement suivant a été trouvé.

reporter	connection.src_ip	connection.dst_ip	bytes_sent	Annotations
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.*

Flux entre un pod et un système externe

Flux entre un pod et un système externe (cliquez pour agrandir).

Le trafic d'un pod (10.4.0.3) vers une adresse IP externe (203.0.113.1) est modifié par le masquage d'adresses IP afin que les paquets soient envoyés depuis l'adresse IP du nœud (10.0.12.2) au lieu de l'adresse IP du pod. Par défaut, le cluster GKE est configuré pour masquer le trafic vers des destinations externes. Pour en savoir plus, consultez la page Agent de masquage d'adresses IP.

Pour afficher les annotations de pod pour ce trafic, vous pouvez configurer l'agent de masquage afin qu'il ne masque pas les adresses IP de pod. Dans ce cas, pour autoriser le trafic vers Internet, vous pouvez configurer Cloud NAT, qui traite les adresses IP des pods. Pour en savoir plus sur Cloud NAT avec GKE, consultez la section Interaction avec GKE.

Dans cet exemple, l'enregistrement suivant a été trouvé.

reporter	connection.src_ip	connection.dst_ip	bytes_sent	Annotations
SRC	10.0.12.2	203.0.113.1	1 224	src_instance.* src_vpc.* src_gke_details.cluster.* dest_location.* internet_routing_details.*

Étapes suivantes

• Configurez les journaux de flux VPC
• Accédez aux journaux de flux