Veuillez supporter avec moi alors que mes antécédents sont le développement et non Sysadmin. La mise en réseau est quelque chose que j'apprends alors que je vais et pourquoi j'écris ici :)
Il y a quelques mois, j'ai commencé le processus de conception de la structure du réseau de notre nuage. Après quelques échanges ici, je m'inspirai d'avoir un projet qui accueillera un tunnel VPN aux ressources sur site et d'autres projets qui hébergeront nos produits une fois qu'ils sont déplacés des serveurs sur site.
Tout est bon et j'ai réussi à régler les choses.
Maintenant, l'un des projets est dédié à "Stockage": cela signifie, pour nous, des bases de données, des godets pour que les données statistes soient accessibles autour, etc.
J'ai créé une première base de données MySQL (2nd gen) pour commencer à tester et remarqua que la seule option disponible pour accéder aux bases de données SQL à partir d'IPS interne était avec le sous-réseau "Projet parent".
J'ai réalisé que le moteur SQL crée un sous-réseau dédié pour cela. Il est écrit dans la documentation aussi bien, stupide moi. Pas de problème, je le déchire, activez la connexion de service privé, créez une gamme IP allouée dans la gestion VPC et définissez-la sur les itinéraires d'exportation.
Puis je suis retourné au moteur SQL a créé une nouvelle base de données. Comme prévu, le nouveau a eu la propriété intellectuelle attribuée à la plage IP allouée configurée précédemment.
Maintenant, je m'attendais à ce que chaque réseau d'argent soit capable de voir le sous-réseau SQL aussi bien mais apparemment pas. Encore une fois, vous avez une oie stupide. Il a été écrit là aussi.
J'ai activé un abonnement de support de bronze avec GCP pour avoir des conseils, mais ce que j'ai eu était une "création d'un tunnel VPN entre les deux projets" qui m'a laissé un peu déçu car le concept de VPC en pair est si bon.
Mais de toute façon, faisons cela alors.
J'ai créé un tunnel pointant vers une passerelle sur le projet qui aura des clusters K8S et vice-versa.
Le tableau de bord me dit que le tunnel est établi mais apparemment, il y a un problème avec les paramètres À ce stade, je cherche quelque chose de lié à BGP, mais tout ce que je peux trouver, c'est comment cela fonctionne en théorie, ce qu'il est utilisé, qui sont les numéros ASM réservés, etc.
J'ai vraiment besoin de quelqu'un pour souligner l'évidence et me dire ce que j'ai foutu ici, alors:
Il s'agit du tunnel VPN sur les projets qui héberge les bases de données:
Et c'est le tunnel VPN sur le projet où les produits seront déployés, qui doivent accéder aux bases de données.
Toute aide est grandement appréciée! 
3 Réponses :
Concernant le statut BGP "En attente de pair" dans votre tunnel VPN, je pense que cela est dû au routeur de nuage configuré BGP IP et IP BGP Peer IP. Lors de la configuration, l'adresse IP BGP du routeur de nuage de tunnel1 sera l'adresse IP de l'homologue BGP pour Tunnel2 et l'adresse IP de pair BGP pour Tunnel1 sera l'adresse IP du routeur BGP de Tunnel2.
En vous référant à votre scénario, l'adresse IP de Stage-Tunnel-To-Cerberus devrait être: Routeur BGP Adresse IP: 169.254.1.2 et, Adresse IP de BGP Peer: 169.254.1.1
Ceci devrait mettre votre statut de session BGP Tunnels VPN dans "BGP établi".
Merci beaucoup. C'était l'erreur. Sur Cerberus, le IP 169.254.0.1/169.254.0.1 a déjà été utilisé par un autre tunnel avec un réseau sur site et ne pouvant pas voir la configuration sur le site où je pensais que l'adresse BGP n'était que quelque chose pour le routage interne de les demandes. Comme je l'ai dit, pas de fond de réseautage (mais je prends des livres de première fois). Merci encore!
Vous ne pouvez pas réaliser ce que vous voulez par VPN ou par VPC Peering. En fait, il existe une règle dans VPC qui évitent la transitivité de peering décrit dans la partie de restriction < / a>
seulement directement des réseaux homologues peuvent communiquer. Le peering transitif n'est pas pris en charge. En d'autres termes, si le réseau VPC N1 est envisagé avec N2 et N3, mais N2 et N3 ne sont pas directement connectés, VPC Network N2 ne peut pas communiquer avec VPC Network N3 sur le jeu de réseaux VPC.
Maintenant, prenez ce que vous voulez réaliser. Lorsque vous utilisez une adresse IP privée Cloud SQL, vous créez un peering entre votre VPC et le VPC du cloud SQL. Et vous avez un autre peering (ou un tunnel VPN) pour le moteur SQL.
Moteur SQL -> JEEING -> PROJET -> JE PEAINE -> Cloud SQL
Comme ça, vous ne pouvez pas.
Mais vous pouvez utiliser VPC partagé . Créez un VPC partagé, ajoutez vos 2 projets dedans, créez un sous-réseau commun pour le moteur SQL et le scrutin SQL Cloud SQL. Cela devrait fonctionner.
mais, soyez prudent. Toutes les fonctionnalités VPC ne sont pas disponibles avec VPC partagé. Par exemple, connecteur VPC sans serveur ne sont pas encore conformes avec il.
J'espère que cette aide!
Merci Guillaume, cela semble la solution la plus rationalisée. J'ai accepté @Marcelp répondre car il est plus pertinent pour ma question, mais je vais garder l'option VPN partagée à l'esprit et expérimenter!
Pas de problème, j'ai répondu à votre objectif global. Je ne suis pas non plus un administrateur réseau et je n'aime pas les problèmes de réseau! Et je voulais vous empêcher de passer trop de temps dans une solution inutile!
En dépit de demander au soutien de Google (100 £ x mois) et à suivre leur suggestion de créer un VPN (d'où cette question) apparemment, vous aviez raison, car le tunnel VPN ne me permet pas d'accéder à l'ensemble de sous-réseau SQL Engine. Voilà pour le soutien payé. Je vais explorer la solution VPC partagée que vous avez suggérée.
La configuration originale dans la question OP devrait fonctionner, c'est-à-dire
(le réseau Ensuite, la ressource dans réseau 1 <--- (VPN) ---> Network 2 <--- (homologue) ---> Network CloudSQL
et le peering est créé par GCP)
Network 1 est capable d'accéder à une instance MySQL créée dans le réseau cloudsqlz réseau.
Quelle architecture voulez-vous réaliser? Ressource A -> VPN -> Projet B -> Cloud SQL Private IP? Vous voulez que la ressource a atteint un cloud SQL hébergé par le projet B. Suis-je raison?
Oui, @guillaumeblaquiere. Nous essayons de disposer de la propriété intellectuelle SQL privée disponible dans la ressource A. Le moteur SQL est sur la ressource B.