Plusieurs projets Google Cloud, un seul VPN hybride ? Décidez d'abord

Quand plusieurs projets Google Cloud ont besoin d'un accès hybride, le réflexe est un VPN par projet, et c'est presque toujours la mauvaise forme. La propriété du projet et le routage des paquets sont des sujets liés mais différents, et l'architecture utile conserve les frontières administratives dont vous avez besoin tout en donnant aux préfixes prévus un chemin délibéré vers le bureau ou le centre de données. Ces vérifications décident quel modèle de réseau vous voulez réellement, dans l'ordre qui évite la reprise. Chacune peut clore la discussion tôt, et c'est le but.

Une frontière de projet n'exige pas automatiquement son propre tunnel.

Vérifiez si l'objet partagé est le réseau

Commencez par une question de propriété, pas de connectivité : la propriété centrale du réseau peut-elle soutenir ces charges de travail ? Si la réponse est oui et que l'organisation dispose d'une configuration éligible, un projet hôte possède le VPC, les sous-réseaux et la connectivité, tandis que les projets de service possèdent leurs ressources applicatives. Une connexion Cloud VPN dans ce réseau partagé peut alors desservir les préfixes de charge de travail prévus, sous réserve des politiques de routage et de sécurité .

Soyez précis sur ce que fait l'association. Attacher un projet de service ne fusionne pas son VPC indépendant existant avec le réseau hôte, et ne déplace pas chaque ressource automatiquement. Le rattachement des charges de travail, les autorisations, l'espace d'adressage et le DNS font partie de l'architecture, pas des conséquences du réglage. Lisez l'association d'abord comme un changement d'autorisations, ensuite comme un changement de routage, car les équipes découvrent généralement la différence lors de la bascule.

Si la propriété centrale n'est pas acceptable pour les équipes concernées, arrêtez-vous ici et traitez le reste comme une conception de peering ou de hub. Imposer Shared VPC à un groupe qui a besoin de cycles de vie réseau indépendants produit un problème politique au nom technique.

Vérifiez si des VPC indépendants peuvent le rester

Le peering préserve des VPC distincts, et c'est précisément pourquoi il attire les équipes qui veulent leurs propres plans d'adressage et leur propre contrôle des changements. Le piège est que le peering n'est pas transitif : un peering A-vers-B et B-vers-C ne crée pas à lui seul un routage A-vers-C via B. Si trois projets doivent atteindre une destination hybride, il vous faut un plan d'échange délibéré plutôt qu'une chaîne de peerings.

Le partage de la joignabilité hybride dépend aussi de l'échange documenté de routes personnalisées et des annonces Cloud Router prévues. Un état de peering actif prouve que le peering existe, pas que les préfixes qui importent à chaque côté ont jamais été exportés. Vérifiez les plages exportées des deux côtés du pair, dans la configuration qui effectue l'export, et comparez-les aux adresses que vos charges de travail utilisent réellement. Une incohérence à cet endroit est la raison la plus courante pour qu'un peering paraisse sain alors qu'un préfixe reste injoignable.

Écrivez le plan d'adressage avant tout le reste. Les plages qui ne se chevauchent pas, les routes vers chaque destination prévue et les annonces de retour sont les trois artefacts dont ce modèle vit ou meurt.

Vérifiez si un modèle de hub convient à la topologie

Pour une conception plus vaste ou segmentée différemment, la présentation de Google Network Connectivity Center décrit les modèles en hub et en étoile. Lisez-la pour ce que la version actuelle prend en charge, et non pour ce que le schéma suggère : quelles combinaisons de VPC et d'hybride, quelles familles de routes et quelles politiques chaque type de branche autorise.

Vérifiez la famille d'adresses explicitement. Les exemples de planification de la plupart des guides, y compris celui-ci, concernent IPv4, et une fonctionnalité qui existe pour un type de branche ne s'applique pas automatiquement sans changement à un autre. Si votre environnement est en double pile, cette question relève du choix du modèle, pas d'une migration ultérieure.

Le tableau ci-dessous est le récapitulatif des trois modèles et de la question qui décide chacun.

Vérifiez ce que le routage n'accorde pas

L'échange de routes n'est pas une concession globale de confiance. La résolution DNS, l'autorisation du pare-feu et l'autorisation applicative restent leurs propres responsabilités, et chacune est configurée par un propriétaire différent dans la plupart des organisations. Une conception qui suppose que la joignabilité implique l'autorisation passera son test de connectivité et échouera à sa revue de sécurité.

Confirmez aussi l'histoire DNS pour chaque modèle, car les arrangements de zone et de transfert diffèrent entre un réseau partagé et des réseaux appairés. Les noms privés qui se résolvent dans un projet ne suivent pas une route vers un autre.

Consignez la décision et son propriétaire

Centralisez là où l'organisation veut un propriétaire de réseau partagé ; gardez des VPC séparés là où le cycle de vie ou la politique l'exige. Choisissez ensuite une relation de connectivité prise en charge et notez laquelle vous avez choisie, qui possède le réseau partagé et ce que chaque projet est autorisé à annoncer.

Compter les projets et acheter un VPN pour chacun ne remplace pas cette décision de propriété. C'est la même décision, prise plus tard, par celui qui hérite de la facture et de la table de routage.