Ce document est destiné aux administrateurs réseau, aux architectes de solutions et aux professionnels des opérations qui exécutent des dispositifs réseau centralisés sur Google Cloud. Vous devez connaître Compute Engine et la mise en réseau via cloud privé virtuel (VPC) dans Google Cloud.
Les environnements d'entreprise doivent souvent acheminer le trafic vers Internet, vers un réseau sur site, vers d'autres clouds, ou même vers d'autres parties du même environnement cloud, via des dispositifs virtualisés basés sur des VM qui surveillent, transforment ou bloquent le trafic.
Ce document passe en revue plusieurs options de conception qui segmentent les réseaux VPC et les interconnectent avec un dispositif réseau centralisé et virtualisé. Toutes les communications entre les réseaux VPC, les réseaux sur site et le réseau Internet sont acheminées via le dispositif centralisé. Vous pouvez déployer un groupe de dispositifs redondants pour obtenir une configuration à haute disponibilité. Si vous n'avez pas besoin de la haute disponibilité, vous pouvez déployer un seul dispositif réseau.
Le routage du trafic via des dispositifs virtualisés peut s'avérer difficile. Sur Google Cloud, par exemple, vous pouvez remplacer la route pointant vers Internet et rediriger le trafic vers un ensemble de dispositifs virtualisés, mais il n'est pas possible de modifier le comportement de routage entre les sous-réseaux d'un réseau VPC. Le routage entre les sous-réseaux est automatique. Ces routes ne peuvent être ni supprimées ni remplacées.
De plus, en raison de leur rôle crucial, les dispositifs virtualisés doivent être déployés dans des configurations à disponibilité élevée. L'opération est complexe, car vous devez vous assurer que tout le trafic est acheminé via l'un des dispositifs virtuels et que le basculement entre ces systèmes s'effectue automatiquement.
Architecture
Le schéma suivant illustre un cas d'utilisation typique de plusieurs options de conception présentant un dispositif réseau centralisé et virtualisé.
Le schéma précédent montre les chemins de communication entre des réseaux VPC segmentés et des réseaux sur site, ainsi que leur mode de routage via le dispositif réseau centralisé et virtualisé.
Principaux cas d'utilisation de cette architecture
Vous pouvez utiliser cette architecture pour plusieurs cas d'utilisation impliquant le routage du trafic au moyen de dispositifs réseau virtualisés. Gardez à l'esprit les points suivants :
- De nombreux dispositifs sont proposés par différents fournisseurs sur Google Cloud Marketplace.
- Certains fournisseurs proposent également des images Compute Engine personnalisées pour Google Cloud sur leur site Web ou leurs pages d'assistance.
- Vous pouvez créer vos propres dispositifs virtualisés à l'aide d'un logiciel de mise en réseau Open Source. Vous pouvez également créer vos propres images.
Les fournisseurs proposent souvent leurs propres architectures de référence ou guides de déploiement pour exécuter leurs dispositifs virtualisés dans une configuration à haute disponibilité. Pour plus d'informations, consultez le site Web du fournisseur.
Les architectures de référence du fournisseur peuvent ne pas couvrir toutes les options présentées dans ce document.
Il est important de comprendre les avantages et les inconvénients de chaque approche. Voici quelques cas d'utilisation courants de routage du trafic au moyen de dispositifs virtuels :
- Pare-feu nouvelle génération. Un ensemble centralisé de pare-feu s'exécute en tant que machines virtuelles qui fournissent des fonctionnalités qui ne sont pas disponibles avec les règles de pare-feu VPC. Il s'agit du cas d'utilisation le plus courant. Les fonctionnalités types des produits nouvelle génération incluent l'inspection approfondie des paquets (DPI) et la mise en place de pare-feu sur la couche d'application. Certains pare-feu nouvelle génération fournissent également une inspection du trafic TLS/SSL, ainsi que d'autres fonctions de mise en réseau décrites dans les cas d'utilisation répertoriés ci-dessous.
- Système de détection des intrusions/de prévention des intrusions (IDS/IPS). Un IDS basé sur le réseau nécessite la visibilité de tout le trafic potentiellement malveillant. Pour prévenir les intrusions, le trafic est généralement bloqué directement par une adresse IP externe dans le chemin du trafic.
- Proxy transparent. Un proxy transparent est souvent utilisé pour surveiller le trafic HTTP(S) et pour appliquer des restrictions d'accès au Web.
- Passerelle de traduction d'adresses réseau (NAT) Une passerelle NAT traduit les adresses IP et les ports. Cela permet, par exemple, d'éviter les chevauchements d'adresses IP. Google Cloud propose Cloud NAT en tant que service géré, mais ce service n'est disponible que pour le trafic vers Internet, et non pour le trafic sur site ou pour les autres réseaux VPC sur Google Cloud.
- Pare-feu d'application Web (WAF). Un WAF bloque le trafic HTTP malveillant vers une application Web. Google Cloud propose une fonctionnalité WAF via les règles de sécurité de Google Cloud Armor. La fonctionnalité exacte diffère selon les fournisseurs WAF. Il est donc important de déterminer exactement ce dont vous avez besoin.
Exigences types
Les exigences de routage du trafic via des dispositifs virtuels centralisés varient en fonction du cas d'utilisation. Toutefois, les exigences suivantes s'appliquent d'une manière générale :
- Tout le trafic entre différents segments de réseau, par exemple des environnements gérés par différentes équipes avec des exigences de sécurité distinctes ou entre différents modules d'une application, doit passer par un dispositif virtuel centralisé.
- Tout le trafic vers ou depuis Internet vers des environnements sécurisés doit passer par un dispositif virtuel centralisé.
- Tout le trafic vers ou à depuis des systèmes sur site connectés à Google Cloud via Cloud VPN, l'interconnexion dédiée ou l'interconnexion partenaire doit passer par un dispositif virtuel centralisé.
- Plusieurs dispositifs virtuels centralisés sont configurés en mode haute disponibilité dans une configuration de routage actif/actif ou actif/passif. Le basculement s"effectue automatiquement si des problèmes logiciels ou matériels surviennent sur l'un des dispositifs virtualisés.
- Tout le trafic est routé avec état, de sorte qu'un flux de trafic entre deux machines virtuelles passe toujours par le même dispositif virtuel.
- Le débit du système de dispositifs virtuels centralisés est évolutif selon l'une des deux options suivantes :
- Scaling vertical des dispositifs virtuels : augmentation du nombre de cœurs ou de la quantité de mémoire sur chaque machine virtuelle.
- Scaling horizontal des dispositifs virtuels : augmentation du nombre de dispositifs virtuels utilisés pour répartir le trafic.
Options d'architecture
Il existe plusieurs options permettant d'établir la haute disponibilité entre des dispositifs virtuels. Il existe également plusieurs options pour associer des segments de réseau aux dispositifs virtuels.
Les options de haute disponibilité peuvent être combinées avec toute option de rattachement de segments de réseau. Un cas d'utilisation courant décrit plus loin dans ce document est une architecture qui utilise l'appairage de réseaux VPC et l'équilibreur de charge réseau interne à stratégie directe comme saut suivant.
Choisir une option de haute disponibilité
Vous pouvez créer une architecture permettant d'obtenir une haute disponibilité du dispositif central en utilisant plusieurs instances des deux manières suivantes :
Utiliser un équilibreur de charge réseau interne à stratégie directe comme saut suivant. Dans cette approche, vous placez plusieurs dispositifs virtuels dans un groupe d'instances géré derrière un équilibreur de charge réseau interne à stratégie directe. Cet équilibreur de charge est utilisé comme saut suivant pour une route par défaut qui remplace la route par défaut dans les réseaux VPC connectés aux dispositifs. Vous pouvez utiliser des dispositifs dans une configuration de routage actif/actif, soit la configuration standard, ou actif/passif en faisant appel au basculement pour les équilibreurs de charge réseau internes à stratégie directe. Les vérifications d'état dirigent le trafic vers les instances opérationnelles. Si vous souhaitez recréer automatiquement des dispositifs en cas d'échec, vous pouvez utiliser l'autoréparation. Si votre appareil utilise plusieurs interfaces réseau, un équilibreur de charge réseau interne à stratégie directe comme saut suivant peut utiliser des backends sur n'importe quelle interface réseau.
Le schéma suivant illustre la topologie d'utilisation d'un équilibreur de charge réseau interne à stratégie directe en tant que saut suivant.
Le schéma précédent montre un groupe d'instances géré dans un réseau VPC, y compris plusieurs dispositifs virtuels situés derrière un équilibreur de charge réseau interne à stratégie directe, qui sert de saut suivant.
Utiliser le routage. Dans cette approche, les routes Google Cloud dirigent le trafic vers les dispositifs virtuels à partir des réseaux VPC connectés. Vous pouvez utiliser des dispositifs dans une configuration de routage actif/passif en empruntant différentes routes prioritaires, ou actif/actif lorsque les routes sont configurées avec la même priorité, auquel cas vous utilisez le routage ECMP (Equal Cost Multi-Path) pour répartir le trafic. Vous pouvez utiliser l'autoréparation pour vous assurer que les dispositifs redémarrent lorsqu'ils ne sont pas opérationnels.
Le schéma suivant illustre la topologie d'utilisation du routage.
Le schéma précédent montre un groupe d'instances géré dans un réseau VPC avec des routes Google Cloud qui dirigent le trafic vers les dispositifs virtuels à partir du réseau VPC connecté.
Par rapport au routage Google Cloud pour la haute disponibilité, l'utilisation d'un équilibreur de charge réseau interne à stratégie directe comme saut suivant présente certains avantages :
- Les vérifications d'état déterminent l'emplacement vers lequel le trafic est transféré, ce qui permet de s'assurer que le trafic n'est acheminé que vers les instances opérationnelles. Vous pouvez exposer les vérifications d'état afin de valider l'instance locale ou un chemin de bout en bout.
- Vous pouvez affiner les minuteurs de la vérification d'état pour accélérer le basculement. Cette approche fournit les délais de basculement les plus courts en cas d'instances non opérationnelles.
- Le hachage symétrique vous permet de vous assurer que le trafic retour est acheminé vers la même machine virtuelle que le trafic sortant.
L'utilisation du routage Google Cloud présente les inconvénients suivants :
- Le hachage symétrique et cohérent garantit que les paquets pour une connexion donnée sont traités par la même VM de backend, pour les requêtes et les réponses, en fonction de la sélection du protocole et de l'affinité de session. La sélection du protocole et de l'affinité de session détermine si le suivi de connexion est utilisé ou non. Certains cas d'utilisation peuvent tirer parti d'une configuration NAT source dans les instances backend. Par exemple, si une connexion de réponse d'un réseau à un autre doit correspondre à une connexion de requête distincte dans la même direction entre les deux mêmes réseaux.
L'utilisation du routage Google Cloud présente les inconvénients suivants :
- Les vérifications d'état suppriment et recréent les instances non opérationnelles du pool d'instances. Cependant, le flux de trafic ne change pas immédiatement en cas d'échec des vérifications d'état, car supprimer les instances non opérationnelles et en créer de nouvelles demande du temps. Les délais de basculement sont plus longs.
- Si vous définissez des compteurs de vérification d'état pour éviter toute suppression et recréation d'instances inutile, le basculement sera ralenti.
Que vous utilisiez un équilibreur de charge réseau interne à stratégie directe en tant que saut suivant ou un routage Google Cloud, l'ensemble du trafic de protocole est accepté. Pour obtenir des informations détaillées sur cette compatibilité, consultez la section Traitement du trafic TCP, UDP et d'autres protocoles.
De même, les deux solutions permettent de limiter les routes vers certains tags réseau. Par exemple, les instances de VM peuvent être segmentées par région pour utiliser différents ensembles de dispositifs.
Choisir une option pour associer des segments de réseau
Comme le routage entre les sous-réseaux ne peut pas être remplacé, les segments de réseau sont mis en œuvre à l'aide de réseaux VPC distincts. Le trafic entre ces réseaux VPC, vers un environnement sur site et vers Internet doit être acheminé via les dispositifs centralisés. Notez que tous ces segments de réseau peuvent être des réseaux VPC autonomes ou des réseaux VPC partagés.
Plusieurs options permettent d'associer des segments de réseau, comme suit :
Interfaces réseau multiples. Le moyen le plus simple de connecter plusieurs réseaux VPC via un dispositif virtuel consiste à utiliser plusieurs interfaces réseau, chaque interface se connectant à l'un des réseaux VPC. La connectivité Internet et sur site est fournie sur une ou deux interfaces réseau distinctes. Avec de nombreux produits NGFW, la connectivité Internet est assurée via une interface marquée comme non approuvée dans le logiciel NGFW.
Le schéma suivant illustre cette topologie.
Le schéma précédent illustre plusieurs réseaux VPC se connectant à l'aide d'un dispositif virtuel à l'aide de plusieurs interfaces réseau. Chaque interface se connecte à l'un des réseaux VPC. Le schéma montre également les connexions Internet et sur site sur des interfaces réseau distinctes, y compris une connexion Internet via une interface non approuvée.
Appairage de réseaux VPC. Cette topologie utilise le concept de réseau en étoile conjointement avec l'appairage de réseaux VPC. Les segments de réseau sont mis en œuvre sous la forme d'un ensemble de réseaux VPC en étoile appairés à l'aide de l'appairage de réseaux VPC avec un réseau VPC hub, dans lequel le trafic est acheminé via le pool centralisé de dispositifs virtualisés. La ou les routes par défaut pointant vers l'équilibreur de charge réseau interne à stratégie directe en tant que saut suivant ou directement vers les dispositifs virtuels sont exportées en tant que routes personnalisées sur l'appairage de réseaux VPC. La connectivité Internet et sur site est fournie sur une ou deux interfaces réseau distinctes.
Le schéma suivant illustre cette topologie.
Le schéma précédent montre un pool centralisé de dispositifs virtualisés avec plusieurs interfaces réseau associées à plusieurs réseaux VPC hubs. Chaque réseau VPC hub est associé à plusieurs réseaux VPC via l'appairage de réseaux VPC. Le trafic entre deux réseaux VPC est acheminé via le pool centralisé de dispositifs virtualisés.
Combiner plusieurs interfaces réseau et l'appairage de réseaux VPC. Cette approche combine les deux options précédentes pour une évolutivité supplémentaire. Plusieurs interfaces réseau sont associées à plusieurs réseaux VPC hubs, chacun étant connecté à plusieurs réseaux VPC satellites via l'appairage de réseaux VPC. Pour chaque réseau VPC en étoile, vous utilisez la même approche que celle décrite dans le cas de l'appairage de réseaux VPC.
Le schéma suivant illustre cette topologie.
Le schéma précédent montre un réseau VPC hub associé à plusieurs réseaux VPC via l'appairage de réseaux VPC. Le trafic est acheminé via le pool centralisé de dispositifs virtualisés avec une interface réseau dans le réseau hub.
L'arbre de décision suivant peut vous aider à choisir la meilleure approche pour associer des segments de réseau.
L'utilisation de plusieurs interfaces réseau (la première approche présentée dans les cas précédents) est la plus simple à mettre en œuvre.
Cependant, l'utilisation de plusieurs interfaces réseau présente les inconvénients suivants :
- Vous êtes limité à huit interfaces réseau par instance de machine virtuelle. Si vous utilisez une interface réseau pour la connectivité Internet et une pour la connectivité sur site, vous ne pouvez connecter que six segments de réseau sur Google Cloud. Certains systèmes nécessitent une interface de gestion supplémentaire, ce qui vous limite à cinq segments de réseau.
- Vous ne pouvez ni ajouter ni supprimer d'interfaces réseau après la création d'une instance.
L'utilisation de l'appairage de réseaux VPC présente les avantages suivants :
- Vous pouvez effectuer un scaling à la hausse jusqu'à la limite des connexions d'appairage de réseaux VPC à partir d'un seul réseau VPC. Contactez l'équipe commerciale Google Cloud si vous avez des questions sur l'augmentation de cette limite.
- Vous pouvez facilement ajouter ou supprimer des réseaux VPC à partir de cette architecture en configurant l'appairage de réseaux VPC.
Cependant, l'utilisation de l'appairage de réseaux VPC présente les inconvénients suivants :
- Cette approche est légèrement plus complexe que celle qui utilise plusieurs interfaces réseau.
- Le nombre de VPC pouvant être connectés est toujours limité par rapport à l'approche combinée.
L'utilisation de l'approche combinée (plusieurs interfaces réseau et appairage de réseaux VPC) présente les avantages suivants :
- Il s'agit de l'approche la plus évolutive, car la limite est le produit de la limite des interfaces réseau et de la limite des connexions d'appairage de VPC. Par exemple, vous pouvez connecter six réseaux VPC hubs à des interfaces réseau distinctes, chacune étant associée à 25 réseaux VPC satellites connectés. Vous obtenez ainsi une limite de 150 réseaux VPC qui échangent du trafic via un ensemble de dispositifs virtuels.
Cependant, cette approche présente les inconvénients suivants :
- Il s'agit de l'approche la plus complexe à mettre en œuvre.
Exemples d'architecture
Voici deux exemples d'architecture. Le premier exemple montre comment utiliser l'équilibreur de charge réseau interne à stratégie directe pour la haute disponibilité, en association avec l'appairage de réseaux VPC pour associer des segments de réseau. Le deuxième exemple d'architecture, un cas d'utilisation spécial, montre comment acheminer le trafic d'un seul réseau VPC partagé sur Google Cloud vers un environnement sur site et vers Internet.
Exemple d'architecture utilisant l'appairage de réseaux VPC et l'équilibreur de charge réseau interne à stratégie directe comme saut suivant
Cette architecture est un cas d'utilisation classique pour les environnements d'entreprise, utilisant l'équilibreur de charge réseau interne à stratégie directe pour la haute disponibilité, en assoiation avec l'appairage de réseaux VPC pour l'association de segments de réseau.
Le schéma suivant montre la topologie de cette architecture.
Le schéma précédent montre un réseau VPC hub et des réseaux VPC à plusieurs réseaux VPC satellites appairés au réseau VPC hub à l'aide de l'appairage de réseaux VPC. Le réseau VPC hub contient deux instances d'un dispositif virtuel dans un groupe d'instances géré derrière un équilibreur de charge réseau interne à stratégie directe. Une route statique par défaut pointe vers l'équilibreur de charge réseau interne à stratégie directe en tant que saut suivant. Cette route statique par défaut est exportée via l'appairage de réseaux VPC à l'aide de routes personnalisées. La route par défaut vers la passerelle Internet dans les réseaux VPC satellites est supprimée.
Vous pouvez répondre aux exigences de différente manière :
- La connectivité entre les réseaux satellites est automatiquement acheminée via le pare-feu, car l'appairage de réseaux VPC est non transitif. Par conséquent, les réseaux VPC satellites ne peuvent pas échanger de données directement les uns avec les autres. Vous pouvez configurer les dispositifs virtuels pour définir les conditions et les règles d'échange de trafic des réseaux satellites.
- La connectivité à Internet n'est possible que via les dispositifs virtuels, car la route par défaut vers la passerelle Internet a été supprimée des réseaux VPC satellites. Les dispositifs virtuels disposent d'une route par défaut via une interface réseau distincte, qui peut être marquée comme non approuvée dans le cas d'un NGFW.
- La connectivité aux réseaux sur site est assurée par la connectivité d'un réseau VPC connecté au dispositif virtuel sur une interface réseau distincte. Une connexion Cloud VPN ou Cloud Interconnect se termine dans ce réseau VPC de connectivité.
- La haute disponibilité est assurée par des vérifications d'état personnalisées sur l'équilibreur de charge interne. Vous pouvez configurer les dispositifs en tant qu'actifs/passifs à l'aide du basculement pour les équilibreurs de charge réseau internes à stratégie directe. Cela permet de garantir que le trafic passe toujours par un seul dispositif virtuel.
Vous pouvez utiliser cet exemple d'architecture si la communication entre les différents réseaux VPC est TCP/UDP ou tout autre trafic de protocole. Cette approche est évolutive jusqu'à la limite des connexions d'appairage de réseaux VPC par réseau VPC.
Pour obtenir un exemple de mise en œuvre de cette architecture avec une passerelle NAT en tant que dispositif virtuel, consultez la section Déployer un réseau hub-and-spoke en utilisant un équilibreur de charge comme saut suivant. Vous pouvez utiliser le même modèle pour déployer d'autres dispositifs virtuels, comme décrit dans la section Cas d'utilisation précédente.
Cas d'utilisation particulier avec un réseau VPC partagé sur Google Cloud
Dans ce cas d'utilisation spécifique, aucun trafic entre différents réseaux VPC n'a besoin de passer par les dispositifs virtuels. Au lieu de cela, seul le trafic provenant d'un seul réseau VPC partagé est acheminé vers un environnement sur site et vers Internet. Pour mettre en œuvre ce cas d'utilisation, vous pouvez appliquer l'une des options de haute disponibilité décrites précédemment dans ce document, associée à une interface réseau, pour établir la connectivité au réseau VPC partagé, au réseau sur site et au réseau Google Cloud. Si vous souhaitez améliorer la visibilité du trafic entre les sous-réseaux sans passer par des dispositifs centralisés, la mise en miroir de paquets peut vous aider.
Le schéma suivant illustre cette topologie.
Le schéma précédent montre le trafic provenant d'un seul réseau VPC partagé acheminé vers un réseau sur site et vers Internet via un pool de dispositifs virtuels.
Mise en œuvre d'une architecture avec des dispositifs virtuels
Pour en savoir plus sur l'utilisation de l'appairage de réseaux VPC entre les segments et d'un équilibreur de charge réseau interne à stratégie directe en tant qu'option de haute disponibilité, consultez les pages suivantes : Déployer un réseau hub-and-spoke en utilisant un équilibreur de charge comme saut suivant.
Si vous souhaitez déployer un dispositif de partenaire Google Cloud depuis Cloud Marketplace), contactez votre fournisseur ou recherchez sur son site Web les instructions de déploiement de ses systèmes sur Google Cloud.
Étapes suivantes
- Bonnes pratiques et architectures de référence pour la conception de VPC
- Topologies de réseaux hybrides et multicloud
- Découvrez les bonnes pratiques de conception de réseau dans le framework d'architecture Google Cloud.
- Documentation sur les VPC
- Documentation de l'équilibreur de charge réseau interne à stratégie directe.
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.