Mise en miroir de paquets

Cette page présente la mise en miroir de paquets dans le réseau de cloud privé virtuel (VPC). Si vous souhaitez analyser le trafic réseau de vos charges de travail à grande échelle et le surveiller à l'aide de dispositifs virtuels tiers, utilisez la mise en miroir de paquets de l'intégration de la sécurité réseau. Pour en savoir plus, consultez Présentation de l'intégration hors bande.

La mise en miroir de paquets clone le trafic de certaines instances spécifiées de votre réseau VPC 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 passthrough interne. Google Cloudtransfère ensuite le trafic mis en miroir vers les instances du 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 can send traffic to any of the load balancers that have been configured with identical packet mirroring policies. 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 règle 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.