Présentation de l'intégration hors bande

Pour analyser le trafic réseau de vos charges de travail à grande échelle, vous pouvez utiliser la mise en miroir de paquets, un service d'intégration de la sécurité réseau hors bande. La mise en miroir de paquets vous permet de surveiller le trafic réseau à l'aide de dispositifs virtuels tiers.

La mise en miroir de paquets clone le trafic réseau en fonction des critères de filtrage spécifiés dans les règles de mise en miroir de la stratégie de pare-feu. Ce trafic mis en miroir est ensuite envoyé à vos déploiements de dispositifs virtuels tiers pour une inspection approfondie des paquets.

La mise en miroir de paquets capture toutes les données de paquets, y compris les charges utiles et les en-têtes IP. Vous pouvez analyser le trafic réseau mis en miroir pour surveiller les performances de votre réseau et de vos applications, et détecter les menaces dans votre réseau.

La mise en miroir de paquets est un service zonal qui prend en charge les déploiements régionaux. Toutefois, le trafic entre zones vous est facturé si le consommateur et le producteur de votre déploiement de mise en miroir se trouvent dans des zones différentes. Pour améliorer la fiabilité de votre déploiement de mise en miroir, nous vous recommandons de créer un déploiement de producteur distinct dans la même zone que votre source de mise en miroir. Vous pouvez ainsi réduire les frais liés au trafic interzone et améliorer la fiabilité globale de votre configuration de mise en miroir.

Avantages de l'utilisation de l'intégration hors bande

L'intégration hors bande offre les avantages suivants :

Capacités de correspondance précise du trafic : grâce à ces capacités, vous pouvez spécifier des règles de mise en miroir dans votre stratégie de pare-feu. Cela vous permet d'utiliser la stratégie de pare-feu réseau mondiale lorsque vous définissez des règles de mise en miroir. Ces règles vous permettent de mettre en miroir un trafic spécifique en fonction de différents critères, y compris les adresses IP source ou de destination, les protocoles et les plages de ports de destination. Pour en savoir plus sur les règles de mise en miroir, consultez Règles de mise en miroir.
Filtres négatifs : vous pouvez utiliser l'action DO_NOT_MIRROR dans vos règles de mise en miroir pour définir des filtres négatifs. Cela vous permet d'ignorer le trafic spécifique dans les règles de mise en miroir.
Encapsulation Geneve : le trafic mis en miroir est encapsulé à l'aide de Geneve. Cela vous permet de conserver les paquets d'origine lorsqu'ils sont envoyés aux appliances tierces pour inspection. Pour en savoir plus, consultez Comprendre le format GENEVE.

En plus du paquet d'origine, l'encapsulation GENEVE inclut également des informations sur la source de mise en miroir. Il ajoute un identifiant de réseau cloud privé virtuel (VPC) unique à chaque paquet redirigé vers le groupe de points de terminaison de mise en miroir pour l'inspection approfondie des paquets. Si vous disposez de plusieurs réseaux VPC avec des plages d'adresses IP qui se chevauchent, cet identifiant réseau permet de garantir que chaque paquet redirigé est correctement associé à son réseau VPC.
Mise en miroir des collecteurs en tant que service : vous pouvez centraliser la gestion opérationnelle de vos appliances tierces tout en les proposant en tant que service à différentes équipes d'application de votre organisation. Ce déploiement centralisé d'appliance peut se faire dans un autre projet ou une autre organisation, selon la façon dont vos équipes sont organisées.

Modèle de déploiement de l'intégration hors bande

L'intégration hors bande est basée sur le modèle producteur-consommateur, dans lequel le consommateur utilise les services proposés par le producteur.

La figure 1 montre l'architecture de déploiement de haut niveau du service d'intégration hors bande.

Composants du producteur

Un réseau VPC producteur contient un ensemble d'instances de collecteur à équilibrage de charge qui peuvent recevoir des paquets encapsulés Geneve provenant d'un réseau consommateur. Les instances du groupe d'instances sont appelées instances de collecteur.

Lorsque vous spécifiez les instances 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 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é.

Groupes de déploiement de mise en miroir et déploiements de mise en miroir

Le déploiement de la mise en miroir est une ressource zonale qui pointe vers la règle de transfert d'un équilibreur de charge réseau passthrough interne qui sert de frontend pour les instances de collecteur. Ces déploiements de mise en miroir sont regroupés dans des groupes de déploiement de mise en miroir dans différents emplacements d'un projet pour faciliter leur utilisation et leur gestion.

Un groupe de points de terminaison de mise en miroir dans le réseau du consommateur envoie le trafic mis en miroir à son groupe de déploiement de mise en miroir correspondant. Le groupe de déploiement de mise en miroir envoie ensuite le trafic au déploiement de mise en miroir dans la même zone que la source de mise en miroir pour inspection.

Pour en savoir plus sur les groupes de déploiement et les déploiements, consultez Présentation de la mise en miroir des groupes de déploiement et Présentation de la mise en miroir des déploiements.

Composants destinés aux consommateurs

Les sources mises en miroir sont des instances de machine virtuelle (VM) Compute Engine que vous pouvez sélectionner à l'aide des paramètres de cible, de source et de destination dans les règles de mise 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.

Les sections suivantes couvrent les composants d'un réseau consommateur.

Groupes de points de terminaison de mise en miroir

Un groupe de points de terminaison de mise en miroir est une ressource au niveau du projet côté consommateur qui correspond directement au groupe de déploiement de mise en miroir d'un producteur. Vous pouvez associer les réseaux VPC individuels à un groupe de points de terminaison de mise en miroir pour activer la mise en miroir du trafic.

Nous vous recommandons de créer un groupe de points de terminaison de mise en miroir dans un projet appartenant à votre administrateur de la sécurité. Pour créer les associations de groupes de points de terminaison de mise en miroir, l'administrateur de sécurité doit attribuer le rôle Administrateur de point de terminaison de mise en miroir (roles/networksecurity.mirroringAdmin) et le rôle Administrateur réseau de point de terminaison de mise en miroir (roles/networksecurity.mirroringEndpointNetworkAdmin) à ce projet ou à l'administrateur réseau.

Pour en savoir plus sur la mise en miroir des groupes de points de terminaison, consultez la présentation des groupes de points de terminaison de mise en miroir.

Association de groupe de points de terminaison de mise en miroir

L'association de groupe de points de terminaison de mise en miroir spécifie le réseau VPC du consommateur dont le trafic doit être mis en miroir et transféré au groupe de déploiement du producteur pour inspection.

Les groupes de points de terminaison de mise en miroir envoient le trafic mis en miroir au groupe de déploiement correspondant dans le réseau du producteur. Toutefois, pour spécifier le réseau VPC consommateur dont le trafic mis en miroir doit être inspecté, vous devez créer une association entre le réseau VPC et le groupe de points de terminaison de mise en miroir.

Une fois que vous avez créé une association de groupe de points de terminaison de mise en miroir, les règles de mise en miroir de la stratégie de pare-feu déterminent les paquets à mettre en miroir à partir du réseau VPC associé. Si l'association du groupe de points de terminaison de mise en miroir n'est pas créée, les règles de mise en miroir sont ignorées et les paquets ne sont pas envoyés au groupe de déploiement pour inspection.

Pour en savoir plus sur l'association de groupes de points de terminaison, consultez Créer et gérer des associations de groupes de points de terminaison de mise en miroir.

Stratégies et règles de pare-feu

Dans un réseau VPC consommateur, vous utilisez des stratégies de pare-feu réseau pour sélectionner le trafic que vous souhaitez mettre en miroir et inspecter. Les règles suivantes sont incluses dans les stratégies de pare-feu :

Règles de stratégie de pare-feu : autorisent ou refusent l'entrée ou la sortie de paquets de données vers et depuis les VM du consommateur. Une règle de stratégie de pare-feu peut avoir l'une des actions suivantes :
- ALLOW : autorise le trafic et arrête l'évaluation des autres règles de stratégie de pare-feu de priorité inférieure.
- DENY : interdit le trafic et arrête l'évaluation des autres règles de stratégie de pare-feu de priorité inférieure.
- GOTO_NEXT : poursuit le processus d'évaluation des règles.

Pour en savoir plus sur les règles de stratégie de pare-feu, consultez Présentation des règles de stratégie de pare-feu.

Règles de mise en miroir : déterminent si les paquets de données entrants ou sortants sont mis en miroir. Une règle de mise en miroir peut avoir l'une des actions suivantes :
- MIRROR : autorise la mise en miroir du flux de trafic et arrête l'évaluation des autres règles de mise en miroir de priorité inférieure.
- DO_NOT_MIRROR : interdit la mise en miroir du flux de trafic et arrête l'évaluation des autres règles de mise en miroir de priorité inférieure. Vous utilisez l'action DO_NOT_MIRROR pour filtrer de manière précise les flux de trafic qui n'ont pas besoin d'être mis en miroir.
- GOTO_NEXT : action que vous pouvez utiliser pour déléguer l'évaluation de la connexion à des niveaux inférieurs. La règle de mise en miroir permet le traitement des règles suivantes si l'une des conditions suivantes est remplie :
  - Si cette action est goto_next, l'évaluation passe à la règle suivante. Par conséquent, plusieurs règles goto_next n'affectent pas le comportement des autres règles.
  - Si le trafic entrant ne correspond à aucune règle existante, le système applique par défaut une action goto_next. Cela signifie que le niveau de règle actuel n'a pas trouvé d'action pertinente. L'évaluation se poursuit donc au niveau inférieur suivant.
  Remarque : Les règles de niveau inférieur ne peuvent pas remplacer une règle de niveau supérieur dans la hiérarchie des ressources. Cela permet aux administrateurs de l'organisation de gérer les règles critiques de manière centralisée.

Ordre d'évaluation des stratégies et des règles pour les règles de mise en miroir

Vous pouvez ajouter des règles de mise en miroir à une stratégie de pare-feu réseau au niveau mondial. Comme les règles de stratégie de pare-feu, les règles de mise en miroir sont évaluées par ordre de priorité décroissant, zéro (0) étant la priorité la plus élevée. Chaque règle de mise en miroir d'une stratégie de pare-feu doit avoir une priorité unique. Si un flux de trafic correspond à une règle de mise en miroir, l'intégration hors bande met en miroir le paquet et ignore l'évaluation des règles de mise en miroir de priorité inférieure.

Lorsque des règles de mise en miroir sont configurées dans une stratégie de pare-feu, l'ordre dans lequel les règles sont évaluées dépend de la direction du trafic entrant ou sortant d'une VM.

Dans le cas de l'entrée, le trafic est d'abord évalué en fonction de l'ordre d'évaluation des règles de la stratégie de pare-feu.
- Si les règles de pare-feu autorisent le trafic entrant, celui-ci est évalué par rapport aux règles de mise en miroir. En fonction de l'action des règles de mise en miroir, le trafic est ensuite mis en miroir ou non.
- Si les règles de pare-feu interdisent le trafic entrant, celui-ci n'est pas évalué par rapport aux règles de mise en miroir. Les paquets de trafic bloqués par les règles de pare-feu sont supprimés et ne sont pas mis en miroir.
Dans le cas de la sortie, le trafic est d'abord évalué par rapport aux règles de mise en miroir. En fonction de l'action spécifiée pour les règles de mise en miroir, le trafic est mis en miroir ou non, puis il est évalué selon l'ordre d'évaluation des règles de stratégie de pare-feu de sortie.

Profils de sécurité et groupes de profils de sécurité

Les règles de mise en miroir font référence aux profils de sécurité des groupes de profils de sécurité pour mettre en œuvre l'inspection approfondie des paquets du trafic mis en miroir. Le trafic qui correspond à une règle de mise en miroir est mis en miroir dans le groupe de points de terminaison de mise en miroir référencé par le profil de sécurité de la règle de mise en miroir. Vous devez créer un groupe de profils de sécurité contenant un profil de sécurité personnalisé qui pointe vers votre groupe de points de terminaison de mise en miroir pour l'inspection par des tiers. Lorsque vous créez votre règle de mise en miroir, vous associez le groupe de profils de sécurité à la règle à l'aide de l'option --security-profile-group. Les profils de sécurité et les groupes de profils de sécurité sont des ressources au niveau de l'organisation.

Pour en savoir plus sur les profils de sécurité et les groupes de profils de sécurité, consultez Présentation des profils de sécurité et Présentation des groupes de profils de sécurité.

Fonctionnement de l'intégration hors bande

L'intégration hors bande utilise la technologie de Mise en miroir de paquets pour copier les données de trafic du réseau VPC du consommateur et les envoyer au réseau VPC du producteur via un groupe de points de terminaison de mise en miroir. La mise en miroir de paquets traite le trafic dans l'ordre suivant :

Une stratégie de pare-feu réseau est appliquée au trafic vers et depuis la VM dans le réseau.
Le trafic correspondant à la règle de mise en miroir de la règle est mis en miroir, et les paquets mis en miroir sont encapsulés à l'aide de Geneve, ce qui préserve les paquets d'origine.
En fonction du profil de sécurité du groupe de profils de sécurité spécifié dans la stratégie de pare-feu réseau, le trafic mis en miroir est envoyé à un groupe de points de terminaison de mise en miroir.
Le groupe de points de terminaison de mise en miroir transporte les paquets de manière sécurisée vers le déploiement de mise en miroir correspondant au sein du groupe de déploiement de mise en miroir cible pour une inspection approfondie des paquets.
L'équilibreur de charge passthrough interne du groupe de déploiement de mise en miroir du producteur distribue les flux de paquets entre les appliances virtuelles tierces configurées comme backends de l'équilibreur de charge.
Les appliances virtuelles tierces de backend traitent les paquets pour effectuer une inspection approfondie des paquets.

Spécifications

Les sections suivantes décrivent les spécifications de l'intégration hors bande.

Spécifications générales

Tous les protocoles de couche 4 sont compatibles avec la mise en miroir de paquets.
Vous pouvez créer une autorisation IAM côté producteur pour contrôler quel consommateur peut se connecter au groupe de déploiement de son producteur.
Nous vous recommandons d'avoir des projets producteurs et consommateurs dans la même organisation. Toutefois, vous pouvez également les placer dans différentes organisations.
Ne configurez pas votre producteur et votre consommateur dans le même réseau VPC, car cela entraînerait une boucle de mise en miroir.
Vous devez configurer des règles de stratégie de pare-feu sur le réseau VPC du producteur pour autoriser les paquets encapsulés Geneve (UDP:6081) provenant du groupe de déploiement de mise en miroir. De plus, vous devez configurer les règles du règlement de pare-feu pour autoriser également les requêtes de vérification de l'état provenant de l'équilibreur de charge réseau passthrough interne. Pour en savoir plus, consultez Utiliser des stratégies et des règles de pare-feu de réseau globales.
L'intégration hors bande est compatible avec la mise en miroir multizone. Vous pouvez configurer la mise en miroir multizone ou monozone en choisissant la zone du backend de l'équilibreur de charge interne côté producteur.
Les règles de mise en miroir, semblables aux règles de pare-feu, sont basées sur les sessions. Une règle de mise en miroir spécifie la session à mettre en miroir en fonction de l'initiateur de la session. Pour une session mise en miroir, tous les paquets du trafic entrant et sortant sont mis en miroir.
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 en spécifiant l'indicateur --is_mirroring_collector. Le trafic non mis en miroir envoyé à l'équilibreur de charge est supprimé. Pour savoir comment configurer des équilibreurs de charge réseau passthrough internes pour la mise en miroir de paquets, consultez Créer un équilibreur de charge pour la mise en miroir de paquets.

Mise en miroir du trafic

La mise en miroir de paquets ne collecte les données de trafic que depuis l'interface réseau d'une VM associée à un réseau VPC auquel s'applique la stratégie de pare-feu réseau contenant les règles de mise en miroir. Dans le cas d'une instance possédant plusieurs interfaces réseau, vous devez configurer des stratégies de pare-feu réseau distinctes pour chaque interface réseau.
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é.
Pour mettre en miroir le trafic entre les pods sur le même nœud Google Kubernetes Engine, vous devez activer la visibilité intranœud pour le cluster.

Filtrage

Vous pouvez utiliser des règles de mise en miroir pour filtrer le trafic des instances mises en miroir pour le trafic IPv4 et IPv6.
Les règles de mise en miroir peuvent réduire le volume de trafic mis en miroir, ce qui peut vous aider à limiter la consommation de bande passante en ne mettant en miroir que le trafic requis.
Vous pouvez configurer des règles de mise en miroir 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.

Journalisation des règles de pare-feu

La journalisation des règles de pare-feu ne consigne pas les paquets en miroir. Si une VM producteur se trouve sur un sous-réseau sur lequel la journalisation des règles de pare-feu est activée, le trafic envoyé directement à la VM producteur est journalisé, y compris le trafic provenant des VM en miroir. Autrement dit, si l'adresse IPv4 ou IPv6 de destination d'origine correspond à l'adresse IPv4 ou IPv6 de la VM productrice, le flux est journalisé. Pour en savoir plus sur la journalisation des règles de pare-feu, consultez Utiliser la journalisation des règles de pare-feu.

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.

Audits de sécurité

Vous pouvez collecter et conserver les preuves liées au réseau pour les audits, si nécessaire.

Comparaison entre la mise en miroir de paquets VPC et la mise en miroir de paquets d'intégration de la sécurité réseau

Le tableau suivant récapitule les différences entre la Mise en miroir de paquets VPC et la duplication de paquets d'intégration de la sécurité du réseau.

Attribut	Mise en miroir de paquets VPC	Mise en miroir de paquets pour l'intégration de la sécurité réseau
Encapsulation	Les paquets sont mis en miroir sans encapsulation.	Les paquets sont encapsulés avec Geneve.
Sémantique des règles de mise en miroir	Les règles de mise en miroir sont évaluées pour chaque paquet. Une règle de mise en miroir de paquets VPC peut spécifier de ne mettre en miroir qu'un seul côté d'une session.	La duplication d'écran est basée sur les sessions. De plus, dans les règles de mise en miroir, vous pouvez spécifier l'une des deux options suivantes : `mirror` ou `do-not-mirror`. Ces options vous permettent de choisir le trafic que vous souhaitez ou non mettre en miroir.
Filtres des règles de mise en miroir	Les règles de mise en miroir permettent de filtrer les adresses IP et les protocoles source (`src`) et de destination (`dst`).	Identique à la mise en miroir de paquets VPC, avec des plages de ports de destination en plus.
Prise en charge des appareils tiers
Compatible avec les stratégies de pare-feu hiérarchiques
Compatible avec les stratégies de pare-feu réseau régionales
Compatible avec les stratégies de pare-feu de réseau au niveau mondial

Interopérabilité de la mise en miroir de paquets entre VPC et Network Security Integration

Au niveau de la charge de travail, la mise en miroir de paquets de l'intégration de la sécurité réseau est prioritaire par rapport à la mise en miroir de paquets VPC. Si une charge de travail dispose d'une configuration de mise en miroir de paquets d'intégration de la sécurité réseau, le plan de données ignore toute configuration de mise en miroir de paquets VPC existante. Cela s'applique même lorsque la configuration de la mise en miroir de paquets de l'intégration de la sécurité réseau est appliquée de manière implicite à la charge de travail.

Par exemple, la règle de mise en miroir de paquets VPC préexistante est configurée pour mettre en miroir le trafic HTTP et ICMP. Lorsque le client crée une configuration de mise en miroir de paquets d'intégration de la sécurité réseau avec une règle de mise en miroir pour mettre en miroir HTTP, cette règle est activée dans une stratégie de pare-feu réseau mondiale et associée au projet. Par conséquent, la configuration de la mise en miroir de paquets de l'intégration de la sécurité réseau est prioritaire sur la règle de mise en miroir de paquets du VPC. Les modifications suivantes se produisent lors du traitement des paquets :

Le trafic HTTP est mis en miroir en fonction de la configuration de la mise en miroir de paquets de l'intégration de la sécurité réseau. Cela signifie que tout le trafic HTTP est envoyé à la destination spécifiée pour une inspection approfondie des paquets.
Le plan de données ignore toutes les configurations de mise en miroir de paquets VPC pour toutes les charges de travail. Cela signifie que la mise en miroir du trafic ICMP configurée dans la règle de mise en miroir de paquets du VPC est arrêtée et que le trafic ICMP n'est plus mis en miroir.

Ce changement de comportement peut avoir des conséquences importantes sur votre réseau. Par exemple, si vous vous appuyez sur la mise en miroir du trafic ICMP pour résoudre les problèmes réseau, vous ne pourrez plus le faire une fois la configuration de la mise en miroir de paquets de l'intégration de la sécurité réseau appliquée.

Limites

Le seul type d'équilibreur de charge interne compatible avec le déploiement du producteur est un équilibreur de charge réseau passthrough interne avec un backend de groupe d'instances. Cela signifie que la configuration du backend groupe de points de terminaison du réseau (NEG) n'est pas compatible avec le déploiement du producteur.
Lorsque des paquets réseau correspondent à une règle de mise en miroir, Compute Engine traite les paquets d'origine et les paquets mis en miroir à un rythme plus lent. Le taux de traitement des paquets dépend du type de machine, de la taille des paquets et de l'utilisation du processeur. Il est approximativement similaire aux taux de sortie en dehors d'un réseau VPC. Si vous avez besoin de toute la bande passante et de toute la vitesse de traitement du réseau pour le trafic mis en miroir, contactez l'assistance pour discuter d'autres solutions.
Nous vous déconseillons d'activer la mise en miroir pour les familles de machines de 3e génération et ultérieures, car le débit de la route la plus lente annule les avantages de la mise en réseau à bande passante élevée.
Les stratégies de pare-feu réseau régionales ne sont pas compatibles avec la mise en miroir de paquets.
Chaque règle de transfert d'équilibreur de charge interne ne peut être associée qu'à un seul déploiement de mise en miroir. Le déploiement de la mise en miroir doit se trouver dans le même projet qu'un équilibreur de charge interne. La zone du déploiement de la mise en miroir doit se trouver dans la région d'un équilibreur de charge interne.
Les règles de mise en miroir ne sont pas compatibles avec les tags sécurisés sources.
Un VPC peut être associé à une seule association de groupe de points de terminaison de mise en miroir au maximum.
Le trafic correspondant à une règle de pare-feu avec l'action apply_security_profile_group n'est pas mis en miroir. Les règles de pare-feu avec cette action remplacent la configuration de mise en miroir.