À propos des flux de trafic

Cette page explique comment les journaux de flux VPC génèrent des 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 de VM

Les sections suivantes incluent des exemples de la façon dont les journaux de flux VPC échantillonnent le trafic envoyé et reçu par les instances de machine virtuelle (VM). Pour en savoir plus sur la façon dont les journaux de flux VPC signalent les journaux de flux pour les pods Google Kubernetes Engine (GKE), consultez la section Flux GKE.

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

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

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 plusieurs VM pour un VPC partagé

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

À 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 de VM avec Cloud Load Balancing

Pour les flux via Cloud Load Balancing, les journaux de flux VPC annotent le trafic envoyé via un équilibreur de charge réseau passthrough, un équilibreur de charge réseau proxy ou un équilibreur de charge d'application. Les exemples suivants supposent que ces équilibreurs de charge sont configurés en tant qu'équilibreurs de charge internes.

Flux entre plusieurs VM via un équilibreur de charge réseau passthrough interne

Lorsque vous ajoutez une VM au service de backend pour un équilibreur de charge réseau passthrough interne, Google Cloud 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 passthrough interne sont rapportés à la fois par la source et par la destination.

Tel que transmis par la VM cliente (192.168.1.2)
request/reply	connection.src_ip	connection.dest_ip	bytes_sent	Annotations
request	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.*
reply	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.*

Tel que transmis par la VM de backend (10.240.0.3)
request/reply	connection.src_ip	connection.dest_ip	bytes	Annotations
request	192.168.1.2	10.240.0.200	1 224	src_instance.* dest_instance.* src_vpc.* dest_vpc.* load_balancing.* (tous les champs, sauf url_map_name)
reply	10.240.0.200	192.168.1.2	5 342	src_instance.* dest_instance.* src_vpc.* dest_vpc.* load_balancing.* (tous les champs, sauf url_map_name)

Dans la requête que l'équilibreur de charge distribue à la VM de backend, l'adresse IP source est définie sur l'adresse IP de la VM cliente. Cela signifie que la VM backend peut fournir des informations src_instance et dest_instance sur la VM cliente. Toutefois, contrairement à la VM de backend, la VM cliente ne peut pas ajouter d'informations src_instance et dest_instance sur la VM de backend à son rapport, car elle envoie la requête à l'adresse IP de l'équilibreur de charge et reçoit la réponse de celle-ci, et non de la VM de backend.

Flux entre une VM et un équilibreur de charge réseau proxy interne, et entre une VM et un équilibreur de charge d'application interne

Les flux de trafic via un équilibreur de charge réseau proxy interne ou un équilibreur de charge d'application interne sont signalés par les VM clientes, à condition que la VM cliente se trouve dans un sous-réseau pour lequel les journaux de flux VPC sont activés. Par exemple, une VM cliente dont l'adresse IP est 10.10.0.2 envoie une requête contenant 1 224 octets au point de terminaison de l'équilibreur de charge, 10.10.0.3. La requête atteint ensuite un backend. À son tour, le backend formule une réponse à la requête,contenant 5 342 octets. La requête et la réponse sont toutes deux enregistrées sur la VM cliente. Les journaux de la VM cliente sont disponibles dans le projet Google Cloud auquel la VM appartient.

Tel que transmis par la VM cliente (10.10.0.2)
request/reply	connection.src_ip	connection.dest_ip	bytes_sent	Annotations
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 (pour l'équilibreur de charge d'application) load_balancing.forwarding_rule_name load_balancing.vpc.*
reply	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 (pour l'équilibreur de charge d'application) load_balancing.forwarding_rule_name load_balancing.vpc.*

Flux VM à VM via Private Service Connect

Pour le trafic VM à VM via Private Service Connect, les journaux de flux VPC échantillonnent les flux entre les consommateurs Private Service Connect et les services publiés.

Point de terminaison Private Service Connect vers un service publié

Les flux de trafic vers les services publiés Private Service Connect sont signalés à la fois par les VM consommatrices et productrices, tant que les deux VM se trouvent dans des sous-réseaux où les journaux de flux VPC sont activés. Dans cet exemple, la VM grand public, 10.10.0.2, envoie une requête contenant 1 224 octets au point de terminaison Private Service Connect, 10.10.0.3. Dans le VPC du producteur, l'adresse IP source de la requête est traduite en adresse IP dans le sous-réseau de l'attachement de service, qui, dans cet exemple, est 10.40.0.2. L'adresse IP de destination de la requête est traduite en adresse IP de l'équilibreur de charge réseau passthrough interne, 10.50.0.3. La requête atteint ensuite la VM backend, 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. Les journaux de la VM cliente sont disponibles dans le projet client, et les journaux de la VM productrice sont disponibles dans le projet productrice.

Tel que transmis par la VM client (10.10.0.2)
request/reply	connection.src_ip	connection.dest_ip	bytes_sent	Annotations
request	10.10.0.2	10.10.0.3	1 224	src_instance.* src_vpc.* psc.reporter psc.psc_endpoint.* psc.psc_attachment.*
reply	10.10.0.3	10.10.0.2	5 342	dest_instance.* dest_vpc.* psc.reporter psc.psc_endpoint.* psc.psc_attachment.*

Tel que transmis par la VM productrice (10.50.0.2)
request/reply	connection.src_ip	connection.dest_ip	bytes_sent	Annotations
request	10.40.0.2	10.50.0.3	1 224	dest_instance.* dest_vpc.* psc.reporter psc.psc_attachment.*
reply	10.50.0.3	10.40.0.2	5 342	src_instance.* src_vpc.* psc.reporter psc.psc_attachment.*

Flux d'API entre une VM et Google

Pour le trafic de VM vers les API Google via l'adresse IP externe de la VM, l'accès privé à Google ou un point de terminaison Private Service Connect, les journaux de flux VPC annotent les enregistrements de journal avec des informations sur les API Google. La section suivante fournit un exemple de la façon dont les journaux de flux VPC annotent les enregistrements de journal d'une VM accédant à une API Google globale via un point de terminaison Private Service Connect.

VM vers une API Google globale via Private Service Connect

Les flux de trafic vers une API Google sont signalés par les VM grand public, à condition que la VM se trouve dans un sous-réseau où les journaux de flux VPC sont activés. Dans cet exemple, la VM grand public, 10.10.0.2, envoie une requête contenant 1 224 octets au point de terminaison Private Service Connect, 10.10.110.10. La requête est transmise au service Google approprié, par exemple Cloud Storage. À son tour, Cloud Storage 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 à l'origine de la requête.

Tel que transmis par la VM client (10.10.0.2)
request/reply	connection.src_ip	connection.dest_ip	bytes_sent	Annotations
request	10.10.0.2	10.10.110.10	1 224	src_instance.* src_vpc.* psc.reporter psc.psc_endpoint.* dest_google_service.*
reply	10.10.110.10	10.10.0.2	5 342	src_google_service.* dest_instance.* dest_vpc.* psc.reporter psc.psc_endpoint.*

Flux GKE

Les sections suivantes incluent des exemples de la façon dont les journaux de flux VPC échantillonnent le trafic GKE à destination et en provenance des pods.

Flux entre le pod et ClusterIP

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

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 passthrough externes 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

Une connexion depuis une adresse IP externe vers une destination Ingress est interrompue au niveau du service Cloud Load Balancing. 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 Ingress GKE 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

Les requêtes provenant d'une adresse IP externe vers une destination 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

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.*

Flux de connectivité hybride

Pour le trafic entre Google Cloud et les réseaux sur site, les journaux de flux VPC annotent les flux entre les instances de VM (y compris les instances utilisées en tant que nœuds GKE) et les points de terminaison sur site, entre les API Google et les points de terminaison sur site, et le trafic de transit entre les points de terminaison sur site. L'exemple suivant décrit comment les journaux de flux VPC annotent les flux entre les instances de VM d'un réseau VPC et un point de terminaison sur site.

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 Google Cloud. Les ressources suivantes génèrent des journaux de flux:

• La VM Génère des journaux de flux si les journaux de flux VPC sont activés pour le sous-réseau auquel la VM est connectée.
• Passerelle qui connecte le réseau VPC au point de terminaison sur site Indique les journaux de flux si les journaux de flux VPC sont activés sur la passerelle.

Dans le schéma précédent, le point de terminaison sur site 10.30.0.2 envoie une requête de 1 224 octets à la VM 10.0.0.2 dans le réseau VPC via Cloud Interconnect. À son tour, la VM 10.0.0.2 formule une réponse à la requête,contenant 5 243 octets. La requête et la réponse sont toutes deux enregistrées à partir du rattachement de VLAN pour Cloud Interconnect et de la VM.

Comme indiqué par le rattachement de VLAN
request/reply	connection.src_ip	connection.dest_ip	bytes_sent	Annotations
request	10.30.0.2	10.10.0.2	1 224	reporter src_gateway.* dest_instance.* dest_vpc.*
reply	10.10.0.2	10.30.0.2	5 342	reporter src_instance.* src_vpc.* dest_gateway.*

Tel que transmis par la VM (10.10.0.2)
request/reply	connection.src_ip	connection.dest_ip	bytes_sent	Annotations
request	10.30.0.2	10.10.0.2	1 224	reporter src_gateway.* dest_instance.* dest_vpc.*
reply	10.10.0.2	10.30.0.2	5 342	reporter src_instance.* src_vpc.* dest_gateway.*

Étape suivante

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