Interfaces réseau multiples

Cette page présente les configurations d'instances de machines virtuelles utilisant plusieurs interfaces réseau. Il y est question de leur fonctionnement et des exemples de configuration y sont présentés. Pour en savoir plus sur la création de configurations utilisant plusieurs interfaces, consultez la section Créer des VM avec plusieurs interfaces réseau.

Les VM dotées de plusieurs contrôleurs d'interface réseau sont appelées VM à cartes d'interface réseau multiples.

Google Cloud Par défaut, les réseaux de cloud privé virtuel (VPC) sont des domaines de mise en réseau privés isolés. Les réseaux ont un champ d'application global et contiennent des sous-réseaux régionaux. Les instances de VM dans un réseau VPC peuvent communiquer entre elles via leurs adresses IP internes si les règles de pare-feu le permettent. Cependant, aucune communication par adresse IP interne n'est autorisée entre les réseaux, sauf si vous mettez en place des systèmes tels qu'un appairage de réseaux VPC ou un réseau Cloud VPN.

Chaque instance d'un réseau VPC possède une interface réseau par défaut. Lorsque vous configurez une interface réseau, vous sélectionnez un réseau VPC et un sous-réseau au sein de ce réseau VPC auquel connecter l'interface. Vous pouvez créer des interfaces réseau supplémentaires associées à vos VM, mais elles doivent toutes être connectées à un réseau VPC différent. Utiliser plusieurs interfaces réseau vous permet de créer des configurations avec lesquelles une instance se connecte directement à plusieurs réseaux VPC.

En général, il est nécessaire d'utiliser plusieurs interfaces pour configurer une instance en tant que dispositif réseau chargé du pare-feu d'application Web (WAF), de l'équilibrage de charge, de la détection et de la prévention des intrusions (IDS/IPS) ou de l'optimisation WAN entre les réseaux. L'utilisation de plusieurs interfaces réseau est également utile lorsque des applications exécutées dans une instance nécessitent une séparation du trafic, telle que la séparation du trafic du plan de données de celui du plan de gestion.

Chaque interface d'une VM est affectée par la MTU du réseau connecté. Pour en savoir plus sur la MTU d'interface, consultez la section Unité de transmission maximum.

Cas d'utilisation

Utilisez plusieurs interfaces réseau lorsqu'une instance individuelle a besoin d'accéder à plusieurs réseaux VPC, mais que vous ne souhaitez pas connecter ces réseaux directement.

• Fonction réseau et sécurité : l'utilisation de plusieurs interfaces réseau active les fonctions de dispositif réseau virtuel, telles que les équilibreurs de charge, les serveurs de traduction d'adresses de réseau (NAT) et les serveurs proxy configurés avec plusieurs interfaces réseau. Pour en savoir plus, consultez la section Exemple 1: Dispositifs virtuels de mise en réseau et de sécurité.

• Isolation du périmètre (également appelée isolation DMZ) : une bonne pratique importante en matière d'architectures réseau à plusieurs niveaux consiste à isoler les services publics du réseau interne avec de ses services. Utilisez plusieurs interfaces réseau pour créer des configurations dans lesquelles on trouve des interfaces réseau distinctes sur l'instance, l'une d'entre elles acceptant le trafic public et l'autre gérant le trafic backend privé avec des contrôles d'accès plus restrictifs.

  Toutes les ressources accessibles depuis Internet doivent être séparées de votre réseau interne et de ses services. Cela limite considérablement la portée et les dommages qu'une violation de sécurité pourrait causer. Par exemple, vous pouvez placer une seconde interface réseau sur chaque serveur Web qui se connecte à un réseau de niveau intermédiaire sur lequel se trouve un serveur d'applications. Le serveur d'applications peut également être hébergé en double sur un réseau backend sur lequel se trouve le serveur de base de données. Chaque instance à double hébergement reçoit et traite les requêtes sur le frontal, initie une connexion au backend, puis envoie des requêtes aux serveurs du réseau backend.

  En configurant des interfaces distinctes, l'une publique et l'autre privée, vous pouvez appliquer à chacune des règles de pare-feu et des contrôles d'accès distincts, et appliquer des fonctions de sécurité pour les communications allant de la partie publique à la privée. Pour en savoir plus, consultez la section Exemple 2 : Utiliser des dispositifs tiers dans un scénario de réseau VPC partagé.

Spécifications

• Vous ne pouvez configurer une interface réseau que lorsque vous créez une instance.

• Si vous créez une instance avec plusieurs interfaces réseau, chaque interface doit se connecter à un réseau VPC différent. Les réseaux peuvent être des réseaux VPC autonomes ou des réseaux VPC partagés.

  Toutefois, les réseaux VPC créés avec un profil réseau RDMA vous permettent d'associer des cartes d'interface réseau RDMA au même réseau, où chaque carte est associée à un sous-réseau différent.

• Une interface réseau doit se connecter à un sous-réseau dont la plage d'adresses IP ne chevauche pas celle d'une autre interface de la même instance.

• Si vous souhaitez créer une VM associée à des sous-réseaux dans plusieurs réseaux VPC, tous les réseaux et sous-réseaux doivent exister avant de créer l'instance. Pour en savoir plus sur la création de réseaux et de sous-réseaux, consultez la section Créer et gérer des réseaux VPC.

• Vous ne pouvez pas supprimer une interface réseau sans supprimer l'instance à laquelle elle est associée.

• Chaque instance doit disposer d'au moins une interface réseau: nic0. Le nombre maximal d'interfaces varie selon le type de machine de l'instance.

• Vous pouvez configurer des interfaces de VM avec des adresses IPv4 uniquement, des adresses IPv4 et IPv6 (double pile) ou des adresses IPv6 uniquement (Preview). Le type de pile d'une interface détermine les adresses IP qu'elle peut avoir et le type de sous-réseaux auxquels elle peut se connecter. Pour en savoir plus, consultez la section Types de piles.

• Le serveur DHCP deGoogle Cloudenvoie une route par défaut (RFC 3442, "route statique sans classe") exclusivement à l'interface réseau par défaut, nic0. Si une route par défaut est nécessaire sur une autre interface réseau, vous devez configurer le routage des règles sur l'instance. Pour obtenir un exemple de procédure, consultez le tutoriel suivant: Configurer le routage pour une interface supplémentaire.

• Toutes les interfaces réseau de VM doivent se connecter à des sous-réseaux dans des réseaux appartenant au même projet que la VM ou à un réseau VPC partagé avec le projet.

Types de piles

Lorsque vous créez une interface réseau, vous spécifiez un type de pile. Le type de pile d'une interface détermine les adresses IP qu'elle peut avoir et le type de sous-réseaux auxquels elle peut se connecter. Pour en savoir plus, consultez le tableau suivant:

Type de pile d'interface	Adresses IP	Types de sous-réseaux compatibles
IPv4 uniquement (pile unique)	Une adresse IPv4 interne (obligatoire) Une adresse IPv4 externe (facultatif)	Sous-réseaux IPv4 uniquement et à double pile
IPv4 et IPv6 (double pile)	Une adresse IPv4 interne (obligatoire) Une adresse IPv4 externe (facultatif) Une plage d'adresses IPv6 /96, internes ou externes, mais pas les deux (obligatoire)	Sous-réseaux à double pile
IPv6 uniquement (pile unique) (bêta)	Une plage d'adresses IPv6 /96, internes ou externes, mais pas les deux (obligatoire)	Sous-réseaux IPv6 uniquement (Preview) et à double pile

Allouer les adresses IP des interfaces réseau

Pour les interfaces avec des adresses IPv4:

• Vous devez configurer chaque interface réseau avec une adresse IPv4 interne principale allouée à partir de la plage d'adresses IPv4 principale d'un sous-réseau. L'adresse interne principale attribuée à chacune des interfaces d'une même instance doit être différente.
• Facultatif: vous pouvez configurer chacune des interfaces réseau avec une adresse IPv4 externe unique. Les adresses externes peuvent être éphémères ou réservées.

Pour les interfaces avec des adresses IPv6:

• Vous devez attribuer une plage d'adresses IPv6 /96 à partir de la plage d'adresses IPv6 d'un sous-réseau. La première adresse IPv6 de la plage (/128) est configurée sur l'interface. Pour en savoir plus, consultez la section Attribution d'adresses IPv6.
• La plage d'adresses IPv6 /96 peut être interne ou externe, en fonction du type d'accès IPv6 du sous-réseau.

Nombre maximal d'interfaces réseau

Pour la plupart des types de machines, le nombre d'interfaces réseau virtuelles s'adapte au nombre de processeurs virtuels (2 au minimum, 10 au maximum).

Le tableau suivant vous permet de déterminer le nombre d'interfaces réseau pouvant être associées à une instance :

Nombre de processeurs virtuels	Nombre de cartes d'interface réseau virtuelles
2 ou moins	2
4	jusqu'à 4
6	jusqu'à 6
8 ou plus	jusqu'à 8
10 ou plus	jusqu'à 10

Limites

• Vous ne pouvez pas ajouter ou supprimer des interfaces réseau dans une VM existante.

• Vous ne pouvez pas utiliser la console Google Cloud pour créer des configurations multi-NIC pour des modèles d'instances ou des groupes d'instances. Utilisez plutôt gcloud CLI ou l'API.

• Pour savoir si vous pouvez modifier le type de pile de l'interface d'une VM, consultez les informations suivantes:

  • Vous pouvez modifier le type de pile d'une interface existante de IPv4 uniquement à double pile, ou de double pile à IPv4 uniquement.

  • Les interfaces IPv6 uniquement (Preview) ne sont compatibles qu'avec la création de VM. Vous ne pouvez pas modifier le type de pile d'une interface IPv4 uniquement ou à double pile existante en IPv6 uniquement.

  • De plus, vous ne pouvez pas modifier le type de pile d'une interface IPv6 uniquement en double pile ou en IPv4 uniquement.

• Une interface IPv6 uniquement (Preview) ne peut avoir qu'une seule plage d'adresses internes ou externes en fonction du type d'accès de son sous-réseau connecté. Pour créer une instance IPv6 uniquement avec une adresse IP interne et externe, vous devez la configurer avec deux interfaces.

• Le transfert IP est activé au niveau de la VM et ne peut pas être appliqué à des interfaces individuelles.

• Vous ne pouvez pas configurer plusieurs interfaces réseau pour les instances Bare Metal Compute Engine, qui ne peuvent avoir qu'une seule vNIC.

• Le nombre maximal de vNIC pour la série de machines A3 est différent du nombre maximal pour la plupart des types de machines. Pour en savoir plus, consultez la série de machines A3.

Exemples de configuration

Cette section examine plusieurs exemples courants d'utilisation de plusieurs interfaces réseau.

Exemple 1 : Dispositifs virtuels de mise en réseau et de sécurité

Les dispositifs virtuels de mise en réseau et de sécurité, tels que les pare-feu d'applications Web, les pare-feu de sécurité au niveau de l'application et les accélérateurs WAN, sont généralement configurés avec plusieurs interfaces virtuelles. Chacune des interfaces est configurée avec sa propre adresse IP interne et, éventuellement, avec sa propre adresse IP externe.

La figure 1 décrit un exemple de configuration d'un pare-feu au niveau de l'application qui contrôle le trafic depuis Internet vers un réseau VPC. Le pare-feu au niveau de l'application est mis en œuvre dans les VM Compute Engine.

Dans cet exemple, la route par défaut de la VM de dispositif a été configurée pour utiliser nic1.

Figure 1 : Une instance avec une VM de dispositif possède trois interfaces réseau. Chaque interface est connectée à un sous-réseau qui se trouve dans un réseau VPC différent (cliquez pour agrandir).

Provisionner et configurer des instances pour l'exemple 1

Le code suivant suppose que subnet0, subnet1 et subnet2 existent déjà, avec des plages d'adresses IP qui ne se chevauchent pas.

Pour créer la VM et les interfaces réseau dans cet exemple, utilisez la commande suivante :

gcloud compute instances create vm-appliance \
    --network-interface subnet=subnet0,no-address \
    --network-interface subnet=subnet1 \
    --network-interface subnet=subnet2,no-address \
    --machine-type n1-standard-4

Cette commande crée une instance avec trois interfaces réseau :

• nic0 est associée à subnet0 et n'a pas d'adresse IP externe.
• nic1 est associée à subnet1 et possède une adresse IP externe éphémère.
• nic2 est associée à subnet2 et n'a pas d'adresse IP externe.

Exemple 2 : Utiliser des dispositifs tiers dans un scénario de réseau VPC partagé

Cette configuration est utile lorsque vous souhaitez partager un ensemble unique de dispositifs tiers centralisés pour les charges de travail ou les applications hébergées dans différents projets. Dans la figure 2, quatre applications distinctes (App1, App2, App3 et App4) sont hébergées dans différents projets de service. Vous devez les protéger de toutes les entrées Internet, et faire en sorte que le trafic de sortie soit inspecté et filtré par un dispositif tiers situé dans le projet hôte de VPC partagé.

Figure 2. Une instance appartenant à un projet hôte de VPC partagé héberge un dispositif de VM. L'instance dispose d'une interface réseau pour chacun des quatre projets de service et d'une autre interface pour le réseau VPC du périmètre réseau (cliquez pour agrandir).

Provisionner et configurer la VM et les interfaces réseau pour l'exemple 2

Pour créer la VM et les interfaces réseau dans cet exemple, utilisez la commande suivante :

gcloud compute instances create VM-appliance \
    --network-interface subnet=subnet-perimeter,address='reserved-address' \
    --network-interface subnet=subnet-1,no-address \
    --network-interface subnet=subnet-2,no-address \
    --network-interface subnet=subnet-3,no-address \
    --network-interface subnet=subnet-4,no-address \
    --machine-type=n1-standard-4

Cela crée une instance avec cinq interfaces réseau :

• nic0 est associée à subnet-perimeter, qui fait partie de network-perimeter, avec une adresse statique reserved-address.
• nic1 est associée à subnet-1, qui fait partie de network-1, sans adresse IP externe.
• nic2 est associée à subnet-2, qui fait partie de network-2, sans adresse IP externe.
• nic3 est associée à subnet-3, qui fait partie de network-3, sans adresse IP externe.
• nic4 est associée à subnet-4, qui fait partie de network-4, sans adresse IP externe.

Détails opérationnels supplémentaires

Plusieurs interfaces réseau dans un environnement VPC partagé

Le VPC partagé vous permet de partager des réseaux VPC entre des projets dans votre Google Cloud organisation.

Il vous permet de créer des instances associées à un réseau VPC partagé hébergé dans un projet hôte de VPC partagé centralisé. Pour en savoir plus sur la configuration des réseaux VPC partagés, consultez la page Provisionner le VPC partagé.

Remarque : La connexion à un réseau VPC partagé avec des interfaces autres que nic0 est possible pour les configurations suivantes :

• Instances de VM : compatibles avec la console Google Cloud, gcloud CLI et l'API.
• Modèles d'instances : compatibles avec gcloud CLI et l'API.
• Groupes d'instances gérés : compatibles avec gcloud CLI et l'API.

Pour créer des instances utilisant une ou plusieurs interfaces associées à des réseaux VPC partagés, vous devez disposer du rôle d'utilisateur de réseau Compute (roles/compute.networkUser) dans le projet hôte VPC partagé.

Résolution DNS avec plusieurs interfaces réseau

Lorsqu'une requête DNS interne est effectuée avec le nom d'hôte de l'instance, elle se résout au niveau de l'interface principale (nic0) de l'instance. Si l'interface nic0 de l'instance est associée à un sous-réseau d'un réseau VPC différent de celui de l'instance émettant la requête DNS interne, la requête échoue.

Les enregistrements DNS privés de Compute Engine ne sont pas générés pour chaque interface.

Comportement DHCP avec plusieurs interfaces réseau

Dans une configuration par défaut comportant plusieurs interfaces, le système d'exploitation est configuré pour utiliser le DHCP. Le comportement du DHCP et de l'ARP de chacune des interfaces est identique à celui du DHCP et de l'ARP dans une instance dotée d'une interface unique.

Dans une instance avec plusieurs interfaces utilisant DHCP, chaque interface obtient une route vers le sous-réseau auquel elle appartient. En outre, l'instance obtient une route par défaut unique associée à l'interface principale eth0. Sauf configuration manuelle différente, tout trafic quittant une instance pour une destination autre qu'un sous-réseau directement connecté quittera l'instance en utilisant la route par défaut sur eth0.

Le comportement est le même que pour les interfaces avec des adresses IPv6. L'interface obtient une route pour la plage de sous-réseau IPv6 dans laquelle elle se trouve, ainsi qu'une route IPv6 par défaut.

Dans cet exemple, l'interface principale eth0 obtient la route par défaut default via 10.138.0.1 dev eth0, et les deux interfaces eth0 et eth1 obtiennent une route pour leurs sous-réseaux respectifs.

instance-1:~$ ip route
default via 10.138.0.1 dev eth0
10.137.0.0/20 via 10.137.0.1 dev eth1
10.137.0.1 dev eth1 scope link
10.138.0.0/20 via 10.138.0.1 dev eth0
10.138.0.1 dev eth0 scope link

Pour plus d'informations, consultez le tutoriel suivant : Configurer le routage pour une interface supplémentaire.

Routes statiques personnalisées et interfaces réseau multiples

Lorsqu'une instance de VM possède plusieurs interfaces ainsi qu'un tag réseau, ce tag ne s'applique pas nécessairement à la totalité des interfaces de la VM. Le tag réseau d'une VM n'a une incidence sur une interface que si celle-ci fait partie d'un réseau VPC qui contient une route statique marquée par un tag correspondant.

Par exemple :

1. Une VM possède deux interfaces : nic0 et nic1. L'interface nic0 fait partie du réseau vpc-net-a. L'interface nic1 fait partie du réseau vpc-net-b. La VM possède un tag réseau appelé vpn-ok. Le tag est un attribut appliqué à l'instance, et non à une interface spécifique.
2. Le réseau vpc-net-a dispose d'une route statique personnalisée avec un tag appelé vpn-ok.
3. Le réseau vpc-net-b dispose d'une route statique personnalisée avec un tag appelé vpn-123.

Ces étapes numérotées correspondent à la figure 3:

Figure 3. La route statique personnalisée de vpc-net-a concerne nic0 car elles ont un tag en commun, tandis que la route statique personnalisée du vpc-net-b n'affecte pasnic1 (cliquez sur l'image pour l'agrandir).

Dans le cas du réseau vpc-net-a, du fait qu'il possède une route ayant un tag en commun avec la VM, le tag vpn-ok de la VM s'applique à l'interface nic0 de la VM dans le réseau vpc-net-a. En revanche, comme le réseau vpc-net-b ne possède pas de route statique associée au tag vpn-ok, le tag réseau vpn-ok de la VM est ignoré sur l'interface nic1 de la VM.

Utiliser des tags avec les routes dans des instances avec plusieurs interfaces réseau

Si vous choisissez d'utiliser des tags avec les routes, notez qu'ils sont appliqués au niveau de l'instance et que, par conséquent, ils s'appliquent à toutes les interfaces d'une instance de machine virtuelle. Si ce n'est pas ce que vous souhaitez, assurez-vous que les tags appliqués aux routes sont propres à chaque réseau VPC.

Équilibreurs de charge et interfaces réseau multiples

Sauf dans le contexte de l'équilibrage de charge TCP/UDP interne, tous les équilibreurs de charge Google Cloud ne distribuent le trafic que vers la première interface (nic0) d'une instance backend.

Règles de pare-feu et interfaces réseau multiples

Chaque réseau VPC possède son propre ensemble de règles de pare-feu. Si l'interface d'une instance se trouve dans un réseau VPC donné, les règles de pare-feu de ce réseau s'appliquent à cette interface.

Par exemple, supposons qu'une instance de VM possède deux interfaces :

• nic0 dans le réseau VPC network-1
• nic1 dans le réseau VPC network-2

Les règles de pare-feu que vous créez pour le réseau network-1 s'appliquent à nic0. Les règles de pare-feu que vous créez pour le réseau network-2 s'appliquent à nic1.

Pour plus d'informations, consultez la section Règles de pare-feu VPC.

Utiliser des pare-feu sur des instances avec plusieurs interfaces réseau

• Les règles de pare-feu d'entrée peuvent utiliser des tags réseau ou des comptes de service pour identifier les sources, les cibles (destinations) ou les deux.

• Les règles de pare-feu de sortie peuvent utiliser des tags réseau ou des comptes de service pour identifier des cibles (sources).

Pour en savoir plus, consultez la section Filtrer la source et la cible par compte de service.

Les tags réseau et les comptes de service identifient des instances, et non des interfaces spécifiques. Gardez à l'esprit que les règles de pare-feu sont associées à un réseau VPC unique et que chaque interface d'une instance à plusieurs cartes d'interface réseau doit se trouver dans un sous-réseau qui se trouve dans un réseau VPC unique.

L'exemple suivant montre comment utiliser efficacement les tags sources pour les règles de pare-feu autorisant le trafic entrant (allow). L'instance vm1 comporte deux interfaces réseau :

• nic0 dans le réseau network-1
• nic1 dans le réseau network-2

Supposons que vous ayez besoin d'autoriser le trafic suivant depuis vm1 :

• Trafic SSH provenant de vm1 à destination de n'importe quelle instance dans le réseau network-1
• Trafic HTTP et HTTPS provenant de vm1 à destination de n'importe quelle instance dans le réseau network-2

Pour mettre en place cette configuration, procédez comme suit :

1. Attribuez deux tags réseau à vm1 : vm1-network1 et vm1-network2.

2. Créez une règle de pare-feu autorisant le trafic entrant (allow) pour le réseau network-1. Les composants suivants permettent d'autoriser le trafic SSH provenant de vm1 vers toutes les VM du réseau network-1 :

   • Action : allow
   • Direction : ingress
   • Sources : VM ayant le tag vm1-network1
   • Cibles : toutes les instances du réseau VPC
   • Protocoles et ports : tcp:22

3. Créez une règle de pare-feu autorisant le trafic entrant pour le réseau network-2. Les composants suivants permettent d'autoriser le trafic HTTP et HTTPS provenant de vm1 vers toutes les VM du réseau network-2 :

   • Action : allow
   • Direction : ingress
   • Sources : VM ayant le tag vm1-network2
   • Cibles : toutes les instances du réseau VPC
   • Protocoles et ports : tcp:80,443

La figure 4 illustre cet exemple de configuration de pare-feu :

Figure 4. La règle de pare-feu 1 et la règle de pare-feu 2 possèdent chacune un tag source associé à la VM1. La règle de pare-feu 1, qui se trouve dans network-1, ne concerne que nic0 de la VM1, car elles se trouvent toutes deux dans network-1. La règle de pare-feu 2 n'affecte que nic1 de la VM1, car ils partagent également un réseau (cliquez pour agrandir).

Étapes suivantes

• Consultez la section Créer des VM avec plusieurs interfaces réseau.