Mise en miroir de paquets

Cette page présente la mise en miroir de paquets.

La mise en miroir de paquets clone le trafic de certaines instances spécifiées de votre réseau privé virtuel (VPC, Virtual Private Cloud) et le transfère pour examen. La mise en miroir de paquets permet de capturer toutes les données relatives au trafic et aux paquets, y compris les charges utiles et les en-têtes. La capture peut être configurée pour le trafic sortant et entrant, uniquement pour le trafic entrant ou uniquement pour le trafic sortant.

La mise en miroir a lieu sur les instances de machine virtuelle (VM), et non sur le réseau. Par conséquent, la mise en miroir de paquets consomme une quantité supplémentaire de bande passante au niveau des VM.

La mise en miroir de paquets est utile lorsque vous devez surveiller et analyser l'état de la sécurité. Ce mécanisme exporte l'intégralité du trafic, pas seulement le trafic sur des périodes d'échantillonnage. Par exemple, vous pouvez utiliser un logiciel de sécurité qui analyse le trafic mis en miroir afin de détecter toute menace ou anomalie. En outre, vous pouvez inspecter l'intégralité du flux de trafic afin de détecter des problèmes de performances des applications. Pour plus d'informations, consultez les exemples de cas d'utilisation.

Fonctionnement

La mise en miroir de paquets copie le trafic en provenance des sources mises en miroir et l'envoie à une destination de collecteur. Pour configurer la mise en miroir de paquets, vous devez créer une règle de mise en miroir de paquets qui spécifie la source et la destination.

  • Les sources mises en miroir sont des instances de VM Compute Engine que vous pouvez sélectionner en spécifiant des sous-réseaux, des tags réseau ou des noms d'instances. Si vous spécifiez un sous-réseau, toutes les instances existantes et futures de ce sous-réseau sont mises en miroir. Vous pouvez spécifier un ou plusieurs types de sources. Si une instance correspond à l'un au moins de ces types, elle est mise en miroir.

    La mise en miroir de paquets collecte le trafic à partir de l'interface réseau d'une instance appartenant au réseau auquel s'applique la règle de mise en miroir. Dans le cas d'une instance possédant plusieurs interfaces réseau, les autres interfaces ne sont pas mises en miroir, à moins qu'une autre règle ait été configurée dans ce but.

  • Une destination de collecteur est un groupe d'instances situé derrière un équilibreur de charge interne. Les instances du groupe d'instances sont appelées instances de collecteur.

    Lorsque vous spécifiez la destination de collecteur, saisissez le nom d'une règle de transfert associée à l'équilibreur de charge réseau interne à stratégie directe. Google Cloud transfère alors le trafic mis en miroir vers les instances de collecteur. Un équilibreur de charge interne pour la mise en miroir de paquets est semblable aux autres équilibreurs de charge internes, à la différence près que la règle de transfert doit être configurée pour la mise en miroir de paquets. Le trafic non mis en miroir envoyé à l'équilibreur de charge est abandonné.

Filtrage

Par défaut, la mise en miroir de paquets collecte l'intégralité du trafic IPv4 des instances mises en miroir. Plutôt que de collecter l'intégralité du trafic IPv4, vous pouvez utiliser des filtres pour étendre le trafic collecté afin d'inclure tout ou partie du trafic IPv6. Vous pouvez également utiliser des filtres pour affiner le trafic mis en miroir, ce qui peut vous aider à limiter la bande passante utilisée par les instances mises en miroir.

Vous pouvez configurer des filtres pour collecter le trafic en fonction du protocole, des plages CIDR (IPv4, IPv6 ou les deux), du sens du trafic (entrant uniquement, sortant uniquement ou les deux) ou d'une combinaison de ces paramètres.

Ordre des règles

Plusieurs règles de mise en miroir de paquets peuvent s'appliquer à une même instance. La priorité d'une règle de mise en miroir de paquets est toujours définie sur 1000 et ne peut pas être modifiée. Les règles identiques ne sont pas acceptées. Google Cloud peut envoyer du trafic vers n'importe quel équilibreur de charge configuré avec des règles de mise en miroir de paquets identiques. Pour envoyer de manière prévisible et cohérente le trafic mis en miroir vers un seul équilibreur de charge, créez des règles dotées de filtres dont les plages d'adresses ne se chevauchent pas. Si les plages se chevauchent, définissez des protocoles de filtrage uniques.

En fonction du filtre de chaque règle, Google Cloud choisit une stratégie pour chaque flux. Si vous avez des règles distinctes, Google Cloud utilise la règle qui correspond au trafic mis en miroir. Par exemple, vous pouvez avoir une règle associée au filtre 198.51.100.3/24:TCP et une autre associée au filtre 2001:db8::/64:TCP:UDP. Ces règles étant distinctes, il n'existe aucune ambiguïté sur celle que Google Cloud doit appliquer.

Toutefois, si certaines de vos règles se chevauchent, Google Cloud évalue leurs filtres afin de choisir la règle à utiliser. Par exemple, imaginons que vous ayez deux règles, l'une avec un filtre pour 10.0.0.0/24:TCP et l'autre pour 10.0.0.0/16:TCP. Ces règles se chevauchent, car leurs plages CIDR elles-mêmes se chevauchent.

Lors du choix d'une règle, Google Cloud hiérarchise les règles en comparant la taille de la plage CIDR associée au filtre.

Google Cloud choisit une règle en fonction d'un filtre :

  • Si les règles possèdent exactement le même protocole et des plages CIDR différentes mais se chevauchant, Google Cloud choisit la règle qui utilise la plage CIDR la plus spécifique. Supposons que la destination d'un paquet TCP quittant une instance mise en miroir soit 10.240.1.4 et qu'il existe deux règles associées aux filtres suivants : 10.240.1.0/24:ALL et 10.240.0.0/16:TCP. La correspondance la plus spécifique pour 10.240.1.4 étant 10.240.1.0/24:ALL, Google Cloud utilise la règle associée au filtre 10.240.1.0/24:ALL.

  • Si les règles spécifient exactement la même plage CIDR avec des protocoles qui se chevauchent, Google Cloud choisit la règle ayant le protocole le plus spécifique. Par exemple, les filtres suivants possèdent la même plage, mais leurs protocoles se chevauchent : 10.240.1.0/24:TCP et 10.240.1.0/24:ALL. Pour mettre en correspondance le trafic TCP, Google Cloud utilise la règle 10.240.1.0/24:TCP. La règle 10.240.1.0/24:ALL s'applique au trafic correspondant pour tous les autres protocoles.

  • Si les règles possèdent exactement la même plage CIDR, mais des protocoles distincts, ces règles ne se chevauchent pas. Google Cloud utilise la règle correspondant au protocole du trafic mis en miroir. Par exemple, vous pouvez avoir une règle pour 2001:db8::/64:TCP et une autre pour 2001:db8::/64:UDP. Suivant le protocole du trafic mis en miroir, Google Cloud utilise soit la règle TCP, soit la règle UDP.

  • Si des règles qui se chevauchent possèdent exactement le même filtre, elles sont identiques. Dans ce cas, Google Cloud peut choisir la même règle ou une règle différente à chaque fois que le trafic correspondant est réévalué en fonction de ces règles. Nous vous recommandons d'éviter de créer des règles de mise en miroir de paquets identiques.

Journaux de flux VPC

Les journaux de flux VPC ne consignent pas les paquets en miroir. Si une instance de collecteur se trouve sur un sous-réseau sur lequel les journaux de flux VPC sont activés, le trafic envoyé directement à l'instance du collecteur est journalisé, y compris le trafic provenant d'instances en miroir. Autrement dit, si l'adresse IPv4 ou IPv6 de destination d'origine correspond à l'adresse IPv4 ou IPv6 de l'instance du collecteur, le flux est journalisé.

Pour en savoir plus sur les journaux de flux VPC, consultez la section Utiliser des journaux de flux VPC.

Propriétés clés

La liste suivante décrit les contraintes ou comportements liés à la mise en miroir de paquets que vous devez bien comprendre avant toute utilisation :

  • Chaque règle de mise en miroir de paquets définit des sources mises en miroir et une destination de collecteur. Vous devez respecter les règles suivantes :

    • Toutes les sources mises en miroir doivent se trouver dans les mêmes projet, réseau VPC et région Google Cloud.
    • La destination d'un collecteur doit se trouver dans la même région que les sources mises en miroir. Une destination de collecteur peut se trouver sur le même réseau VPC que les sources mises en miroir ou sur un réseau VPC connecté au réseau des sources mises en miroir à l'aide de l'appairage de réseaux VPC.
    • Chaque règle de mise en miroir ne peut référencer qu'une seule destination de collecteur. Toutefois, une même destination de collecteur peut être référencée par plusieurs règles de mise en miroir.

  • Tous les protocoles de couche 4 sont compatibles avec la mise en miroir de paquets.

  • Vous ne pouvez pas simultanément mettre en miroir et collecter le trafic sur la même interface réseau d'une instance de VM, car cela entraînerait une boucle de mise en miroir.

  • Pour mettre en miroir le trafic entre les pods sur le même nœud Google Kubernetes Engine (GKE), vous devez activer la visibilité intranœud pour le cluster.

  • Pour mettre en miroir le trafic IPv6, utilisez des filtres pour spécifier les plages CIDR IPv6 du trafic IPv6 que vous souhaitez mettre en miroir. Vous pouvez mettre en miroir l'ensemble du trafic IPv6 à l'aide d'un filtre de plage CIDR ::/0. Vous pouvez mettre en miroir l'ensemble du trafic IPv4 et IPv6 en utilisant le filtre suivant (plages CIDR séparées par une virgule) : 0.0.0.0/0,::/0.

  • La mise en miroir du trafic consomme de la bande passante sur l'instance mise en miroir. Par exemple, si une instance mise en miroir génère 1 Gbit/s de trafic d'entrée et 1 Gbit/s de trafic de sortie, le trafic total sur cette instance est de 1 Gbit/s en entrée et 3 Gbit/s en sortie (1 Gbit/s de trafic de sortie normal, ainsi que 2 Gbit/s de trafic de sortie généré par la mise en miroir). Vous pouvez utiliser des filtres pour limiter le trafic collecté.

  • Le coût de la mise en miroir de paquets varie selon le volume du trafic de sortie circulant depuis une instance mise en miroir vers un groupe d'instances. Si le trafic doit circuler à travers plusieurs zones, cela influe également sur le coût.

  • La mise en miroir de paquets s'applique dans les deux directions de trafic, entrée et sortie. Si deux instances de VM mises en miroir s'envoient mutuellement du trafic, Google Cloud collecte deux versions du même paquet. Vous pouvez modifier ce comportement en spécifiant que seuls les paquets d'entrée ou seuls les paquets de sortie sont mis en miroir.

  • Il existe une limite maximale concernant le nombre de règles de mise en miroir de paquets que vous pouvez créer pour un projet donné. Pour plus d'informations, consultez les quotas appliqués par projet sur la page Quotas.

  • Pour chaque règle de mise en miroir de paquets, le nombre maximal de sources mises en miroir que vous pouvez spécifier dépend du type de source :

    • 5 sous-réseaux
    • 5 tags
    • 50 instances

  • Le nombre maximal de filtres de mise en miroir de paquets est de 30 (le nombre de plages d'adresses IPv4 et IPv6 multiplié par le nombre de protocoles). Par exemple, vous pouvez spécifier 30 plages et 1 protocole, soit 30 filtres. Cependant, vous ne pouvez pas spécifier 30 plages et 2 protocoles : cela équivaut à 60 filtres, ce qui dépasse donc la limite autorisée.

  • La quantité de données traitées par mise en miroir de paquets vous est facturée. Pour en savoir plus, consultez les tarifs applicables à la mise en miroir de paquets.

    Tous les composants prérequis et le trafic de sortie lié à la mise en miroir de paquets vous sont également facturés. Par exemple, les instances collectant du trafic sont facturées au tarif standard. En outre, si le trafic lié à la mise en miroir de paquets circule à travers plusieurs zones, vous êtes facturé pour le trafic de sortie. Pour en savoir plus sur les tarifs, consultez la page de tarification correspondante.

  • Le trafic mis en miroir n'est chiffré que si la VM chiffre ce trafic au niveau de la couche d'application. Bien que les connexions entre plusieurs VM au sein des réseaux VPC et réseaux VPC appairés soient chiffrées, le chiffrement et le déchiffrement s'effectuent dans les hyperviseurs. Du point de vue de la VM, ce trafic n'est pas chiffré.

Cas d'utilisation

Les sections suivantes décrivent des scénarios réels démontrant l'intérêt de la mise en miroir de paquets.

Sécurité d'entreprise

Les équipes chargées de la sécurité et de l'ingénierie réseau doivent s'assurer qu'elles détectent toute anomalie ou menace susceptible de constituer des violations de sécurité et des intrusions. Elles mettent en miroir l'intégralité du trafic afin de pouvoir examiner de manière exhaustive les flux suspects. Une attaque pouvant s'étendre sur plusieurs paquets, les équipes chargées de la sécurité doivent être en mesure de recevoir la totalité des paquets de chaque flux.

Par exemple, les outils de sécurité suivants nécessitent de capturer plusieurs paquets :

  • Pour que les outils de type système de détection des intrusions (IDS, Intrusion Detection System) puissent détecter les menaces persistantes, il est nécessaire que les différents paquets issus d'un même flux correspondent à une signature.

  • Les moteurs d'inspection approfondie des paquets examinent les charges utiles des paquets pour détecter des anomalies de protocole.

  • La criminalistique des réseaux pour la conformité PCI et autres cas d'utilisation réglementaires exigent que la plupart des paquets soient examinés. La mise en miroir de paquets permet de capturer différents vecteurs d'attaque, tels que des communications peu fréquentes ou des tentatives de communication infructueuses.

Surveillance des performances des applications

Les ingénieurs réseau peuvent utiliser le trafic mis en miroir pour résoudre les problèmes de performances signalés par les équipes chargées des applications et des bases de données. Pour détecter les problèmes de réseau, les ingénieurs réseau peuvent suivre ce qui circule sur le réseau au lieu de s'appuyer sur les journaux d'application.

Par exemple, les ingénieurs réseau peuvent utiliser les données issues de la mise en miroir de paquets pour effectuer les tâches suivantes :

  • Analyser les protocoles et comportements afin de détecter et de résoudre les problèmes, tels que la perte de paquets ou les réinitialisations TCP.

  • Analyser (en temps réel) les modèles se dégageant du trafic émis par les applications de bureau à distance, de VoIP et autres applications interactives. Les ingénieurs réseau peuvent investiguer les problèmes affectant l'expérience des utilisateurs de l'application, tels que des renvois de paquets multiples ou des reconnexions plus nombreuses que prévu.

Exemples de topologies de destination de collecteur

Vous pouvez utiliser la mise en miroir de paquets dans le cadre de différentes configurations. Les exemples suivants illustrent l'emplacement des destinations de collecteur et les règles associées pour différentes configurations de mise en miroir de paquets, telles que l'appairage de réseaux VPC et le VPC partagé.

Destination de collecteur appartenant au même réseau

L'exemple suivant illustre une configuration de mise en miroir de paquets dans laquelle la source mise en miroir et la destination de collecteur se trouvent dans le même réseau VPC.

Dans le diagramme précédent, la règle de mise en miroir de paquets est configurée pour mettre en miroir le sous-réseau mirrored-subnet et envoyer le trafic mis en miroir à l'équilibreur de charge réseau interne à stratégie directe. Google Cloud met en miroir le trafic sur toutes les instances existantes et futures du sous-réseau. Tout le trafic en provenance et à destination d'Internet, des hôtes sur site ou des services Google est mis en miroir.

Destination de collecteur dans un réseau appairé

Vous pouvez créer un modèle de collecteur centralisé, dans lequel les instances situées dans différents réseaux VPC envoient leur trafic mis en miroir vers une destination collecteur dans un réseau VPC central. Ainsi, vous pouvez utiliser une seule destination de collecteur.

Dans l'exemple suivant, l'équilibreur de charge réseau interne à stratégie directe collector-load-balancer se trouve dans la région us-central1 du réseau VPC network-a dans project-a. Cette destination de collecteur peut être utilisée par deux règles de mise en miroir de paquets :

  • policy-1 collecte les paquets des sources mises en miroir dans la région us-central1 du réseau VPC network-a de project-a et les envoie à la destination collector-load-balancer.

  • policy-2 collecte les paquets des sources mises en miroir dans la région us-central1 du réseau VPC network-b de project-b et les envoie à la même destination collector-load-balancer.

Deux règles de mise en miroir sont requises, car les sources mises en miroir existent dans différents réseaux VPC.

Dans le diagramme précédent, la destination de collecteur recueille le trafic mis en miroir depuis les sous-réseaux situés dans deux réseaux différents. Toutes les ressources (la source et la destination) doivent se trouver dans la même région. La configuration dans le réseau network-a est semblable à l'exemple où la source mise en miroir et la destination de collecteur appartiennent au même réseau VPC. La règle policy-1 est configurée pour collecter le trafic du sous-réseau subnet-a et l'envoyer à collector-ilb.

La règle policy-2 est configurée dans le projet project-a, mais spécifie le sous-réseau subnet-b comme source mise en miroir. Étant donné que les réseaux network-a et network-b sont appairés, le collecteur de destination peut recueillir le trafic provenant du sous-réseau subnet-b.

Les réseaux appartiennent à des projets différents et peuvent avoir des propriétaires différents. Chacun de ces propriétaires potentiels peut créer les règles de mise en miroir de paquets, à condition qu'il dispose des autorisations appropriées :

  • Si les propriétaires de project-a créent la règle de mise en miroir de paquets, ils doivent disposer du rôle compute.packetMirroringAdmin sur le réseau, le sous-réseau ou les instances à mettre en miroir dans project-b.

  • Si les propriétaires de project-b créent la règle de mise en miroir de paquets, ils doivent disposer du rôle compute.packetMirroringUser dans project-a.

Pour plus d'informations sur l'activation de la connectivité privée entre deux réseaux VPC, consultez la page Appairage de réseaux VPC.

VPC partagé

Dans les scénarios de VPC partagé suivants, les instances mises en miroir pour la destination de collecteur font toutes partie du même réseau VPC partagé. Même si les ressources appartiennent toutes au même réseau, elles peuvent se trouver dans des projets différents, par exemple le projet hôte ou différents projets de service. Les exemples suivants montrent où créer les règles de mise en miroir de paquets et qui est habilité à le faire.

Si les sources mises en miroir et la destination de collecteur font partie du même projet, qu'il s'agisse d'un projet hôte ou d'un projet de service, la configuration est semblable à celle créée si toutes les ressources appartiennent au même réseau VPC. Le propriétaire du projet peut créer toutes les ressources et définir les autorisations requises dans ce projet.

Pour en savoir plus, consultez la section Présentation du VPC partagé.

Destination de collecteur dans un projet de service

Dans l'exemple suivant, la destination de collecteur est hébergée dans un projet de service qui utilise un sous-réseau dans le projet hôte. Dans ce cas, la règle se trouve également dans le projet de service. La règle peut aussi se trouver dans le projet hôte.

Dans le diagramme précédent, le projet de service contient les instances de collecteur qui utilisent le sous-réseau collecteur dans le réseau VPC partagé. La règle de mise en miroir de paquets a été créée dans le projet de service. Elle est configurée pour mettre en miroir les instances possédant une interface réseau dans subnet-mirrored.

Les utilisateurs du projet de service ou du projet hôte sont autorisés à créer la règle de mise en miroir de paquets. Pour ce faire, ils doivent disposer du rôle compute.packetMirroringUser dans le projet de service hébergeant la destination de collecteur. Les utilisateurs doivent également disposer du rôle compute.packetMirroringAdmin sur les sources mises en miroir.

Destination de collecteur dans le projet hôte

Dans l'exemple suivant, la destination de collecteur se trouve dans le projet hôte et les instances mises en miroir dans les projets de service.

Cet exemple peut s'appliquer aux scénarios dans lesquels les développeurs déploient des applications dans des projets de service et utilisent le réseau VPC partagé. Ils n'ont pas besoin de gérer l'infrastructure réseau ni la mise en miroir de paquets. Une équipe centralisée, en charge du réseau ou de la sécurité, contrôle le projet hôte et le réseau VPC partagé. Cette équipe est responsable du provisionnement des règles de mise en miroir de paquets.

Dans le diagramme précédent, la règle de mise en miroir de paquets est créée dans le projet hôte, où se trouve la destination de collecteur. La règle est configurée pour mettre en miroir les instances hébergées dans le sous-réseau mis en miroir. Les instances de VM situées dans les projets de service peuvent utiliser le sous-réseau mis en miroir, et leur trafic est alors mis en miroir.

Les utilisateurs du projet de service ou du projet hôte sont autorisés à créer la règle de mise en miroir de paquets. Pour ce faire, les utilisateurs du projet de service doivent disposer du rôle compute.packetMirroringUser dans le projet hôte. Les utilisateurs du projet hôte doivent disposer du rôle compute.packetMirroringAdmin pour les sources mises en miroir dans les projets de service.

Instances de VM à plusieurs interfaces

Une règle de mise en miroir de paquets peut inclure des instances de VM comportant plusieurs interfaces réseau. Une règle ne peut mettre en miroir que les ressources associées à un seul réseau à la fois. Par conséquent, vous ne pouvez pas créer de règle qui mette en miroir le trafic de toutes les interfaces réseau d'une instance. Si vous devez mettre en miroir plusieurs interfaces réseau d'une instance à plusieurs interfaces réseau, vous devez créer une règle de mise en miroir de paquets pour chaque interface, car chaque interface se connecte à un réseau VPC unique.

Étapes suivantes