Journaux de flux VPC

Les journaux de flux VPC enregistrent un échantillon des flux réseau envoyés et reçus par les instances de VM, y compris les instances utilisées comme nœuds Google Kubernetes Engine. Ces journaux peuvent être utilisés pour la surveillance et l'investigation des réseaux, l'analyse de la sécurité en temps réel et l'optimisation des dépenses.

Vous pouvez consulter les journaux de flux dans Cloud Logging et exporter les journaux vers n'importe quelle destination compatible avec l'exportation Cloud Logging.

Les journaux de flux sont agrégés par connexion à partir de VM Compute Engine, puis exportés en temps réel. En vous abonnant à Pub/Sub, vous pouvez analyser les journaux de flux à l'aide d'API de streaming en temps réel.

Propriétés clés

  • Les journaux de flux VPC font partie d'Andromeda, le logiciel qui alimente les réseaux VPC. Ils ne causent pas de délai ni de perte de performances lorsqu'ils sont activés.
  • Les journaux de flux VPC fonctionnent avec les réseaux VPC, mais pas avec les anciens réseaux. Vous pouvez activer ou désactiver les journaux de flux VPC pour chaque sous-réseau. Si cette option est activée pour un sous-réseau, les journaux de flux VPC collectent les données issues de toutes les instances de VM de ce sous-réseau.
  • Les journaux de flux VPC échantillonnent les flux TCP, UDP, ICMP, ESP et GRE de chaque VM. Les flux entrants et sortants sont échantillonnés. Il peut s'agir de flux entre deux VM, entre une VM et un hôte de votre centre de données sur site, entre une VM et un service Google, ou entre une VM et un hôte sur Internet. Si un flux est capturé par échantillonnage, les journaux de flux VPC génèrent un journal pour le flux. Chaque enregistrement de flux inclut les informations décrites dans la section Format de l'enregistrement.
  • Les journaux de flux VPC interagissent avec les règles de pare-feu de la manière suivante :
    • Les paquets de sortie sont échantillonnés avant les règles de pare-feu de sortie. Même si une règle de pare-feu de sortie refuse les paquets sortants, ces paquets peuvent être échantillonnés par les journaux de flux VPC.
    • Les paquets d'entrée sont échantillonnés après les règles de pare-feu d'entrée. Si une règle de pare-feu d'entrée refuse les paquets entrants, ces paquets ne sont pas échantillonnés par les journaux de flux VPC.
  • Vous pouvez utiliser des filtres dans les journaux de flux VPC pour ne générer que certains journaux.
  • Les journaux de flux VPC sont compatibles avec les VM ayant plusieurs interfaces réseau. Vous devez activer les journaux de flux VPC pour chaque sous-réseau, dans chaque VPC contenant une interface réseau.
  • Pour enregistrer les flux entre les pods sur le même nœud Google Kubernetes Engine (GKE), vous devez activer la visibilité intranœud pour le cluster.

Cas d'utilisation

Surveillance du réseau

Les journaux de flux VPC vous offrent une visibilité en temps réel du débit et des performances du réseau. Grâce à eux, vous pouvez :

  • surveiller le réseau VPC ;
  • réaliser un diagnostic du réseau ;
  • filtrer les journaux de flux par VM et par application pour comprendre les évolutions du trafic ;
  • comprendre la croissance du trafic pour prévoir les besoins en capacité.

Comprendre l'utilisation du réseau et optimiser les frais liés au trafic réseau

Vous pouvez analyser l'utilisation du réseau grâce aux journaux de flux VPC. Vous pouvez analyser les flux du réseau pour les éléments suivants :

  • Trafic entre régions et zones
  • Trafic vers certains pays sur Internet
  • Top talkers

Sur la base de l'analyse, vous pouvez optimiser les dépenses liées au trafic réseau.

Investigation numérique du réseau

Vous pouvez utiliser les journaux de flux VPC pour analyser le réseau. Par exemple, en cas d'incident, vous pouvez examiner :

  • les adresses IP impliquées, et avec qui et quand elles ont communiqué ;
  • les éventuelles adresses IP compromises en analysant tous les flux réseau entrants et sortants.

Analyse de la sécurité en temps réel

Vous pouvez exploiter les API de streaming en temps réel (via Pub/Sub) et les intégrer aux systèmes SIEM (Security Information and Event Management, gestion des informations et des événements de sécurité). Vous obtenez ainsi une surveillance en temps réel, la corrélation des événements, ainsi que des analyses et des alertes de sécurité.

Collecte de journaux

Les journaux de flux sont collectés pour chaque connexion à une VM à des intervalles spécifiques. Tous les paquets collectés pour un intervalle et une connexion donnés sont agrégés pendant une certaine période (intervalle d'agrégation) en une seule entrée de journal de flux. Ces données sont ensuite envoyées à Logging.

Par défaut, les journaux sont stockés dans Logging pendant 30 jours. Si vous souhaitez les conserver plus longtemps, vous pouvez définir une durée de conservation personnalisée ou les exporter vers une destination compatible.

Échantillonnage et traitement des journaux

Google Cloud échantillonne les paquets qui quittent une VM et y entrent pour générer des journaux de flux. Les paquets ne sont pas tous capturés dans leur propre enregistrement de journal. Environ un paquet sur 30 est capturé, mais ce taux d'échantillonnage peut être inférieur en fonction de la charge de la VM. Vous ne pouvez pas ajuster ce taux.

Une fois les journaux de flux générés, Google Cloud les traite selon la procédure suivante :

  1. Filtrage : vous pouvez faire en sorte que seuls les journaux correspondant aux critères spécifiés soient générés. Par exemple, vous pouvez filtrer de manière à ne générer que les journaux d'une VM spécifique ou uniquement ceux contenant une valeur de métadonnées particulière, et ignorer les autres. Pour en savoir plus, consultez la section Filtrage des journaux.
  2. Agrégation : les informations des paquets échantillonnés sont agrégées sur un intervalle d'agrégation configurable pour générer une entrée de journal de flux.
  3. Échantillonnage de journal de flux : il s'agit d'un deuxième processus d'échantillonnage. Les entrées de journal de flux sont ré-échantillonnées en fonction d'un paramètre de taux d'échantillonnage configurable.
  4. Métadonnées : si elles sont désactivées, toutes les annotations de métadonnées sont supprimées. Si vous souhaitez conserver les métadonnées, vous pouvez spécifier que tous les champs ou un ensemble de champs spécifié sont conservés. Pour en savoir plus, consultez la section Annotations de métadonnées.
  5. Écriture dans Logging : les entrées de journal finales sont écrites dans Cloud Logging.

Comme les journaux de flux VPC ne capturent pas tous les paquets, ils compensent les paquets manquants en effectuant une interpolation à partir des paquets capturés. Cette opération se produit pour les paquets manqués en raison de paramètres d'échantillonnage initiaux et configurables par l'utilisateur.

Bien que Google Cloud ne capture pas tous les paquets, les captures d'enregistrements de journal peuvent être relativement volumineuses. Vous pouvez équilibrer vos besoins en termes de visibilité du trafic et de coûts de stockage en ajustant les aspects suivants de la collecte de journaux :

  • Intervalle d'agrégation : les paquets échantillonnés pendant un intervalle de temps sont agrégés dans une seule entrée de journal. Cet intervalle de temps peut être de 5 secondes (par défaut), 30 secondes, 1 minute, 5 minutes, 10 minutes ou 15 minutes.
  • Taux d'échantillonnage : avant leur écriture dans Logging, vous pouvez échantillonner les journaux pour en réduire le nombre. Par défaut, le volume des entrées de journal est réduit de 0,5 (50 %), ce qui signifie que la moitié des entrées sont conservées. Cette valeur peut être comprise entre 1.0 (100 %, toutes les entrées de journal sont conservées) et 0.0 (0 %, aucun journal n'est conservé).
  • Annotations de métadonnées : par défaut, les entrées de journal de flux sont annotées avec des informations de métadonnées, telles que les noms des VM sources et de destination, ou bien la région géographique des sources et des destinations externes. Les annotations de métadonnées peuvent être désactivées ou vous pouvez ne spécifier que certaines annotations pour économiser de l'espace de stockage.
  • Filtrage : par défaut, les journaux sont générés pour chaque flux du sous-réseau. Vous pouvez définir des filtres de sorte que seuls les journaux correspondant à certains critères soient générés.

Annotations des métadonnées

Les enregistrements de journal contiennent des champs de base et des champs de métadonnées. La section Format de l'enregistrement répertorie les champs qui sont des métadonnées de type et ceux de base. Tous les champs de base sont toujours inclus. Vous pouvez personnaliser les champs de métadonnées à conserver.

  • Si vous sélectionnez toutes les métadonnées, tous les champs de métadonnées au format d'enregistrement des journaux de flux VPC sont inclus dans les journaux de flux. Lorsque de nouveaux champs de métadonnées sont ajoutés au format d'enregistrement, les journaux de flux incluent automatiquement les nouveaux champs.

  • Si vous ne sélectionnez aucune métadonnée, tous les champs de métadonnées sont omis.

  • Si vous sélectionnez des métadonnées personnalisées, vous pouvez spécifier les champs de métadonnées que vous souhaitez inclure par le champ parent, tels que src_vpc, ou par leur nom complet, par exemple src_vpc.project_id.

    Lorsque de nouveaux champs de métadonnées sont ajoutés au format d'enregistrement, les journaux de flux n'incluent pas ces champs, sauf s'ils sont un nouveau champ dans un champ parent que vous avez spécifié.

    • Si vous spécifiez des métadonnées personnalisées à l'aide de champs parents, lorsque de nouveaux champs de métadonnées sont ajoutés au format d'enregistrement au sein de ce champ parent, les journaux de flux incluent automatiquement les nouveaux champs.

    • Si vous spécifiez des métadonnées personnalisées à l'aide du nom complet du champ, lorsque de nouveaux champs de métadonnées sont ajoutés au champ parent, les journaux de flux n'incluent pas les nouveaux champs.

Pour en savoir plus sur la personnalisation des champs de métadonnées, consultez les instructions de gcloud CLI ou de l'API pour activer la journalisation de flux VPC lorsque vous créez un sous-réseau.

Annotations GKE

Les flux comportant un point de terminaison dans un cluster GKE peuvent être annotés avec des annotations GKE, qui peuvent inclure des détails sur le cluster, le pod et le service du point de terminaison.

Annotations de service GKE

Le trafic envoyé à une ressource ClusterIP, NodePort ou LoadBalancer peut recevoir des annotations de service. Si le trafic est envoyé à une ressource NodePort ou LoadBalancer, le flux reçoit l'annotation de service sur les deux sauts de la connexion.

Le trafic envoyé directement au port de service d'un pod est annoté avec une annotation de service sur le point de terminaison de destination.

Le trafic envoyé au port de service d'un pod où le pod sauvegarde plusieurs services sur le même port de service est annoté avec plusieurs services sur le point de terminaison de destination. Ce processus est limité à deux services. S'il y en a plus, le point de terminaison sera annoté avec un marqueur MANY_SERVICES spécial.

Annotations de pod sur le trafic Internet

Le trafic entre un pod et Internet ne reçoit pas d'annotations de pod par défaut. Pour les paquets à destination d'Internet, l'agent de masquage traduit l'adresse IP du pod en adresse IP du nœud avant que les journaux de flux VPC ne voient le paquet. Par conséquent, les journaux de flux VPC ne savent rien du pod et ne peuvent pas ajouter d'annotations de pod.

En raison du masquage, les annotations de pod ne sont visibles que si les destinations se trouvent dans l'un des deux emplacements suivants : des destinations non masquées par défaut ou une liste nonMasqueradeCIDRs personnalisée. Si vous incluez des destinations Internet dans une liste nonMasqueradeCIDRs personnalisée, vous devez fournir un moyen de traduire les adresses IP internes du pod avant qu'elles ne soient transmises à Internet. Pour les clusters privés et non privés, vous pouvez utiliser Cloud NAT. Consultez la section Interaction avec GKE pour en savoir plus.

Format de l'enregistrement

Les enregistrements de journal contiennent des champs de base, qui constituent les principaux champs de chaque enregistrement de journal, ainsi que des champs de métadonnées qui ajoutent des informations supplémentaires. Les champs de métadonnées peuvent être omis pour réduire les coûts de stockage.

Le format "multi-champs" de certains champs affiche plusieurs données dans un même champ. Par exemple, le champ connection est au format IpConnection, qui contient l'adresse IP et les ports sources et de destination ainsi que le protocole, dans un seul champ. Ces champs particuliers sont décrits sous le tableau relatif au format de l'enregistrement.

Champ Format du champ Type de champ : métadonnées de base ou facultatives
connexion IpConnection
5-tuple décrivant cette connexion.
Couches
reporter string
Côté ayant signalé le flux. Défini sur SRC ou DEST.
Couches
rtt_msec int64
Latence mesurée pendant l'intervalle de temps, seulement pour les flux TCP. La latence mesurée correspond au temps écoulé entre l'envoi d'une séquence et la réception de l'indicateur ACK correspondant. Le résultat de la latence correspond à la somme de la latence DAR du réseau et de tout délai lié à l'application.
Couches
bytes_sent int64
Quantité d'octets envoyés depuis la source vers la destination.
Couches
packets_sent int64
Nombre de paquets envoyés depuis la source vers la destination.
Couches
start_time string
Horodatage (format de chaîne de date RFC 3339) du premier paquet observé pendant l'intervalle de temps cumulé.
Couches
end_time string
Horodatage (format de chaîne de date RFC 3339) du dernier paquet observé pendant l'intervalle de temps cumulé.
Couches
src_gke_details GkeDetails
Métadonnées GKE pour les points de terminaison sources. Disponible uniquement si le point de terminaison est un point GKE.
Métadonnées
dest_gke_details GkeDetails
Métadonnées GKE pour les points de terminaison de destination. Disponible uniquement si le point de terminaison est un point GKE.
Métadonnées
src_instance InstanceDetails
Si la source de la connexion est une VM située sur le même réseau VPC, les détails de l'instance de VM sont insérés dans ce champ. Dans une configuration de réseau VPC partagé, project_id correspond au projet propriétaire de l'instance, généralement le projet de service.
Métadonnées
dest_instance InstanceDetails
Si la destination de la connexion est une VM située sur le même réseau VPC, les détails de l'instance de VM sont insérés dans ce champ. Dans une configuration de réseau VPC partagé, project_id correspond au projet propriétaire de l'instance, généralement le projet de service.
Métadonnées
src_location GeographicDetails
Si la source de la connexion est externe au réseau VPC, les métadonnées disponible relatives à l'emplacement sont insérées dans ce champ.
Métadonnées
dest_location GeographicDetails
Si la destination de la connexion est externe au réseau VPC, les métadonnées disponibles relatives à l'emplacement sont insérées dans ce champ.
Métadonnées
src_vpc VpcDetails
Si la source de la connexion est une VM située sur le même réseau VPC, les détails du réseau VPC sont insérés dans ce champ. Dans une configuration de VPC partagé, project_id correspond à l'ID du projet hôte.
Métadonnées
dest_vpc VpcDetails
Si la destination de la connexion est une VM située sur le même réseau VPC, les détails du réseau VPC sont insérés dans ce champ. Dans une configuration de VPC partagé, project_id correspond à l'ID du projet hôte.
Métadonnées

Format de champ IpConnection

Champ Type Description
protocol int32 Numéro de protocole IANA
src_ip string Adresse IP source
dest_ip string Adresse IP de destination
src_port int32 Port source
dest_port int32 Port de destination

Format de champ GkeDetails

Champ Type Description
Cluster ClusterDetails Métadonnées du cluster GKE.
pod PodDetails Métadonnées du pod GKE, renseignées lorsque la source ou la destination du trafic est un pod.
service ServiceDetails Métadonnées du service GKE, renseignées seulement dans les points de terminaison du service. L'enregistrement contient jusqu'à deux services. S'il existe plus de deux services pertinents, ce champ contient un seul service avec un marqueur MANY_SERVICES spécial.

Format de champ ClusterDetails

Champ Type Description
cluster_location chaîne Emplacement du cluster. Il peut s'agir d'une zone ou d'une région selon que le cluster est zonal ou régional.
cluster_name chaîne Nom du cluster GKE.

Format de champ PodDetails

Champ Type Description
pod_name chaîne Nom du pod
pod_namespace chaîne Espace de noms du pod

Format de champ ServiceDetails

Champ Type Description
service_name chaîne Nom du service. S'il existe plus de deux services pertinents, le champ est défini sur un marqueur MANY_SERVICES spécial.
service_namespace chaîne Espace de noms du service.

Exemple :

S'il existe deux services, le champ "Service" se présente comme suit :

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

S'il existe plus de deux services, le champ "Service" se présente comme suit :

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

Format de champ InstanceDetails

Champ Type Description
project_id string ID du projet contenant la VM
region string Région de la VM
vm_name string Nom d'instance de la VM
zone string Zone de la VM

Format de champ GeographicDetails

Champ Type Description
asn int32 Numéro ASN (Autonomous System Number) du réseau externe auquel appartient ce point de terminaison
city string Ville des points de terminaison externes
continent string Continent des points de terminaison externes
country chaîne Pays des points de terminaison externes, représentés par leurs codes pays sur trois lettres (code alpha-3 selon l'ISO 3166-1).
region string Région des points de terminaison externes

Format de champ VpcDetails

Champ Type Description
project_id string ID du projet contenant le VPC
subnetwork_name string Sous-réseau sur lequel la VM fonctionne
vpc_name string VPC sur lequel la VM fonctionne

Filtrage des journaux

Lorsque vous activez les journaux de flux VPC, vous pouvez définir un filtre basé sur les champs de base et de métadonnées qui ne conservent que les journaux correspondant au filtre. Tous les autres journaux sont supprimés avant d'être écrits dans Logging, ce qui vous permet de réaliser des économies et de réduire le temps nécessaire à la localisation des informations recherchées.

Vous pouvez filtrer sur n'importe quel sous-ensemble des champs décrits dans la section Format des enregistrements.

Le filtrage des journaux de flux VPC utilise CEL, un langage d'expression intégré pour les expressions logiques basées sur des attributs. Les expressions de filtre pour les journaux de flux VPC sont limitées à 2 048 caractères. Pour en savoir plus, consultez la section Opérateurs logiques CEL compatibles.

Pour plus d'informations sur la syntaxe CEL, consultez la présentation de CEL et la définition du langage. La fonctionnalité de filtre de génération est compatible avec un sous-ensemble limité de la syntaxe CEL.

Pour en savoir plus sur la création d'un sous-réseau qui utilise le filtrage de journaux, consultez les instructions de gcloud CLI ou de l'API pour Activer les journaux de flux VPC lorsque vous créez un sous-réseau.

Pour en savoir plus sur la configuration du filtrage des journaux, consultez les instructions de gcloud CLI ou de l'API pour mettre à jour les paramètres des journaux de flux VPC.

Exemple 1 : Limiter la collecte des journaux à une VM spécifique nommée my-vm. Dans ce cas, les journaux ne sont enregistrés que lorsque le champ src_instance, tel qu'il est signalé par la source du trafic, correspond à my-vm ou lorsque le champ dst_instance, tel qu'il est signalé par la destination du trafic, correspond à my-vm.

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')"

Exemple 2 : Limiter la collecte des journaux aux paquets dont les adresses IP sources se trouvent dans le sous-réseau 10.0.0.0/8.

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

Exemple 3 : Limiter la collecte des journaux au trafic externe à un VPC

gcloud compute networks subnets update my-subnet \
    --logging-filter-expr '!(has(src_vpc.vpc_name) && has(dest_vpc.vpc_name))'

Opérateurs logiques CEL compatibles

Expression Types compatibles Description
true, false Booléen Constantes booléennes

x == y

x != y

Boolean, Int, String

Opérateurs de comparaison

Exemple : connection.protocol == 6

x && y

x || y

Booléen

Opérateurs logiques booléens

Exemple : connection.protocol == 6 && src_instance.vm_name == "vm_1"

!x Booléen Négation
1, 2.0, 0, ... Int Littéraux numériques constants
x + y String Concaténation de chaînes
"foo", 'foo', ... String Littéral de chaîne constante
x.lower() String Renvoie la valeur en minuscules de la chaîne
x.upper() String Renvoie la valeur en majuscules de la chaîne
x.contains(y) String Renvoie la valeur "true" si la chaîne contient la sous-chaîne spécifiée
x.startsWith(y) String Renvoie la valeur "true" si la chaîne commence par la sous-chaîne spécifiée
x.endsWith(y) String Renvoie la valeur "true" si la chaîne se termine par la sous-chaîne spécifiée
inIpRange(X, Y) String

Renvoie la valeur "true" si X est une adresse IP et si Y est une plage d'adresses IP contenant X.

Exemple : inIpRange("1.2.3.1", "1.2.3.0/24")

x.containsFieldValue(y) x: list
y: map(string, string)

Renvoie la valeur "true" si la liste contient un objet dont les champs correspondent aux paires clé/valeur spécifiées.

Exemple : dest_gke_details.service.containsFieldValue({'service_name': 'service1', 'service_namespace': 'namespace1'})

has(x) String

Renvoie la valeur "true" si le champ est présent.

Exemples de modèle de trafic

Cette section explique le fonctionnement des journaux de flux VPC dans divers cas d'utilisation.

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

Flux entre VM au sein d'un 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
requête 10.10.0.2 10.50.0.2 1 224 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*
reply 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
requête 10.10.0.2 10.50.0.2 1 224 src_instance.*
dest_instance.*
src_vpc.*
dest_vpc.*
reply 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.
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
requête 10.10.0.2 203.0.113.5 1 224 src_instance.*
src_vpc.*
dest_location.*
reply 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.
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
requête 10.10.0.2 10.30.0.2 1 224 src_instance.*
src_vpc.*
reply 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é.
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 "webserver" (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 webserver 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).
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).
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).
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).
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. 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).
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).
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).
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.*

Tarifs

Pour Logging, BigQuery et Pub/Sub, la tarification standard s'applique. Les tarifs des journaux de flux VPC sont présentés dans les tarifs de télémétrie réseau.

FAQ

  • Les journaux de flux VPC incluent-ils à la fois le trafic autorisé et le trafic refusé en fonction des règles de pare-feu ?

    • Les journaux de flux VPC couvrent le trafic du point de vue d'une VM. L'ensemble du trafic sortant d'une VM est journalisé, même s'il est bloqué par une règle de pare-feu de refus du trafic sortant. Le trafic entrant est journalisé s'il est autorisé par une règle de pare-feu d'autorisation du trafic entrant. Le trafic entrant bloqué par une règle de pare-feu de refus du trafic entrant n'est pas journalisé.
  • Les journaux de flux VPC fonctionnent-ils avec des instances de VM à plusieurs interfaces ?

  • Les journaux de flux VPC fonctionnent-ils avec les anciens réseaux ?

    • Non, les journaux de flux VPC ne sont pas disponibles sur les anciens réseaux.

Étapes suivantes