IP privée Cloud SQL via VPN : la route que personne n'exporte

Beaucoup d'équipes croient que l'IP privée de Cloud SQL ne fonctionne que depuis l'intérieur du VPC, et cette croyance persiste parce que la panne ressemble à un problème de base de données. Google documente l'accès depuis des réseaux connectés par Cloud VPN ou Cloud Interconnect. Ces réseaux n'ont pas besoin d'une fonction de base de données particulière, mais de deux échanges de routes faciles à laisser à moitié configurés. Le tunnel monte, les instances de calcul répondent et la connexion à la base de données expire : exactement la combinaison qui envoie les gens vers la mauvaise console.

Mythe : une IP privée signifie privée pour le VPC

L'accès aux services privés est un appairage de VPC entre votre réseau et un réseau producteur détenu par Google. La plage allouée au service se trouve côté producteur, et l'adresse de l'instance est à l'intérieur. C'est cet appairage qui permet à une base de données de votre projet de résider sur une adresse vers laquelle votre VPC route sans qu'aucun sous-réseau explicite de votre part ne la contienne.

Comme c'est un appairage, il en a aussi le comportement, y compris la partie où les routes personnalisées ne franchissent pas automatiquement la frontière.

Mythe : un tunnel qui fonctionne transporte la route de la base de données

Deux plages doivent survivre au trajet. La première est le préfixe client : votre réseau local doit être connu du Cloud Router avec des préfixes précis, car une route par défaut ne peut pas fournir l'import dont le réseau producteur a besoin pour le chemin de retour. La seconde est la plage de service allouée, que le côté externe doit apprendre pour que ses paquets vers la base de données aient où aller. Ce sont des routes différentes maintenues à des frontières différentes, et corriger l'une laisse l'autre cassée.

Côté Google, cela signifie activer Export custom routes sur les connexions d'appairage concernées et ajouter la plage de service allouée aux routes annoncées du Cloud Router pour le tunnel.

Conservez les annonces déjà présentes. L'ajout de la plage de service ne doit pas retirer les routes du VPC que la même session BGP transporte pour d'autre trafic, et un jeu d'annonces remplacé en bloc est une seconde panne cachée derrière la première. Vérifiez aussi les routes effectives sur l'équipement externe, car atteindre la passerelle VPN ou un autre sous-réseau ne prouve que le transport.

Mythe : le Cloud SQL Auth Proxy règle le problème réseau

The Auth Proxy fournit une authentification prise en charge et un transport chiffré entre votre application et l'instance. Il ne crée pas de route. Un proxy lancé sur un hôte sans chemin vers le réseau privé échouera exactement comme échouerait une connexion directe, et ses journaux seront moins utiles sur le pourquoi. Déplacer le proxy vers un hôte qui dispose de la connectivité change quel tronçon du chemin doit fonctionner, et c'est une vraie décision de conception, pas un contournement.

Ce qu'il ne fait pas, c'est permettre à un portable déconnecté d'atteindre une instance uniquement privée.

Mythe : Private Service Connect suit les mêmes règles

Private Service Connect utilise un point de terminaison dans votre propre sous-réseau et une organisation DNS que vous contrôlez, la route vers lui est donc une route ordinaire vers une adresse qui vous appartient. Les réglages d'export d'appairage ne s'appliquent pas à ce design, et copier des changements d'appairage dans un déploiement PSC ajoute du risque sans ajouter de joignabilité.

Les deux vous donnent une adresse privée ; la ressemblance s'arrête là.

Testez le chemin dans le bon ordre

Depuis le client externe, testez d'abord le point de terminaison TCP de la base de données. Une poignée de main TCP terminée signifie que routage, pare-feu et écouteur sont tous en place, et le test suivant est une opération authentifiée autorisée. Un refus d'authentification est en fait une bonne nouvelle à ce stade, car il prouve qu'un écouteur de la base de données a répondu. Un délai ICMP ne dit presque rien sur l'accès à la base de données, car beaucoup de chemins le suppriment tout en transmettant TCP sans problème.

Si vos plages client sont hors de RFC 1918, examinez les exigences supplémentaires d'export de routes et d'autorisation réseau avant de conclure que le design n'est pas pris en charge.

Notez quatre objets avec la connexion : le préfixe externe, la plage de service allouée, les connexions d'appairage impliquées et le routeur qui annonce. Ces quatre objets expliquent tout le chemin privé et remplacent la légende selon laquelle Cloud SQL a soit toujours besoin d'un proxy, soit ne peut pas être atteint du tout par VPN.