La mise en réseau est nécessaire pour que les ressources puissent communiquer au sein de votre organisation Google Cloud et entre votre environnement cloud et votre environnement sur site. Cette section décrit la structure du plan pour les réseaux VPC, l'espace d'adresses IP, les DNS, les règles de pare-feu et la connectivité à l'environnement sur site.
Topologie du réseau
Le dépôt de plans fournit les options suivantes pour votre topologie de réseau:
- Utilisez des réseaux VPC partagés distincts pour chaque environnement, sans aucun trafic réseau directement autorisé entre les environnements.
- Utilisez un modèle hub et spoke qui ajoute un réseau hub pour connecter chaque environnement dans Google Cloud, avec le trafic réseau entre les environnements contrôlés par un dispositif virtuel de réseau (NVA).
Choisissez la topologie du réseau VPC partagé double lorsque vous ne souhaitez pas de connectivité réseau directe entre les environnements. Choisissez la topologie du réseau hub et spoke lorsque vous souhaitez autoriser la connectivité réseau entre les environnements filtrés par un dispositif virtuel de réseau, par exemple lorsque vous utilisez des outils existants nécessitant un chemin de réseau direct à chaque serveur de votre environnement.
Les deux topologies utilisent le VPC partagé comme construction de réseau principale, car le VPC partagé permet une séparation claire des responsabilités. Les administrateurs réseau gèrent les ressources réseau dans un projet hôte centralisé, et les équipes de charge de travail déploient leurs propres ressources d'application et consomment les ressources réseau dans les projets de service associés au projet hôte.
Les deux topologies incluent une version de base et une version restreinte de chaque réseau VPC. Le réseau VPC de base est utilisé pour les ressources contenant des données non sensibles, et le réseau VPC restreint est utilisé pour les ressources contenant des données sensibles nécessitant VPC Service Controls. Pour en savoir plus sur la mise en œuvre de VPC Service Controls, consultez la page Protéger vos ressources avec VPC Service Controls.
Topologie d'un réseau VPC partagé double
Si vous avez besoin d'une isolation réseau entre vos réseaux de développement, hors production et de production sur Google Cloud, nous vous recommandons la topologie de réseau VPC partagé double. Cette topologie utilise des réseaux VPC partagés distincts pour chaque environnement, chaque environnement étant également divisé entre un réseau VPC partagé de base et un réseau VPC partagé restreint.
Le schéma suivant illustre la topologie de réseau VPC partagé double.
Le schéma décrit les concepts clés suivants de la topologie de VPC partagé double:
- Chaque environnement (production, hors production et développement) dispose d'un réseau VPC partagé pour le réseau de base et d'un réseau VPC partagé pour le réseau restreint. Ce schéma n'affiche que l'environnement de production, mais le même schéma est répété pour chaque environnement.
- Chaque réseau VPC partagé comporte deux sous-réseaux, chaque sous-réseau situé dans une région différente.
- La connectivité avec les ressources sur site est activée via quatre rattachements de VLAN à l'instance Dedicated Interconnect pour chaque réseau VPC partagé, à l'aide de quatre services Cloud Router (deux dans chaque région pour la redondance). Pour en savoir plus, consultez la page Connectivité hybride entre l'environnement sur site et Google Cloud.
De par sa conception, cette topologie ne permet pas au trafic réseau de circuler directement entre les environnements. Si vous avez besoin que le trafic réseau circule directement entre les environnements, vous devez prendre des mesures supplémentaires pour autoriser ce chemin de réseau. Par exemple, vous pouvez configurer les points de terminaison Private Service Connect pour exposer un service d'un réseau VPC sur un autre réseau VPC. Vous pouvez également configurer votre réseau sur site pour permettre au trafic de circuler d'un environnement Google Cloud vers l'environnement sur site, puis vers un autre environnement Google Cloud.
Topologie de réseau hub et spoke
Si vous déployez dans Google Cloud des ressources qui nécessitent un chemin d'accès réseau direct vers des ressources situées dans plusieurs environnements, nous vous recommandons d'utiliser la topologie de réseau hub-and-spoke.
La topologie hub et spoke utilise plusieurs concepts de la topologie de VPC partagé double, mais modifie la topologie pour ajouter un réseau hub. Le schéma suivant illustre la topologie hub et spoke.
Le schéma décrit les concepts clés suivants de la topologie de réseau hub-and-spoke:
- Ce modèle ajoute un réseau hub et chacun des réseaux de développement, hors production et de production (spokes) est connecté au réseau hub via l'appairage de réseaux VPC. Si vous prévoyez de dépasser la limite de quota, vous pouvez également utiliser une passerelle VPN haute disponibilité.
- La connectivité aux réseaux sur site n'est autorisée que via le réseau hub. Tous les réseaux spokes peuvent communiquer avec les ressources partagées du réseau hub et utiliser ce chemin pour se connecter aux réseaux sur site.
- Les réseaux hubs incluent un dispositif virtuel de réseau pour chaque région, déployé de manière redondante derrière des instances d'équilibreur de charge réseau interne. Ce dispositif virtuel de réseau sert de passerelle pour autoriser ou refuser le trafic entre les réseaux spokes.
- Le réseau hub héberge également des outils qui nécessitent une connectivité à tous les autres réseaux. Par exemple, vous pouvez déployer des outils sur des instances de VM pour gérer la configuration dans l'environnement commun.
- Le modèle hub et spoke est dupliqué pour une version de base et une version restreinte de chaque réseau.
Pour activer le trafic de spoke à spoke, le plan déploie les NVA sur le réseau VPC partagé hub agissant comme des passerelles entre les réseaux. Les routes sont échangées à partir de réseaux VPC hub vers des réseaux VPC spoke via un échange de routes personnalisées. Dans ce scénario, la connectivité entre les spokes doit être acheminée via le NVIDIA, car l'appairage de réseaux VPC est non transitif. Par conséquent, les réseaux VPC spoke ne peuvent pas échanger de données directement entre eux. Vous devez configurer les dispositifs virtuels pour autoriser de manière sélective le trafic entre les spokes.
Modèles de déploiement de projets
Lorsque vous créez des projets pour des charges de travail, vous devez décider de la façon dont les ressources de ce projet se connectent à votre réseau existant. Le tableau suivant décrit les modèles de déploiement des projets utilisés dans le plan.
| Modèle | Description | Exemple d'utilisation |
|---|---|---|
| Projets de base partagés | Ces projets sont configurés en tant que projets de service dans un projet hôte de VPC partagé de base. Utilisez ce modèle lorsque les ressources de votre projet répondent aux critères suivants:
|
example_base_shared_vpc_project.tf |
| Projets partagés restreints | Ces projets sont configurés en tant que projets de service dans un projet hôte de VPC partagé restreint. Utilisez ce modèle lorsque les ressources de votre projet répondent aux critères suivants :
|
example_restricted_shared_vpc_project.tf |
| Projets flottants | Les projets flottants ne sont pas connectés à d'autres réseaux VPC dans votre topologie. Utilisez ce modèle lorsque les ressources de votre projet répondent aux critères suivants :
Imaginons que vous souhaitiez séparer le réseau VPC d'un projet flottant de la topologie du réseau VPC principale, tout en exposant un nombre limité de points de terminaison entre les réseaux. Dans ce cas, publiez des services à l'aide de Private Service Connect pour partager l'accès réseau à un point de terminaison individuel sur plusieurs réseaux VPC, sans exposer l'ensemble du réseau. |
example_floating_project.tf |
| Projets d'appairage | Les projets d'appairage créent leurs propres réseaux VPC et s'appairent à d'autres réseaux VPC dans votre topologie. Utilisez ce modèle lorsque les ressources de votre projet répondent aux critères suivants :
Si vous créez des projets d'appairage, vous êtes tenu d'allouer des plages d'adresses IP non conflictuelles et de planifier le quota des groupes d'appairage. |
example_peering_project.tf |
Attribution d'adresses IP
Cette section explique comment l'architecture du plan alloue des plages d'adresses IP. Vous devrez peut-être modifier les plages d'adresses IP spécifiques utilisées en fonction de la disponibilité des adresses IP dans votre environnement hybride existant.
Le tableau suivant fournit la répartition de l'espace d'adressage IP alloué au plan. L'environnement hub ne s'applique que dans la topologie hub et spoke.
| Objectif | Type de VPC | Région | Environnement hub | Environnement de développement | Environnement hors production | Environnement de production |
|---|---|---|---|---|---|---|
| Plages de sous-réseaux principales | Base | Région 1 | 10.0.0.0/18 | 10.0.64.0/18 | 10.0.128.0/18 | 10.0.192.0/18 |
| Région 2 | 10.1.0.0/18 | 10.1.64.0/18 | 10.1.128.0/18 | 10.1.192.0/18 | ||
| Non allouées | 10.{2-7}.0.0/18 | 10.{2-7}.64.0/18 | 10.{2-7}.128.0/18 | 10.{2-7}.192.0/18 | ||
| Limité | Région 1 | 10.8.0.0/18 | 10.8.64.0/18 | 10.8.128.0/18 | 10.8.192.0/18 | |
| Région 2 | 10.9.0.0/18 | 10.9.64.0/18 | 10.9.128.0/18 | 10.9.192.0/18 | ||
| Non allouées | 10.{10-15}.0.0/18 | 10.{10-15}.64.0/18 | 10.{10-15}.128.0/18 | 10.{10-15}.192.0/18 | ||
| Accès aux services privés | Base | Global | 10.16.0.0/21 | 10.16.8.0/21 | 10.16.16.0/21 | 10.16.24.0/21 |
| Limité | Global | 10.16.32.0/21 | 10.16.40.0/21 | 10.16.48.0/21 | 10.16.56.0/21 | |
| Points de terminaison Private Service Connect | Base | Global | 10.17.0.1/32 | 10.17.0.2/32 | 10.17.0.3/32 | 10.17.0.4/32 |
| Limité | Global | 10.17.0.5/32 | 10.17.0.6/32 | 10.17.0.7/32 | 10.17.0.8/32 | |
| Sous-réseaux proxy réservés | Base | Région 1 | 10.18.0.0/23 | 10.18.2.0/23 | 10.18.4.0/23 | 10.18.6.0/23 |
| Région 2 | 10.19.0.0/23 | 10.19.2.0/23 | 10.19.4.0/23 | 10.19.6.0/23 | ||
| Non allouées | 10.{20-25}.0.0/23 | 10.{20-25}.2.0/23 | 10.{20-25}.4.0/23 | 10.{20-25}.6.0/23 | ||
| Limité | Région 1 | 10.26.0.0/23 | 10.26.2.0/23 | 10.26.4.0/23 | 10.26.6.0/23 | |
| Région 2 | 10.27.0.0/23 | 10.27.2.0/23 | 10.27.4.0/23 | 10.27.6.0/23 | ||
| Non allouées | 10.{28-33}.0.0/23 | 10.{28-33}.2.0/23 | 10.{28-33}.4.0/23 | 10.{28-33}.6.0/23 | ||
| Plages de sous-réseaux secondaires | Base | Région 1 | 100.64.0.0/18 | 100.64.64.0/18 | 100.64.128.0/18 | 100.64.192.0/18 |
| Région 2 | 100.65.0.0/18 | 100.65.64.0/18 | 100.65.128.0/18 | 100.65.192.0/18 | ||
| Non allouées | 100.{66-71}.0.0/18 | 100.{66-71}.64.0/18 | 100.{66-71}.128.0/18 | 100.{66-71}.192.0/18 | ||
| Limité | Région 1 | 100.72.0.0/18 | 100.72.64.0/18 | 100.72.128.0/18 | 100.72.192.0/18 | |
| Région 2 | 100.73.0.0/18 | 100.73.64.0/18 | 100.73.128.0/18 | 100.73.192.0/18 | ||
| Non allouées | 100.{74-79}.0.0/18 | 100.{74-79}.64.0/18 | 100.{74-79}.128.0/18 | 100.{74-79}.192.0/18 |
Le tableau précédent illustre ces concepts pour l'allocation de plages d'adresses IP:
- L'allocation d'adresses IP est subdivisée en plages pour chaque combinaison de VPC partagé de base, de VPC partagé restreint, de région et d'environnement.
- Certaines ressources sont globales et ne nécessitent pas de subdivision pour chaque région.
- Par défaut, pour les ressources régionales, le plan est déployé dans deux régions. En outre, il existe des plages d'adresses IP inutilisées que vous pouvez développer dans six régions supplémentaires.
- Le réseau hub n'est utilisé que dans la topologie de réseau hub-and-spoke, tandis que les environnements de développement, hors production et de production sont utilisés dans les deux topologies de réseau.
Le tableau suivant explique comment chaque type de plage d'adresses IP est utilisé.
| Objectif | Description |
|---|---|
| Plages de sous-réseaux principales | Les ressources que vous déployez sur votre réseau VPC, telles que les instances de machine virtuelle, utilisent des adresses IP internes provenant de ces plages. |
| Accès aux services privés | Certains services Google Cloud tels que Cloud SQL nécessitent la pré-allocation d'une plage de sous-réseaux pour l'accès aux services privés. Le plan réserve une plage /21 pour chacun des réseaux VPC partagés à l'échelle mondiale, afin d'allouer des adresses IP aux services qui nécessitent un accès aux services privés. Lorsque vous créez un service qui dépend de l'accès aux services privés, vous allouez un sous-réseau /24 régional à partir de la plage /21 réservée. |
| Private Service Connect | Le plan provisionne chaque réseau VPC avec un point de terminaison Private Service Connect pour communiquer avec les API Google Cloud. Ce point de terminaison permet à vos ressources du réseau VPC d'atteindre les API Google Cloud sans s'appuyer sur le trafic sortant vers les plages Internet ou les plages Internet annoncées publiquement. |
| Équilibreurs de charge basés sur un proxy | Certains types d'équilibreurs de charge d'application nécessitent la pré-allocation de sous-réseaux proxy réservés. Bien que le plan ne déploie pas d'équilibreurs de charge d'application qui nécessitent cette plage, l'allocation préalable de plages permet de réduire les frictions des charges de travail lorsqu'elles doivent demander une nouvelle plage de sous-réseau pour activer certaines ressources d'équilibreurs de charge. |
| Plages de sous-réseaux secondaires | Certains cas d'utilisation, tels que les charges de travail basées sur des conteneurs, nécessitent des plages secondaires. Le plan alloue des plages de l'espace d'adresses IP RFC 6598 pour les plages secondaires. |
Configuration DNS centralisée
Pour la résolution DNS entre les environnements Google Cloud et sur site, nous vous recommandons d'utiliser une approche hybride avec deux systèmes DNS faisant autorité. Dans cette approche, Cloud DNS gère la résolution DNS faisant autorité pour votre environnement Google Cloud, et vos serveurs DNS sur site existants gèrent la résolution DNS faisant autorité pour les ressources sur site. Votre environnement sur site et votre environnement Google Cloud effectuent des résolutions DNS entre les environnements via des requêtes de transfert.
Le schéma suivant illustre la topologie DNS sur les différents réseaux VPC utilisés dans le plan.
Le schéma décrit les composants suivants de la conception DNS déployée par le plan:
- Le projet de hub DNS dans le dossier commun est le point central de l'échange DNS entre l'environnement sur site et l'environnement Google Cloud. Le transfert DNS utilise les instances d'interconnexion dédiée et les routeurs cloud déjà configurés dans votre topologie de réseau.
- Dans la topologie à VPC partagé double, le hub DNS utilise le réseau VPC partagé de production partagé de base.
- Dans la topologie hub et spoke, le hub DNS utilise le réseau VPC partagé hub de base.
- Les serveurs de chaque réseau VPC partagé peuvent résoudre les enregistrements DNS d'autres réseaux VPC partagés via le transfert DNS, qui est configuré entre Cloud DNS dans chaque projet hôte de VPC partagé et le hub DNS.
- Les serveurs sur site peuvent résoudre les enregistrements DNS dans les environnements Google Cloud à l'aide de règles de serveur DNS qui autorisent les requêtes depuis des serveurs sur site. Le plan configure une règle de serveur entrant dans le hub DNS pour allouer des adresses IP, et les serveurs DNS sur site transfèrent les requêtes vers ces adresses. Toutes les requêtes DNS adressées à Google Cloud atteignent d'abord le hub DNS, qui résout ensuite les enregistrements des pairs DNS.
- Les serveurs Google Cloud peuvent résoudre les enregistrements DNS dans l'environnement sur site à l'aide de zones de transfert qui interrogent les serveurs sur site. Toutes les requêtes DNS adressées à l'environnement sur site proviennent du hub DNS. La source de la requête DNS est 35.199.192.0/19.
Stratégies de pare-feu
Google Cloud propose plusieurs types de stratégies de pare-feu. Les stratégies de pare-feu hiérarchiques sont appliquées au niveau de l'organisation ou du dossier pour hériter des règles de stratégie de pare-feu de manière cohérente sur toutes les ressources de la hiérarchie. En outre, vous pouvez configurer des stratégies de pare-feu réseau pour chaque réseau VPC. Le plan combine ces stratégies de pare-feu pour appliquer des configurations communes à tous les environnements à l'aide de stratégies de pare-feu hiérarchiques et pour appliquer des configurations plus spécifiques à chaque réseau VPC individuel à l'aide de stratégies de pare-feu de réseau.
Le plan n'utilise pas les anciennes règles de pare-feu VPC. Nous vous recommandons de n'utiliser que des stratégies de pare-feu et d'éviter de mélanger l'utilisation avec les anciennes règles de pare-feu VPC.
Stratégies de pare-feu hiérarchiques
Le plan définit une stratégie de pare-feu hiérarchique unique et l'associe à chacun des dossiers de production, hors production, de développement, d'amorçage et courants. Cette stratégie de pare-feu hiérarchique contient les règles qui doivent être appliquées de manière générale à tous les environnements et délègue l'évaluation de règles plus précises à la stratégie de pare-feu réseau pour chaque environnement individuel.
Le tableau suivant décrit les règles de stratégies de pare-feu hiérarchiques déployées par le plan.
| Description de la règle | Sens du trafic | Filtre (plage IPv4) | Protocoles et ports | Action |
|---|---|---|---|---|
| Déléguer l'évaluation du trafic entrant de la RFC 1918 à des niveaux inférieurs de la hiérarchie. | Ingress |
192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 |
all |
Go to next |
| Déléguer l'évaluation du trafic sortant à la norme RFC 1918 à des niveaux inférieurs de la hiérarchie | Egress |
192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 |
all |
Go to next |
| IAP pour le transfert TCP | Ingress |
35.235.240.0/20 |
tcp:22,3390 |
Allow |
| Activation de Windows Server | Egress |
35.190.247.13/32 |
tcp:1688 |
Allow |
| Vérifications d'état pour Cloud Load Balancing. | Ingress |
130.211.0.0/22, 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22 |
tcp:80,443 |
Allow |
Stratégies de pare-feu réseau
Le plan configure une stratégie de pare-feu réseau pour chaque réseau. Chaque stratégie de pare-feu réseau commence par un ensemble minimal de règles qui autorisent l'accès aux services Google Cloud et refusent la sortie vers toutes les autres adresses IP.
Dans le modèle hub et spoke, les stratégies de pare-feu réseau contiennent des règles supplémentaires pour autoriser la communication entre les spokes. La stratégie de pare-feu réseau autorise le trafic sortant de l'un vers le hub ou un autre spoke, et autorise le trafic entrant depuis le NVA sur le réseau hub.
Le tableau suivant décrit les règles de la stratégie de pare-feu de réseau au niveau mondial déployées pour chaque réseau VPC du plan.
| Description de la règle | Sens du trafic | Filtre | Protocoles et ports |
|---|---|---|---|
| Autorise le trafic sortant vers les API Google Cloud. | Egress |
Point de terminaison Private Service Connect configuré pour chaque réseau individuel. Consultez la section Accès privé aux API Google. | tcp:443 |
| Refusez le trafic sortant ne correspondant pas à d'autres règles. | Egress |
tous | all |
Autorisez le trafic sortant d'un spoke à un autre spoke (pour le modèle hub et spoke uniquement). |
Egress |
Agrégation de toutes les adresses IP utilisées dans la topologie hub et spoke. Le trafic quittant un VPC spoke est d'abord acheminé vers le NVA dans le réseau hub. | all |
Autorisez le trafic entrant vers un spoke du dispositif virtuel de réseau dans le réseau hub (pour le modèle hub et spoke uniquement). |
Ingress |
Trafic provenant des dispositifs virtuels de réseau du réseau hub. | all |
Lorsque vous déployez le plan pour la première fois, une instance de VM dans un réseau VPC peut communiquer avec les services Google Cloud, mais pas vers d'autres ressources d'infrastructure du même réseau VPC. Pour autoriser les instances de VM à communiquer, vous devez ajouter des règles supplémentaires à votre stratégie de pare-feu réseau et des tags qui autorisent explicitement les instances de VM à communiquer. Les tags sont ajoutés aux instances de VM et le trafic est évalué en fonction de ces tags. Les tags disposent également de contrôles IAM afin que vous puissiez les définir de manière centralisée et déléguer leur utilisation à d'autres équipes.
Le schéma suivant montre comment ajouter des tags personnalisés et des règles de stratégie de pare-feu réseau pour permettre aux charges de travail de communiquer au sein d'un réseau VPC.
Le diagramme illustre les concepts suivants de cet exemple:
- La stratégie de pare-feu réseau contient la règle 1 qui refuse le trafic sortant de toutes les sources avec la priorité 65530.
- La stratégie de pare-feu réseau contient la règle 2 qui autorise le trafic entrant provenant d'instances portant le tag
service=frontendvers des instances dotées du tagservice=backendavec la priorité 999. - La VM instance-2 peut recevoir du trafic provenant de l'instance-1, car ce trafic correspond aux tags autorisés par la règle 2. La règle 2 est mise en correspondance avant l'évaluation de la règle 1, en fonction de la valeur de priorité.
- La VM instance-3 ne reçoit pas de trafic. La seule règle de stratégie de pare-feu qui correspond à ce trafic est la règle 1. Le trafic sortant de l'instance-1 est donc refusé.
Accès privé aux API Google Cloud
Pour permettre aux ressources de vos réseaux VPC ou de votre environnement sur site d'accéder aux services Google Cloud, nous vous recommandons d'utiliser une connectivité privée plutôt que le trafic Internet sortant vers les points de terminaison d'API publiques. Le plan configure l'accès privé à Google sur chaque sous-réseau et crée des points de terminaison internes avec Private Service Connect pour communiquer avec les services Google Cloud. Utilisés conjointement, ces contrôles permettent d'utiliser un chemin privé vers des services Google Cloud sans s'appuyer sur le trafic sortant Internet ou les plages Internet annoncées publiquement.
Le plan configure les points de terminaison Private Service Connect avec des groupes d'API pour différencier les services accessibles sur chaque réseau. Le réseau de base utilise le groupe all-apis et peut atteindre n'importe quel service Google, et le réseau restreint utilise le groupe vpcsc qui permet d'accéder à un ensemble limité de services qui est compatible avec VPC Service Controls.
Pour accéder aux hôtes situés dans un environnement sur site, nous vous recommandons d'utiliser une convention de nom de domaine complet personnalisé pour chaque point de terminaison, comme décrit dans le tableau suivant. Le plan utilise un point de terminaison Private Service Connect unique pour chaque réseau VPC, configuré pour accéder à un ensemble différent de groupes d'API. Par conséquent, vous devez déterminer comment acheminer le trafic du service depuis l'environnement sur site vers le réseau VPC avec le point de terminaison de l'API approprié et, si vous utilisez VPC Service Controls, assurez-vous que ce trafic vers les services Google Cloud atteigne le point de terminaison dans le périmètre prévu. Configurez vos contrôles sur site pour DNS, pare-feu et routeurs afin d'autoriser l'accès à ces points de terminaison et configurez les hôtes sur site pour utiliser le point de terminaison approprié. Pour plus d'informations, consultez la page Accéder aux API Google via des points de terminaison.
Le tableau suivant décrit les points de terminaison Private Service Connect créés pour chaque réseau.
| VPC | Environnement | Bundle d'API | Adresse IP du point de terminaison Private Service Connect | Nom de domaine complet personnalisé | ||||
|---|---|---|---|---|---|---|---|---|
| Base | Courant | all-apis |
10.17.0.1/32 | c.private.googleapis.com |
||||
| Développement | all-apis |
10.17.0.2/32 | d.private.googleapis.com |
|||||
| Hors production | all-apis |
10.17.0.3/32 | n.private.googleapis.com |
|||||
| Production | all-apis |
10.17.0.4/32 | p.private.googleapis.com |
|||||
| Limité | Courant | vpcsc |
10.17.0.5/32 | c.restricted.googleapis.com |
||||
| Développement | vpcsc |
10.17.0.6/32 | d.restricted.googleapis.com |
|||||
| Hors production | vpcsc |
10.17.0.7/32 | n.restricted.googleapis.com |
|||||
| Production | vpcsc |
10.17.0.8/32 | p.restricted.googleapis.com |
|||||
Pour garantir que le trafic des services Google Cloud dispose d'une résolution DNS vers le point de terminaison approprié, le plan configure les zones DNS privées pour chaque réseau VPC. Le tableau suivant décrit ces zones DNS privées.
| Nom de zone privée | Nom DNS | Type d'enregistrement | Données |
|---|---|---|---|
googleapis.com. |
*.googleapis.com. |
CNAME |
private.googleapis.com. (pour les réseaux de base) ou restricted.googleapis.com. (pour les réseaux restreints) |
private.googleapis.com (pour les réseaux de base) ou restricted.googleapis.com (pour les réseaux restreints) |
A |
Adresse IP du point de terminaison Private Service Connect pour ce réseau VPC. | |
gcr.io. |
*.gcr.io |
CNAME |
gcr.io. |
gcr.io |
A |
Adresse IP du point de terminaison Private Service Connect pour ce réseau VPC. | |
pkg.dev. |
*.pkg.dev. |
CNAME |
pkg.dev. |
pkg.dev. |
A |
Adresse IP du point de terminaison Private Service Connect pour ce réseau VPC. |
Le plan contient des configurations supplémentaires pour s'assurer que ces points de terminaison Private Service Connect sont utilisés de manière cohérente. Chaque réseau VPC partagé applique également les éléments suivants:
- Règle de stratégie de pare-feu réseau qui autorise le trafic sortant de toutes les sources vers l'adresse IP du point de terminaison Private Service Connect sur TCP:443.
- Une règle de stratégie de pare-feu réseau qui refuse le trafic sortant à 0.0.0.0/0, ce qui inclut les domaines par défaut utilisés pour accéder aux services Google Cloud.
Connectivité Internet
Le plan n'autorise pas le trafic entrant ou sortant entre ses réseaux VPC et Internet. Pour les charges de travail nécessitant une connectivité Internet, vous devez prendre des mesures supplémentaires pour concevoir les chemins d'accès requis.
Pour les charges de travail nécessitant du trafic sortant vers Internet, nous vous recommandons de gérer le trafic sortant via Cloud NAT afin d'autoriser le trafic sortant sans connexion entrante non sollicitée, ou via un proxy Web sécurisé pour un contrôle plus précis de l'autorisation du trafic sortant vers des services Web de confiance uniquement.
Pour les charges de travail nécessitant le trafic entrant provenant d'Internet, nous vous recommandons de concevoir votre charge de travail avec Cloud Load Balancing et Google Cloud Armor pour bénéficier des protections DDoS et WAF.
Nous vous déconseillons de concevoir des charges de travail permettant une connectivité directe entre Internet et une VM via une adresse IP externe sur la VM.
Connectivité hybride entre un environnement sur site et Google Cloud
Pour établir la connectivité entre l'environnement sur site et Google Cloud, nous vous recommandons d'utiliser Dedicated Interconnect afin d'optimiser la sécurité et la fiabilité. Une connexion Dedicated Interconnect est une liaison directe entre le réseau sur site et Google Cloud.
Le schéma suivant illustre la connectivité hybride entre l'environnement sur site et un réseau cloud privé virtuel Google.
Le schéma décrit les composants suivants du modèle pour une disponibilité de 99,99% pour l'interconnexion dédiée:
- Quatre connexions Dedicated Interconnect, avec deux connexions dans une zone métropolitaine (agglomération) et deux connexions dans une autre. Dans chaque zone métropolitaine, il existe deux zones distinctes dans l'installation hébergée en colocation.
- Les connexions sont divisées en deux paires, chaque paire étant connectée à un centre de données sur site distinct.
- Les rattachements de VLAN permettent de connecter chaque instance Dedicated Interconnect aux routeurs Cloud Router associés à la topologie de VPC partagé.
- Chaque réseau VPC partagé possède quatre routeurs cloud, deux dans chaque région, avec le mode de routage dynamique défini sur
globalafin que chaque routeur cloud puisse annoncer tous les sous-réseaux, indépendamment de la région.
Le routage dynamique mondial permet au Cloud Router de diffuser des routages vers l'ensemble des sous-réseaux du réseau VPC. Cloud Router diffuse les routages vers des sous-réseaux distants (sous-réseaux situés en dehors de la région du routeur cloud) avec une priorité inférieure à celle des sous-réseaux locaux (sous-réseaux situés dans la région du routeur cloud). Vous pouvez éventuellement modifier les préfixes et les priorités annoncés lorsque vous configurez la session BGP pour un routeur Cloud Router.
Le trafic depuis Google Cloud vers un environnement sur site utilise le routeur Cloud Router le plus proche des ressources cloud. Dans une même région, plusieurs routes vers des réseaux sur site ont la même valeur de discriminateur multisortie (MED), et Google Cloud utilise le routage ECMP (Equal Cost Multi-Path) pour distribuer le trafic sortant entre toutes les routes possibles.
Modifications de la configuration sur site
Pour configurer la connectivité entre l'environnement sur site et Google Cloud, vous devez configurer des modifications supplémentaires dans votre environnement sur site. Le code Terraform du plan configure automatiquement les ressources Google Cloud, mais ne modifie aucune de vos ressources réseau sur site.
Certains composants de la connectivité hybride de votre environnement sur site vers Google Cloud sont automatiquement activés par le plan, y compris les suivants:
- Cloud DNS est configuré avec un transfert DNS entre tous les réseaux VPC partagés vers un seul hub, comme décrit dans la section Configuration DNS. Une règle de serveur Cloud DNS est configurée avec des adresses IP de redirecteur entrant.
- Cloud Router est configuré pour exporter les routes de tous les sous-réseaux et les routes personnalisées pour les adresses IP utilisées par les points de terminaison Private Service Connect.
Pour activer la connectivité hybride, vous devez effectuer les étapes supplémentaires suivantes:
- Commandez une connexion Dedicated Interconnect.
- Configurez les routeurs et les pare-feu sur site pour autoriser le trafic sortant vers l'espace d'adressage IP interne défini dans la section Allocation d'espace d'adressage IP.
- Configurez vos serveurs DNS sur site pour transférer les résolutions DNS associées à Google Cloud vers les adresses IP du redirecteur entrant déjà configurées par le plan.
- Configurez vos serveurs DNS, vos pare-feu et vos routeurs sur site pour accepter les requêtes DNS provenant de la zone de transfert Cloud DNS (35.199.192.0/19).
- Configurez les serveurs DNS sur site pour répondre aux requêtes des hôtes sur site vers les services Google Cloud avec les adresses IP définies dans l'accès privé aux API Cloud.
- Pour le chiffrement en transit sur la connexion Dedicated Interconnect, configurez MACsec pour Cloud Interconnect ou le VPN haute disponibilité sur Cloud Interconnect pour le chiffrement IPsec.
Pour plus d'informations, consultez la section Accès privé à Google pour les hôtes sur site.
Étapes suivantes
- Découvrez les contrôles de détection (document suivant de cette série).