Règles de pare-feu VPC

Les règles de pare-feu de cloud privé virtuel (VPC) s'appliquent à un projet et à un réseau donnés. Si vous souhaitez appliquer des règles de pare-feu à plusieurs réseaux VPC dans une organisation, consultez la section Règles de pare-feu. Le reste de cette page ne couvre que les règles de pare-feu VPC.

Les règles de pare-feu VPC vous permettent d'autoriser ou de refuser les connexions depuis ou vers des instances de machines virtuelles (VM) dans votre réseau VPC. Les règles de pare-feu VPC activées sont toujours appliquées, protégeant vos instances quels que soient leur configuration et leur système d'exploitation, même si elles n'ont pas encore démarré.

Chaque réseau privé virtuel (VPC) fonctionne comme un pare-feu distribué. Alors que les règles de pare-feu sont définies au niveau du réseau, les connexions sont autorisées ou interdites pour chaque instance. Vous pouvez considérer que les règles de pare-feu VPC existent non seulement entre vos instances et les autres réseaux, mais également entre les instances individuelles d'un même réseau.

Pour obtenir plus d'informations sur les pare-feu, consultez la page Pare-feu (informatique).

Bonnes pratiques pour les règles de pare-feu

Tenez compte des bonnes pratiques suivantes lorsque vous concevez et évaluez vos règles de pare-feu :

  • Mettez en œuvre les principes du moindre privilège. Bloquez tout le trafic par défaut et n'autorisez que le trafic spécifique dont vous avez besoin. Cela suppose de cantonner la règle aux seuls protocoles et ports dont vous avez besoin.
  • Utilisez des règles de stratégie de pare-feu hiérarchique pour bloquer le trafic qui ne doit jamais être autorisé au niveau de l'organisation ou du dossier.
  • Pour les règles "allow", limitez-les à des VM spécifiques en spécifiant le compte de service des VM.
  • Si vous devez créer des règles basées sur des adresses IP, essayez de limiter leur nombre au strict minimum. Le suivi s'avère en effet plus facile lorsqu'il porte sur une règle qui autorise le trafic vers une plage de 16 VM, plutôt que sur 16 règles distinctes.
  • Activez la journalisation des règles de pare-feu et utilisez Firewall Insights pour vérifier que les règles de pare-feu sont utilisées de la manière prévue. La journalisation des règles de pare-feu peut entraîner des coûts, que vous pouvez limiter en envisageant une utilisation sélective de cette fonctionnalité.

Règles de pare-feu dans Google Cloud

Lorsque vous créez une règle de pare-feu VPC, vous spécifiez un réseau VPC et un ensemble de composants définissant son rôle. Les composants vous permettent de cibler certains types de trafic en fonction du protocole, des ports de destination, des sources et des destinations. Pour en savoir plus, consultez la section Composants des règles de pare-feu.

Vous pouvez créer ou modifier des règles de pare-feu VPC à l'aide de la console Google Cloud, de Google Cloud CLI et de l'API REST. Lorsque vous créez ou modifiez une règle de pare-feu, vous pouvez spécifier les instances auxquelles elle doit être appliquée à l'aide du paramètre cible de la règle. Pour obtenir des exemples de règles de pare-feu, consultez la section Autres exemples de configuration.

Outre les règles de pare-feu que vous créez, Google Cloud dispose d'autres règles pouvant affecter les connexions entrantes (entrée) et sortantes (sortie) :

  • Google Cloud bloque ou limite certains types de trafic. Pour en savoir plus, consultez la section Trafic bloqué et limité.

  • Google Cloud autorise toujours la communication entre une instance de VM et le serveur de métadonnées correspondant à l'adresse 169.254.169.254. Pour en savoir plus, consultez la section Trafic toujours autorisé.

  • Chaque réseau comporte deux règles de pare-feu implicites qui autorisent les connexions sortantes et bloquent les connexions entrantes. Les règles de pare-feu que vous créez peuvent remplacer ces règles implicites.

  • Le réseau par défaut est prérempli avec des règles de pare-feu que vous pouvez supprimer ou modifier.

Spécifications

Les règles de pare-feu VPC présentent les caractéristiques suivantes :

  • Chaque règle de pare-feu s'applique soit aux connexions entrantes (entrée), soit aux connexions sortantes (sortie), mais pas aux deux. Pour en savoir plus, consultez la section Sens du trafic.

  • Les règles de pare-feu sont compatibles avec les connexions IPv4. Les connexions IPv6 sont également acceptées dans les réseaux VPC pour lesquels IPv6 est activé. Lorsque vous spécifiez une source ou une destination pour une règle d'entrée ou de sortie par adresse, vous pouvez spécifier des adresses IPv4 ou IPv6 ou des blocs au format CIDR.

  • Chaque règle de pare-feu peut contenir des plages IPv4 ou IPv6, mais pas les deux.

  • L'action de chaque règle de pare-feu est soit allow, soit deny. La règle s'applique aux connexions tant qu'elle est activée. Par exemple, vous pouvez désactiver une règle à des fins de dépannage.

  • Lorsque vous créez une règle de pare-feu, vous devez sélectionner un réseau VPC. Alors que la règle est appliquée au niveau de l'instance, sa configuration est associée à un réseau VPC. Cela signifie que vous ne pouvez pas partager les règles de pare-feu entre les réseaux VPC, y compris les réseaux connectés via l'appairage de réseaux VPC ou à l'aide de tunnels Cloud VPN.

  • Les règles de pare-feu VPC sont dites avec état.

    • Lorsqu'une connexion est autorisée via le pare-feu dans un sens, le trafic retour correspondant à cette connexion est également autorisé. Vous ne pouvez pas configurer une règle de pare-feu pour refuser le trafic de réponse associé.
    • Le trafic retour doit correspondre aux cinq tuples (adresse IP source, adresse IP de destination, port source, port de destination et protocole) du trafic de requête accepté, mais avec les adresses et les ports sources et de destination inversés.
    • Google Cloud associe les paquets entrants aux paquets sortants correspondants à l'aide d'une table de suivi des connexions.
    • Google Cloud met en œuvre le suivi des connexions, que le protocole soit compatible ou non avec les connexions. Si une connexion est autorisée entre une source et une cible (pour une règle d'entrée), ou une cible et une destination (pour une règle de sortie), l'intégralité du trafic de réponse est autorisée aussi longtemps que l'état de suivi des connexions du pare-feu reste actif. L'état de suivi d'une règle de pare-feu est considéré comme actif si au moins un paquet est envoyé toutes les 10 minutes.
    • Lorsqu'une connexion fragmentée est autorisée via le pare-feu, Google Cloud utilise le suivi des connexions pour n'autoriser que le premier fragment du trafic retour. Pour autoriser les fragments de retour suivants, vous devez ajouter une règle de pare-feu.
    • Le trafic de réponse ICMP (tel que "ICMP TYPE 3, DESTINATION UNREACHABLE") généré en réponse à une connexion TCP/UDP autorisée est autorisé via le pare-feu. Ce comportement est conforme à la norme RFC 792.

  • Les règles de pare-feu VPC ne rassemblent pas les paquets TCP fragmentés. Par conséquent, une règle de pare-feu applicable au protocole TCP ne peut s'appliquer qu'au premier fragment, car celui-ci contient l'en-tête TCP. Les règles de pare-feu applicables au protocole TCP ne s'appliquent pas aux fragments TCP ultérieurs.

  • Le nombre maximal de connexions suivies dans la table des règles de pare-feu dépend du nombre de connexions avec état compatibles avec le type de machine de l'instance. Si le nombre maximal de connexions suivies est dépassé, le suivi est arrêté pour les connexions dont l'intervalle d'inactivité est le plus long pour permettre le suivi des nouvelles connexions.

    Type de machine de l'instance Nombre maximal de connexions avec état
    Types de machines à cœur partagé 130 000
    Instances avec 1 à 8 processeurs virtuels 130 000 connexions par processeur virtuel
    Instances avec plus de 8 processeurs virtuels 1 040 000 (130 000 × 8) connexions au total

Règles implicites

Chaque réseau VPC possède deux règles de pare-feu IPv4 implicites. Si IPv6 est activé dans un réseau VPC, ce réseau a également deux règles de pare-feu IPv6 implicites. Ces règles ne sont pas affichées dans la console Google Cloud.

Les règles de pare-feu implicites sont présentes dans tous les réseaux VPC, que leur mode soit automatique ou personnalisé et quelle que soit la façon dont ils sont créés. Le réseaupar défaut possède les mêmes règles implicites.

  • Règle implicite de sortie IPv4 autorisée. Une règle de sortie dont l'action est allow et la destination, 0.0.0.0/0, et dont la priorité est la plus faible possible (65535), permet à une instance d'envoyer du trafic vers n'importe quelle destination, à l'exception du trafic bloqué par Google Cloud. L'accès sortant peut être limité par une règle de pare-feu de priorité supérieure. L'accès à Internet est autorisé si aucune autre règle de pare-feu ne refuse le trafic sortant, et si l'instance possède une adresse IP externe ou utilise une instance Cloud NAT. Pour en savoir plus, consultez la section Conditions d'accès à Internet.

  • Règle implicite d'entrée interdite IPv4. Une règle d'entrée dont l'action est deny, dont la source est 0.0.0.0/0 et dont la priorité est la plus faible possible (65535), protège toutes les instances en bloquant leurs connexions entrantes. L'accès entrant peut être autorisé par une règle de priorité plus élevée. Le réseau par défaut dispose de règles supplémentaires qui remplacent celle-ci, autorisant certains types de connexions entrantes.

Si IPv6 est activé, le réseau VPC possède également ces deux règles implicites :

  • Règle implicite de sortie IPv6 autorisée. Une règle de sortie dont l'action est allow et la destination, ::/0, et dont la priorité est la plus faible possible (65535), permet à une instance d'envoyer du trafic vers n'importe quelle destination, à l'exception du trafic bloqué par Google Cloud. L'accès sortant peut être limité par une règle de pare-feu de priorité supérieure. L'accès à Internet est autorisé si aucune autre règle de pare-feu ne refuse le trafic sortant et si l'instance possède une adresse IP externe.

  • Règle implicite d'entrée interdite IPv6. Une règle d'entrée dont l'action est deny, dont la source est ::/0 et dont la priorité est la plus faible possible (65535), protège toutes les instances en bloquant leurs connexions entrantes. L'accès entrant peut être autorisé par une règle de priorité plus élevée.

Les règles implicites ne peuvent pas être supprimées, mais elles ont les priorités les plus faibles. Vous pouvez créer des règles qui les remplacent à condition qu'elles aient des priorités plus élevées (numéros de priorité inférieurs à 65535). Les règles deny sont prioritaires sur les règles allow ayant la même priorité. Une règle d'entrée allow ayant une priorité de 65535 ne prend donc jamais effet.

Règles préremplies dans le réseau par défaut

Le réseau par défaut est prérempli avec des règles de pare-feu autorisant les connexions entrantes vers les instances. Ces règles peuvent être supprimées ou modifiées si nécessaire :

Nom de la règle Direction Priorité Plages sources Action Protocoles et ports Description
default-allow-internal ingress 65534 10.128.0.0/9 allow tcp:0-65535
udp:0-65535
icmp 		Autorise les connexions entrantes aux instances de VM depuis d'autres instances du même réseau VPC.
default-allow-ssh ingress 65534 0.0.0.0/0 allow tcp:22 Vous permet de vous connecter à des instances avec des outils tels que ssh, scp ou sftp.
default-allow-rdp ingress 65534 0.0.0.0/0 allow tcp:3389 Vous permet de vous connecter à des instances à l'aide du protocole RDP (Remote Desktop Protocol) de Microsoft.
default-allow-icmp ingress 65534 0.0.0.0/0 allow icmp Vous permet d'utiliser des outils tels que ping.

Vous pouvez créer des règles de pare-feu similaires pour les réseaux autres que le réseau par défaut. Pour en savoir plus, consultez la section Configurer les règles de pare-feu pour les cas d'utilisation courants.

Trafic bloqué et limité

En dehors des règles de pare-feu VPC et des stratégies de pare-feu hiérarchiques, Google Cloud bloque ou limite certains types de trafic comme décrit dans le tableau suivant.

Type de trafic Détails
Débit de paquets et bande passante

S'applique à :

  • Tous les paquets de sortie
  • Tous les paquets d'entrée
 Google Cloud tient compte de la bande passante par instance de VM, pour chaque interface réseau ou adresse IP. Le type de machine d'une VM définit son débit de sortie maximal possible. Cependant, vous ne pouvez atteindre ce débit de sortie maximal que dans des situations spécifiques.

Pour en savoir plus, consultez la section Bande passante réseau de la documentation Compute Engine.
Offres et confirmations de DHCP

S'applique à :

  • Paquets d'entrée vers le port UDP 68 (DHCPv4)
  • Paquets d'entrée vers le port UDP 546 (DHCPv6)
 Google Cloud bloque les offres et les accusés de réception DHCP entrants de toutes les sources, à l'exception des paquets DHCP provenant du serveur de métadonnées.
Protocoles compatibles avec les adresses IP externes de Google Cloud

S'applique à :

  • Paquets d'entrée vers des adresses IP externes

Les adresses IPv4 et IPv6 externes n'acceptent que les paquets TCP, UDP, ICMP, IPIP, AH, ESP, SCTP et GRE. Les ressources qui utilisent des adresses IP externes imposent des restrictions de protocole supplémentaires :
Trafic SMTP (port 25)

S'applique à :

  • Sortie de paquets vers des adresses IP externes sur le port TCP 25

Par défaut, Google Cloud bloque les paquets de sortie envoyés au port de destination TCP 25 d'une adresse IP externe (y compris une adresse IP externe d'une autre ressource Google Cloud). Toutefois, ce trafic n'est pas bloqué dans les projets appartenant à certains clients Google Cloud. Dans la console Google Cloud, les pages Réseaux VPC et Pare-feu affichent toutes deux un message indiquant si Le port SMTP 25 est autorisé ou non dans votre projet.

Ce bloc ne s'applique pas aux paquets de sortie envoyés au port de destination TCP 25 d'une adresse IP interne, y compris une adresse IP publique utilisée en mode privé dans un réseau VPC ou un réseau sur site.

Si la sortie SMTP externe sur le port 25 est autorisée dans votre projet et que vous souhaitez envoyer ce type de trafic, les conditions supplémentaires suivantes doivent être remplies :

  • Les règles de pare-feu de sortie du réseau VPC et les règles de pare-feu hiérarchiques applicables au réseau VPC doivent autoriser la sortie vers l'adresse IP externe sur le port TCP 25. Les règles implicites de sortie autorisée répondent à cette exigence, car elles autorisent la sortie vers (et les réponses entrantes établies à partir de) n'importe quelle adresse IP.
  • La route applicable à la destination doit utiliser le saut suivant de la passerelle Internet par défaut. Les routes par défaut générées par le système répondent à cette exigence.
  • L'instance envoyant des paquets à l'adresse IP externe doit répondre aux conditions d'accès à Internet.

Vous pouvez empêcher la sortie SMTP externe en créant des règles de pare-feu de refus du VPC ou des règles de pare-feu hiérarchiques.

Trafic toujours autorisé

Pour les instances de VM, les règles de pare-feu VPC et les règles de pare-feu hiérarchiques ne s'appliquent pas aux éléments suivants :

  • Paquets envoyés et reçus depuis le serveur de métadonnées Google Cloud

  • Paquets envoyés à une adresse IP attribuée à l'une des interfaces réseau (cartes réseau) de l'instance, où les paquets restent dans la VM elle-même. Les adresses IP attribuées à la carte d'interface réseau d'une instance incluent :

    • L'adresse IPv4 interne principale de la carte d'interface réseau
    • Toute adresse IPv4 interne d'une plage d'adresses IP d'alias de la carte d'interface réseau
    • Si IPv6 est configuré sur le sous-réseau, l'une des adresses IPv6 attribuées à la carte d'interface réseau
    • L'adresse IPv4 interne ou externe associée à une règle de transfert, pour l'équilibrage de charge ou le transfert de protocole, si l'instance est un backend pour l'équilibreur de charge ou une instance cible pour le transfert de protocole
    • Adresses de rebouclage
    • Adresses configurées dans le cadre d'un logiciel de superposition de réseaux que vous exécutez dans l'instance elle-même

Serveur de métadonnées Google Cloud

Google Cloud exécute un serveur de métadonnées local avec chaque instance à l'adresse 169.254.169.254. Ce serveur est essentiel au fonctionnement de l'instance. Il faut donc qu'elle puisse y accéder quelles que soient les règles de pare-feu que vous configurez. Le serveur de métadonnées fournit à l'instance les services de base suivants :

Interaction avec les produits

Les sections suivantes décrivent la manière dont les règles de pare-feu et les stratégies de pare-feu hiérarchiques interagissent avec d'autres produits Google Cloud.

Règles de pare-feu et équilibreurs de charge à stratégie directe

Les règles de pare-feu VPC et les stratégies de pare-feu hiérarchiques contrôlent quels protocoles et ports gérés par la règle de transfert sont autorisés pour les backends d'équilibrage de charge réseau et de l'équilibreur de charge TCP/UDP interne. Pour plus d'informations, consultez :

Règles de pare-feu et équilibreurs de charge proxy

Pour les équilibreurs de charge HTTP(S) externes, les équilibreurs de charge HTTP(S) internes, les équilibreurs de charge proxy SSL externes et les équilibreurs de charge proxy TCP externes, les règles de pare-feu VPC et les stratégies de pare-feu hiérarchiques ne contrôlent pas quels protocoles et ports sont acceptés par l'adresse IP de la règle de transfert de l'équilibreur de charge proxy. La règle de transfert à elle seule détermine les protocoles et les ports acceptés par l'équilibreur de charge proxy.

Les règles de pare-feu VPC et les stratégies de pare-feu hiérarchiques contrôlent la manière dont ces équilibreurs de charge proxy communiquent avec leurs backends. Pour plus d'informations, consultez :

Règles de pare-feu et Cloud VPN

Les règles de pare-feu et les règles de pare-feu hiérarchiques ne contrôlent pas les protocoles et les ports acceptés par la passerelle Cloud VPN.

Les passerelles Cloud VPN n'acceptent que les paquets pour les protocoles et les ports décrits dans les spécifications Cloud VPN.

Règles de pare-feu et GKE

Google Kubernetes Engine crée et gère automatiquement les règles de pare-feu lorsque vous créez un cluster ou des ressources dans le cluster (y compris les services et les entrées). Pour plus d'informations, consultez la section Règles de pare-feu créées automatiquement dans la documentation de Google Kubernetes Engine.

Composants des règles de pare-feu

Chaque règle de pare-feu comprend les composants de configuration suivants :

  • Un sens du point de vue de la cible. Le sens peut être entrant ou sortant.

  • Une priorité numérique permettant de déterminer si la règle est appliquée. Seule la règle ayant la priorité la plus élevée (numéro de priorité le plus petit) et dont les autres composants correspondent au trafic est appliquée ; les règles en conflit dont les priorités sont inférieures sont ignorées.

  • Une action en cas de correspondance, allow ou deny, qui détermine si la règle autorise ou bloque les connexions.

  • Le statut d'application de la règle de pare-feu : il est possible d'activer et de désactiver les règles de pare-feu sans les supprimer.

  • Une cible qui définit les instances (y compris les clusters GKE et les instances de l'environnement flexible App Engine) auxquelles la règle s'applique.

  • Un filtre source ou destination pour les caractéristiques de paquet.

  • Le protocole (tel que TCP, UDP ou ICMP) et le port de destination.

  • Une option booléenne logs qui consigne dans Cloud Logging les connexions correspondant à la règle.

Résumé des composants

Règle d'entrée (entrante)
Priorité Action Application Cible (reçoit des paquets) Filtre source Filtre de destination Protocols and ports (Protocoles et ports)
Entier de 0 à 65535 inclus ; 1000 par défaut
 allow ou deny enabled (par défaut) ou disabled Le paramètre de cible spécifie les instances qui reçoivent des paquets. Sources pour les règles d'entrée Destinations pour les règles d'entrée

Spécifiez un protocole, ou un protocole et un port de destination.

Si aucun protocole n'est défini, la règle s'applique à tous les protocoles et ports de destination. Pour en savoir plus, consultez la section Protocoles et ports.
Règle de sortie (sortante)
Priorité Action Application Cible (envoie des paquets) Filtre source Filtre de destination Protocols and ports (Protocoles et ports)
Entier de 0 à 65535 inclus ; 1000 par défaut
 allow ou deny enabled (par défaut) ou disabled Le paramètre de cible spécifie les instances qui envoient des paquets. Sources pour les règles de sortie Destinations pour les règles de sortie Spécifiez un protocole, ou un protocole et un port de destination.

Si aucun protocole n'est défini, la règle s'applique à tous les protocoles et ports de destination. Pour en savoir plus, consultez la section Protocoles et ports.

Sens du trafic

Vous pouvez créer des règles de pare-feu qui s'appliquent au trafic entrant ou sortant. Une même règle ne peut pas s'appliquer à la fois au trafic entrant et sortant. Cependant, vous pouvez créer plusieurs règles pour définir le trafic d'entrée et de sortie que vous autorisez ou refusez via le pare-feu.

  • L'entrée (entrant) décrit les paquets entrant dans l'interface réseau d'une cible.

  • La sortie (sortante) décrit les paquets quittant l'interface réseau d'une cible.

  • Si vous ne spécifiez aucun sens, Google Cloud utilise le sens entrant.

Priorité

La priorité de la règle de pare-feu est un entier compris entre 0 et 65535 inclus. Des entiers plus petits indiquent des priorités plus élevées. Si vous ne spécifiez pas de priorité lors de la création d'une règle, une priorité de 1000 lui est attribuée.

La priorité relative d'une règle de pare-feu détermine si elle est applicable lorsqu'elle est évaluée par rapport à d'autres. La logique d'évaluation fonctionne comme suit :

  • La règle applicable à une cible pour un type de trafic donné, et qui a la priorité la plus élevée, est prioritaire. La spécificité de la cible n'a pas d'importance. Par exemple, une règle d'entrée ayant une priorité plus élevée pour certains ports de destination et protocoles, et destinée à toutes les cibles est prioritaire sur une règle définie de la même manière pour les mêmes ports de destination et protocoles, mais destinée à des cibles spécifiques.

  • La règle de priorité la plus élevée applicable à une définition de protocole et de port donnée est prioritaire, même lorsque la définition du protocole et du port de destination est plus générale. Par exemple, une règle d'entrée de priorité plus élevée autorisant le trafic pour tous les protocoles et ports de destination sur des cibles données est prioritaire sur une règle d'entrée de priorité inférieure refusant le port TCP 22 pour les mêmes cibles.

  • Une règle ayant une action deny est prioritaire sur une règle ayant une action allow seulement si les deux règles ont la même priorité. En utilisant des priorités relatives, il est possible de créer des règles allow qui sont prioritaires sur des règles deny, et des règles deny qui sont prioritaires sur des règles allow.

  • Les règles ayant la même priorité et la même action ont le même résultat. Cependant, la règle utilisée lors de l'évaluation est indéterminée. Normalement, la règle utilisée n'a pas d'importance, sauf lorsque vous activez la journalisation des règles de pare-feu. Si vous souhaitez que vos journaux affichent les règles de pare-feu en cours d'évaluation dans un ordre cohérent et bien défini, attribuez-leur des priorités uniques.

Prenons l'exemple suivant où deux règles de pare-feu existent :

  • Une règle d'entrée depuis les sources 0.0.0.0/0 (toute adresse IPv4) applicable à toutes les cibles, tous les protocoles et tous les ports de destination, ayant une action deny et une priorité de 1000.

  • Une règle d'entrée depuis les sources 0.0.0.0/0 (toute adresse IPv4) applicable à des cibles spécifiques avec le tag réseau webserver, pour le trafic sur TCP 80, avec une action allow.

La priorité de la seconde règle détermine si le trafic TCP sur le port 80 est autorisé pour les cibles webserver :

  • Si la priorité de la seconde règle est définie sur un nombre supérieur à 1000, sa priorité est inférieure. La première règle refusant tout le trafic est donc appliquée.

  • Si la priorité de la seconde règle est définie sur 1000, les deux règles ont des priorités identiques. La première règle refusant tout le trafic est donc appliquée.

  • Si la priorité de la seconde règle est définie sur un nombre inférieur à 1000, sa priorité est supérieure, autorisant ainsi le trafic sur le port TCP 80 pour les cibles webserver. En l'absence d'autres règles, la première règle refuse toujours les autres types de trafic vers les cibles webserver et refuse également l'intégralité du trafic, y compris sur le port TCP 80, vers les instances ne disposant pas du tag réseau webserver.

L'exemple précédent montre comment vous pouvez utiliser des priorités pour créer des règles allow sélectives et des règles deny globales pour mettre en œuvre une bonne pratique de sécurité de moindre privilège.

Action en cas de correspondance

Le composant d'action d'une règle de pare-feu détermine si elle autorise ou bloque le trafic, en tenant compte des autres composants de la règle :

  • Une action allow autorise les connexions correspondant aux autres composants spécifiés.

  • Une action deny bloque les connexions correspondant aux autres composants spécifiés.

Application

Vous pouvez décider si une règle de pare-feu est appliquée ou non en définissant son état sur enabled ou disabled. Vous définissez l'état d'application lorsque vous créez une règle ou lorsque vous mettez à jour une règle.

Si vous ne définissez pas d'état d'application lorsque vous créez une règle de pare-feu, la règle de pare-feu est automatiquement enabled.

Cas d'utilisation

La désactivation et l'activation sont utiles pour le dépannage et l'exécution de la maintenance. Envisagez de modifier l'application d'une règle de pare-feu dans les situations suivantes :

  • Pour le dépannage : en combinaison avec la journalisation des règles de pare-feu, vous pouvez désactiver temporairement une règle de pare-feu pour déterminer si elle est responsable du blocage ou de l'autorisation du trafic. Cela est utile dans les cas où plusieurs règles de pare-feu s'appliquent au même trafic. Il est plus utile de désactiver et d'activer des règles que de les supprimer et de les recréer, car aucun des autres composants de la règle n'est perdu.

  • Pour la maintenance : désactiver des règles de pare-feu peut simplifier la maintenance périodique. Par exemple, vous pouvez choisir d'activer une règle de pare-feu d'entrée qui n'autorise l'accès SSH que lorsque vous devez effectuer une maintenance à l'aide de SSH. Lorsque vous n'effectuez pas de maintenance, vous pouvez désactiver la règle.

Effets sur le trafic existant

Lorsque vous modifiez l'état d'application d'une règle de pare-feu ou lorsque vous créez une règle enforced, la modification ne s'applique qu'aux nouvelles connexions. Les connexions existantes ne sont pas affectées par la modification.

Source, destination, cible

Vous pouvez spécifier des paramètres de source et de destination qui s'appliquent aux sources ou aux destinations de paquets pour les règles de pare-feu d'entrée et de sortie. Le sens de la règle de pare-feu détermine les valeurs possibles pour les paramètres source et de destination.

Les cibles identifient les interfaces réseau des instances auxquelles la règle de pare-feu s'applique.

Paramètre de cible

Le paramètre de cible identifie les interfaces réseau des instances Compute Engine, y compris les nœuds GKE et les instances de l'environnement flexible App Engine.

Vous pouvez définir les cibles suivantes pour les règles d'entrée ou de sortie. Les paramètres de cible, de source et de destination fonctionnent conjointement, comme décrit dans la section Source, destination et cible.

  • Cible par défaut : toutes les instances du réseau VPC Lorsque vous omettez une spécification cible, la règle de pare-feu s'applique à toutes les instances du réseau VPC.

  • Instances par tags réseau cibles. La règle de pare-feu ne s'applique qu'aux instances du réseau VPC ayant un tag réseau correspondant. Pour connaître le nombre maximal de tags réseau cibles que vous pouvez appliquer par règle de pare-feu, consultez la page Quotas de ressources des VPC.

  • Instances par comptes de service cibles : la règle de pare-feu ne s'applique qu'aux instances du réseau VPC qui utilisent un compte de service spécifique. Pour connaître le nombre maximal de comptes de service cibles que vous pouvez appliquer par règle de pare-feu, consultez la page Quotas de ressources des VPC.

Pour en savoir plus sur les avantages et les limites des tags réseau cibles et des comptes de service cibles, consultez la section Filtrer par compte de service ou par tag réseau.

Cibles et adresses IP pour les règles d'entrée

Les paquets acheminés vers l'interface réseau d'une VM cible sont traités en fonction des conditions suivantes :

  • Si la règle de pare-feu d'entrée inclut une plage d'adresses IP de destination, la destination du paquet doit correspondre à l'une des plages d'adresses IP de destination explicitement définies (fonctionnalité d'aperçu).

  • Si la règle de pare-feu d'entrée n'inclut pas de plage d'adresses IP de destination, la destination du paquet doit correspondre à l'une des adresses IP suivantes :

    • L'adresse IPv4 interne principale attribuée à la carte d'interface réseau de l'instance.

    • Toutes les plages d'adresses IP d'alias configurées sur la carte d'interface réseau de l'instance.

    • L'adresse IPv4 externe associée à la carte d'interface réseau de l'instance.

    • Si IPv6 est configuré sur le sous-réseau, l'une des adresses IPv6 attribuées à la carte d'interface réseau.

    • Une adresse IP externe ou interne associée à une règle de transfert utilisée pour l'équilibrage de charge à stratégie directe, où l'instance est un backend pour un équilibreur de charge TCP/UDP interne ou un équilibreur de charge réseau.

    • Une adresse IP externe ou interne associée à une règle de transfert utilisée pour le transfert de protocole, où l'instance est référencée par une instance cible.

    • Une adresse IP dans la plage de destination d'une route statique personnalisée utilisant l'instance comme VM de saut suivant (next-hop-instance ou next-hop-address).

    • Une adresse IP dans la plage de destination d'une route statique personnalisée utilisant un équilibreur de charge TCP/UDP interne (next-hop-ilb) comme saut suivant si la VM est un backend pour cet équilibreur de charge

Cibles et adresses IP pour les règles de sortie

Le traitement des paquets émis à partir de l'interface réseau d'une cible dépend de la configuration du transfert IP sur la VM cible. Le transfert IP est désactivé par défaut.

  • Lorsque le transfert IP est désactivé sur la VM cible, celle-ci peut émettre des paquets avec les sources suivantes :

    • L'adresse IPv4 interne principale de la carte d'interface réseau d'une instance.

    • Toutes les plages d'adresses IP d'alias configurées sur la carte d'interface réseau d'une instance.

    • Si IPv6 est configuré sur le sous-réseau, l'une des adresses IPv6 attribuées à la carte d'interface réseau.

    • Une adresse IP externe ou interne associée à une règle de transfert pour l'équilibrage de charge à stratégie directe ou le transfert de protocole, si l'instance est un backend pour un équilibreur de charge TCP/UDP interne, un équilibreur de charge réseau ou référencé par une instance cible.

    Si la règle de pare-feu de sortie inclut des plages d'adresses IP sources, les VM cibles sont toujours limitées aux adresses IP sources mentionnées précédemment, mais le paramètre source peut être utilisé pour affiner cet ensemble (fonctionnalité de prévisualisation). L'utilisation d'un paramètre source sans activer le transfert IP ne développe pas l'ensemble des adresses sources de paquets possibles.

    Si la règle de pare-feu de sortie n'inclut pas de plage d'adresses IP sources, toutes les adresses IP sources mentionnées précédemment sont autorisées.

  • Lorsque le transfert IP est activé sur la VM cible, celle-ci peut émettre des paquets avec des adresses sources arbitraires. Vous pouvez utiliser le paramètre de source pour définir plus précisément l'ensemble des sources de paquets autorisées.

Sources

Les valeurs des paramètres sources dépendent de la direction de la règle de pare-feu.

Sources des règles d'entrée

Vous pouvez utiliser les sources suivantes pour les règles de pare-feu d'entrée :

  • Plage source par défaut : lorsque vous omettez une spécification source dans une règle d'entrée, Google Cloud utilise la plage d'adresses IPv4 source par défaut 0.0.0.0/0 (toute adresse IPv4). La valeur par défaut n'inclut pas les sources IPv6.

  • Plages IPv4 sources : liste d'adresses IPv4 au format CIDR.

  • Plages IPv6 sources : liste des adresses IPv6 au format CIDR.

  • Tags réseau sources : un ou plusieurs tags réseau qui identifient les interfaces réseau des instances de VM du même réseau VPC que la règle de pare-feu. Pour connaître le nombre maximal de tags réseau sources par règle de pare-feu, consultez la page Quotas de ressources des VPC. Pour en savoir plus sur les adresses de source de paquet lors de l'utilisation de cette spécification implicite, consultez la section Comment les tags réseau sources et les comptes de service sources impliquent des sources de paquets.

  • Comptes de service sources : un ou plusieurs comptes de service qui identifient les interfaces réseau des instances de VM du même réseau VPC que la règle de pare-feu. Pour connaître le nombre maximal de comptes de service sources par règle de pare-feu, consultez la page Quotas de ressources des VPC. Pour en savoir plus sur les adresses de source de paquet lors de l'utilisation de cette spécification implicite, consultez la section Comment les tags réseau sources et les comptes de service sources impliquent des sources de paquets.

  • Une combinaison source valide : pour toutes les combinaisons suivantes, l'ensemble de sources utilisé correspond à la combinaison des adresses IPv4 ou IPv6 explicitement spécifiées, et les plages d'adresses IP implicites par tag réseau source ou compte de service source :

    • Une combinaison de plages IPv4 sources et de tags sécurisés sources.
    • Une combinaison de plages IPv6 sources et de tags sécurisés sources.
    • Une combinaison de plages IPv4 sources et de comptes de service sources.
    • Une combinaison de plages IPv6 sources et de comptes de service sources.

Comment les tags réseau sources et les comptes de service sources impliquent des sources de paquets

Lorsqu'une règle de pare-feu d'entrée utilise un tag réseau source, les paquets doivent être émis à partir d'une interface réseau qui répond aux critères suivants :

  • L'interface réseau utilise le même réseau VPC que la règle de pare-feu.
  • L'interface réseau est associée à une VM dont le tag réseau correspond au tag réseau source de la règle de pare-feu.

Lorsqu'une règle de pare-feu d'entrée utilise un compte de service source, les paquets doivent être émis à partir d'une interface réseau qui répond aux critères suivants :

  • L'interface réseau utilise le même réseau VPC que la règle de pare-feu.
  • L'interface réseau est associée à une VM dont le compte de service correspond au compte de service source de la règle de pare-feu.

En plus de spécifier une interface réseau, lorsqu'une règle de pare-feu d'entrée utilise un tag réseau source ou un compte de service source, les paquets émis à partir de l'interface réseau de la VM doivent utiliser l'une des adresses IP sources valides suivantes :

  • Adresse IPv4 interne principale de cette interface réseau.
  • N'importe quelle adresse IPv6 attribuée à cette interface réseau.

Aucune autre adresse IP source des paquets n'est implicite lorsque vous utilisez des tags réseau sources ou des comptes de service sources. Par exemple, les plages d'adresses IP d'alias et les adresses IPv4 externes associées à l'interface réseau sont exclues. Si vous devez créer des règles de pare-feu d'entrée dont les sources incluent des plages d'adresses IP d'alias ou des adresses IPv4 externes, utilisez des plages IPv4 sources.

Sources des règles de sortie

Vous pouvez utiliser les sources suivantes pour les règles de pare-feu de sortie :

Destinations

Les destinations peuvent être spécifiées à l'aide de plages d'adresses IP, qui sont compatibles avec les règles d'entrée et de sortie. Le comportement de destination par défaut dépend du sens de la règle.

Destinations pour les règles d'entrée

Vous pouvez utiliser les destinations suivantes pour les règles de pare-feu d'entrée :

Destinations pour les règles de sortie

Vous pouvez utiliser les destinations suivantes pour les règles de pare-feu de sortie :

  • Plage de destination par défaut : Lorsque vous omettez une spécification de destination dans une règle de sortie, Google Cloud utilise la plage d'adresses IPv4 de destination par défaut 0.0.0.0/0 (toute adresse IPv4). La valeur par défaut n'inclut pas les destinations IPv6.

  • Plages IPv4 de destination Liste d'adresses IPv4 au format CIDR.

  • Plages IPv6 de destination Liste d'adresses IPv6 au format CIDR.

Protocoles et ports

Vous pouvez réduire le champ d'application d'une règle de pare-feu en spécifiant des protocoles, ou des protocoles et des ports de destination. Vous pouvez spécifier un protocole, ou une combinaison de protocoles et de leurs ports de destination. Si vous ne spécifiez ni protocoles, ni ports, la règle de pare-feu est applicable pour l'ensemble du trafic sur n'importe quel protocole et n'importe quel port de destination. Les règles basées sur les ports sources ne sont pas acceptées.

Tous les protocoles ne sont pas compatibles avec les ports. Par exemple, des ports existent pour TCP et UDP, mais pas pour ICMP (ce protocole regroupe différents types ICMP, qui ne sont pas des ports et ne peuvent donc pas être spécifiés dans une règle de pare-feu).

Vous pouvez utiliser les noms de protocoles suivants dans les règles de pare-feu : tcp, udp, icmp (pour IPv4 ICMP), esp, ah, sctp et ipip. Pour tous les autres protocoles, vous devez utiliser les numéros de protocole IANA.

De nombreux protocoles ont les mêmes nom et numéro dans IPv4 et IPv6, ce qui n'est pas le cas de certains protocoles comme ICMP.

Le protocole IPv6 Hop-by-Hop n'est pas compatible avec les règles de pare-feu.

Le tableau ci-dessous récapitule les combinaisons de spécifications de protocole et de port de destination valides pour les règles de pare-feu Google Cloud.

Spécification Exemple Explication
Aucun protocole et aucun port  : Si vous ne spécifiez pas de protocole, la règle de pare-feu s'applique à tous les protocoles et à leurs ports de destination.
Protocole tcp Si vous spécifiez un protocole sans aucune information de port, la règle de pare-feu s'applique à ce protocole et à tous ses ports.
Protocole et port unique tcp:80 Si vous spécifiez un protocole et un seul port de destination, la règle de pare-feu s'applique à ce port de destination pour le protocole.
Protocole et plage de ports tcp:20-22 Si vous spécifiez un protocole et une plage de ports, la règle de pare-feu s'applique à cette plage de ports pour le protocole.
Combinaisons icmp,tcp:80
tcp:443
udp:67-69		 Vous pouvez spécifier différentes combinaisons de protocoles et de ports de destination auxquelles la règle de pare-feu s'applique. Pour plus d'informations, consultez la section Créer des règles de pare-feu.

Filtrer la source et la cible par compte de service

Vous pouvez utiliser des comptes de service pour créer des règles de pare-feu de nature plus spécifique :

  • Pour les règles d'entrée et de sortie, vous pouvez utiliser des comptes de service pour spécifier des cibles.

  • Pour les règles d'entrée, vous pouvez spécifier la source des paquets entrants comme étant l'adresse IP interne principale de toute VM du réseau dans lequel la VM utilise un compte de service particulier.

Le compte de service doit être créé dans le même projet que la règle de pare-feu et avant la création d'une règle de pare-feu qui lui est associée. Bien que le système ne vous empêche pas de créer une règle qui utilise un compte de service d'un autre projet, la règle n'est pas appliquée si le compte de service n'existe pas dans le projet de la règle de pare-feu.

Les règles de pare-feu qui utilisent des comptes de service pour identifier des instances s'appliquent aux instances créées et associées au compte de service, et aux instances existantes si vous modifiez leur compte de service. Si vous modifiez le compte de service associé à une instance, vous devez arrêter et redémarrer celle-ci. Vous pouvez associer des comptes de service à des instances individuelles et à des modèles d'instance utilisés par des groupes d'instances gérés.

Filtrer par compte de service ou par tag réseau

Cette section met en évidence les points clés à prendre en compte pour décider si vous devez utiliser des comptes de service ou des tags réseau pour définir des cibles et des sources (pour les règles d'entrée).

Si vous avez besoin d'un contrôle strict sur la manière dont les règles de pare-feu sont appliquées aux VM, utilisez les comptes de service cibles et sources au lieu des tags réseau cibles et sources :

  • Un tag réseau est un attribut arbitraire. Un ou plusieurs tags réseau peuvent être associés à une instance par toute entité principale IAM (Identity and Access Management) autorisé à modifier l'instance. Les entités principales IAM dotées du rôle Administrateur d'instances Compute Engine pour un projet disposent de cette autorisation. Les entités principales IAM autorisées à modifier une instance peuvent changer ses tags réseau, ce qui peut modifier l'ensemble de règles de pare-feu applicables à cette instance.

  • Un compte de service représente une identité associée à une instance. Un seul compte de service peut être associé à une instance. Vous contrôlez l'accès au compte de service en contrôlant l'attribution du rôle Utilisateur du compte de service aux autres entités principales IAM. Pour qu'une entité principale IAM démarre une instance à l'aide d'un compte de service, elle doit détenir le rôle "Utilisateur du compte de service" au moins pour ce compte, et disposer des autorisations nécessaires pour créer des instances (par exemple, détenir le rôle "Administrateur d'instances Compute Engine" pour le projet).

Vous ne pouvez pas combiner et faire correspondre des comptes de service et des tags réseau dans une règle de pare-feu :

  • Vous ne pouvez pas utiliser à la fois les comptes de service cibles et les tags réseau cibles dans une même règle de pare-feu (entrée ou sortie).

  • Si vous spécifiez des cibles par tag réseau cible ou par compte de service cible, les sources suivantes ne sont pas valides pour les règles de pare-feu d'entrée.

    Cibles Sources non valides
    Tags réseau cibles Comptes de service sources

    Combinaison de plages d'adresses IP sources et de comptes de service sources
    Compte de service cible Tags réseau sources

    Combinaison de plages d'adresses IP sources et de tags réseau sources

Les considérations opérationnelles concernant les comptes de service et les tags réseau sont les suivantes :

  • La modification d'un compte de service pour une instance nécessite que celle-ci soit arrêtée et redémarrée. L'ajout ou la suppression de tags réseau peut être effectué pendant que l'instance est en cours d'exécution.

  • Vous pouvez spécifier un nombre maximal de comptes de service cibles, de comptes de service sources, de tags réseau cibles et de tags réseau sources pour les règles de pare-feu. Pour en savoir plus, consultez la page Quotas de ressources des VPC.

  • Si vous identifiez des instances par tag réseau, la règle de pare-feu s'applique sur l'adresse IP interne principale de l'instance.

  • Les règles de pare-feu du compte de service s'appliquent au nœud GKE, et non au pod GKE.

Rôles et autorisations

Le tableau suivant décrit les autorisations de gestion de l'authentification et des accès (IAM) dont vous avez besoin pour utiliser les règles de pare-feu VPC.

Tâche Autorisation requise Exemple de rôle
Créer une règle de pare-feu compute.firewalls.create Administrateur de sécurité de Compute
(roles/compute.securityAdmin)
Supprimer une règle de pare-feu compute.firewalls.delete Administrateur de sécurité de Compute
(roles/compute.securityAdmin)
Modifier les règles de pare-feu compute.firewalls.update Administrateur de sécurité de Compute
(roles/compute.securityAdmin)
Afficher les détails d'une règle de pare-feu compute.firewalls.get Lecteur de réseau Compute
(roles/compute.networkViewer)
Afficher la liste des règles de pare-feu compute.firewalls.list Lecteur de réseau Compute
(roles/compute.networkViewer)

Cas d'utilisation

Les cas d'utilisation suivants illustrent le fonctionnement des règles de pare-feu. Dans ces exemples, toutes les règles de pare-feu sont activées.

Cas d'entrée

Les règles de pare-feu d'entrée contrôlent les connexions entrantes d'une source vers les instances cibles de votre réseau VPC. La source d'une règle d'entrée peut être définie par l'un des éléments suivants :

  • Une plage d'adresses IPv4 ou IPv6 ; la valeur par défaut est n'importe quelle adresse IPv4 (0.0.0.0/0)
  • Les autres instances de votre réseau VPC identifiées par des tags réseau
  • Les autres instances de votre réseau VPC identifiées par un compte de service
  • Les autres instances de votre réseau VPC identifiées par une plage d'adresses IPv4 ou IPv6 et par un tag réseau
  • Autres instances de votre réseau VPC identifiées par une plage d'adresses IPv4 ou IPv6 et par compte de service

La source par défaut est n'importe quelle adresse IP (0.0.0.0/0). Si vous souhaitez contrôler les connexions entrantes pour les sources extérieures à votre réseau VPC, y compris d'autres sources sur Internet, utilisez une plage d'adresses IPv4 au format CIDR.

Les règles d'entrée ayant une action allow autorisent le trafic entrant en fonction des autres composants de la règle. Outre la spécification de la source et de la cible pour la règle, vous pouvez limiter l'application de la règle à certains protocoles et ports de destination. De même, les règles d'entrée ayant une action deny peuvent être utilisées pour protéger les instances en bloquant le trafic entrant en fonction des composants de la règle de pare-feu.

Exemples d'entrée

La figure 1 illustre des exemples de règles de pare-feu pouvant contrôler des connexions d'entrée. Les exemples utilisent le paramètre de cible dans les attributions de règles pour appliquer des règles à des instances spécifiques.

Figure 1. Dans cet exemple de réseau VPC, les règles de pare-feu autorisant les entrées remplacent la règle implicite d'entrée interdite pour certaines VM (cliquez pour agrandir).

  • Une règle d'entrée ayant une priorité de 1000 est applicable à la VM 1. Cette règle autorise le trafic TCP entrant depuis n'importe quelle source (0.0.0.0/0). Le trafic TCP provenant d'autres instances du réseau VPC est autorisé, en tenant compte des règles de sortie applicables sur ces autres instances. La VM 4 est capable de communiquer avec la VM 1 via TCP, car la VM 4 n'a pas de règle de sortie bloquant de telles communications (seule la règle implicite de sortie autorisée est applicable). La VM 1 ayant une adresse IP externe, cette règle autorise également le trafic TCP entrant depuis des hôtes externes sur Internet et depuis la VM 2 via des adresses IP externes.

  • La VM 2 ne dispose d'aucune règle de pare-feu d'entrée. La règle implicite d'entrée interdite bloque donc l'intégralité du trafic entrant. Les connexions provenant d'autres instances du réseau sont bloquées, indépendamment des règles de sortie mises en place pour les autres instances. Comme la VM 2 possède une adresse IP externe, elle est accessible depuis des hôtes externes sur Internet, mais cette règle implicite d'entrée interdite bloque également le trafic entrant externe.

  • Une règle d'entrée ayant une priorité de 1000 est applicable à la VM 3. Cette règle autorise le trafic TCP provenant d'instances du réseau ayant le tag réseau client, comme la VM 4. Le trafic TCP de la VM 4 vers la VM 3 est autorisé, car la VM 4 ne dispose pas de règle de sortie bloquant de telles communications (seule la règle implicite de sortie autorisée est applicable). La VM 3 ne disposant pas d'une adresse IP externe, il n'existe pas de chemin d'accès depuis des hôtes externes sur Internet.

Cas de sortie

Les règles de pare-feu de sortie contrôlent les connexions sortantes des instances cibles vers votre réseau VPC. Les règles de sortie ayant une action allow autorisent le trafic des instances en fonction des autres composants de la règle. Par exemple, vous pouvez autoriser le trafic sortant vers des destinations spécifiques, telles qu'une plage d'adresses IPv4, sur les protocoles et les ports de destination que vous spécifiez. De même, les règles de sortie ayant une action deny bloquent le trafic en fonction des autres composants de la règle.

Chaque règle de sortie a besoin d'une destination. La destination par défaut est n'importe quelle adresse IPv4 (0.0.0.0/0), mais vous pouvez créer une destination plus spécifique en utilisant une plage d'adresses IPv4 ou IPv6 au format CIDR. Lorsque vous spécifiez une plage d'adresses IPv4, vous pouvez contrôler le trafic vers les instances de votre réseau et vers des destinations en dehors de votre réseau, y compris les destinations sur Internet.

Exemples de sortie

La figure 2 illustre quelques exemples de règles de pare-feu pouvant contrôler des connexions de sortie. Les exemples utilisent le paramètre de cible dans les attributions de règles pour appliquer des règles à des instances spécifiques.

Figure 2. Dans cet exemple de réseau VPC, les règles de pare-feu de refus du trafic sortant remplacent la règle implicite de sortie autorisée pour certaines VM (cliquez pour agrandir).

  • Aucune règle de pare-feu de sortie n'a été spécifiée pour la VM 1. Par conséquent, la règle implicite de sortie autorisée lui permet d'envoyer le trafic vers n'importe quelle destination. Les connexions à d'autres instances du réseau VPC sont autorisées, en tenant compte des règles d'entrée applicables à ces autres instances. La VM 1 est autorisée à envoyer du trafic vers la VM 4, car la VM 4 dispose d'une règle d'entrée autorisant le trafic entrant provenant de toute plage d'adresses IP. La VM 1 dispose d'une External IP (adresse IP externe). Elle est donc en mesure d'envoyer du trafic vers External host (hôtes externes) sur Internet. Les réponses entrantes au trafic envoyé par la VM 1 sont autorisées, car les règles de pare-feu sont "avec état".

  • Une règle de sortie ayant une priorité de 1000 est applicable à la VM 2. Cette règle refuse tout trafic sortant vers toutes les destinations (0.0.0.0/0). Le trafic sortant vers les autres instances du réseau VPC est bloqué, quelles que soient les règles d'entrée appliquées aux autres instances. Même si la VM 2 dispose d'une adresse IP externe, cette règle de pare-feu bloque son trafic sortant vers des hôtes externes sur Internet.

  • Une règle de sortie ayant une priorité de 1000 est applicable à la VM 3. Cette règle bloque le trafic TCP sortant vers toute destination dans la plage d'adresses IP 192.168.1.0/24. Même si les règles d'entrée pour la VM 4 autorisent l'intégralité du trafic entrant, la VM 3 ne peut pas envoyer de trafic TCP vers la VM 4. Cependant, la VM 3 est libre d'envoyer du trafic UDP à la VM 4, car la règle de sortie ne s'applique qu'au protocole TCP.

    En outre, la VM 3 peut envoyer tout type de trafic vers d'autres instances du réseau VPC en dehors de la plage d'adresses IP 192.168.1.0/24, à condition que ces autres instances disposent de règles d'entrée autorisant ce trafic. Comme elle ne possède pas d'adresse IP externe, elle n'a aucun moyen d'envoyer du trafic en dehors du réseau VPC.

Étapes suivantes

Faites l'essai

Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de VPC en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.

Profiter d'un essai gratuit de VPC