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.

Par défaut, les réseaux de cloud privé virtuel (VPC) Google Cloud 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.

Chaque instance peut avoir jusqu'à huit interfaces selon le type d'instance. Pour en savoir plus, consultez la section Nombre maximal d'interfaces réseau.

Les adresses IP suivantes peuvent être configurées sur chaque interface :

• Une adresse IPv4 interne (obligatoire)
• Une adresse IPv4 externe

• Une adresse IPv6, interne ou externe, mais pas les deux

  Pour configurer une adresse IPv6, vous devez connecter l'interface à un sous-réseau sur lequel une plage IPv6 est configurée.

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é.

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 organisation Google Cloud.

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 Google Cloud Console, 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 la section Configurer une liaison de règle.

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 personnalisée marquée par un tag correspondant.

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.