Le VPN vers le VPC fonctionne, mais le service géré expire

Atteindre une base de données gérée via un VPN échoue généralement pour une raison que personne n'a écrite dans le runbook : le tunnel se termine à la frontière de votre réseau, alors que le service n'a jamais été de votre côté. La table de routage semble correcte, le tunnel se déclare actif, et la connexion expire quand même. Déroulez les quatre vérifications ci-dessous dans l'ordre et arrêtez-vous à la première dont la condition de réussite est fausse, car chaque vérification suivante suppose que les précédentes ont été satisfaites.

Première vérification : où vit réellement le point de terminaison ?

Une passerelle VPN relie deux réseaux dont vous contrôlez l'adressage. Un service géré est exploité derrière la propre porte d'entrée du fournisseur, et cette porte prend l'une de trois formes selon le produit. Si vous ne savez pas à quelle forme vous avez affaire, aucun travail sur les routes n'aidera, car la panne n'est peut-être pas une panne de routage du tout.

La plupart des après-midi perdus viennent du fait de sauter ce classement et d'aller droit à la table de routage. Un service hébergé chez le fournisseur avec un point de terminaison public n'est pas derrière votre tunnel quoi qu'en dise le schéma, et un service rattaché au VPC n'apparaîtra jamais dans une réponse DNS publique.

Deuxième vérification : un service rattaché au VPC comme ElastiCache

Les caches de ce type sont adressés à l'intérieur de votre propre VPC et n'ont aucun écouteur tourné vers internet. Un VPN client terminé dans ce même VPC peut les atteindre, mais seulement lorsque trois conditions sont réunies. Le point de terminaison du cache doit être associé à des sous-réseaux que votre tunnel voit, son groupe de sécurité doit autoriser l'adresse d'où viennent vos clients, et le côté client a besoin d'une route qui couvre les sous-réseaux du cache.

L'erreur courante est de supposer qu'une connexion quelque part à proximité compte. Rattacher le VPN à un autre VPC, ou s'appuyer uniquement sur le peering, n'étend ni le groupe de sécurité du cache ni la table de routage de son sous-réseau à vos clients. Quand le tunnel existant se termine ailleurs, un hôte de rebond ou un serveur VPN placé dans ce VPC est la solution de repli habituelle. Ce repli est un contournement et non une conception, et il devrait être étiqueté comme tel dans le runbook.

Troisième vérification : un point de terminaison PaaS au nom public

Azure Database for PostgreSQL présente un nom de serveur public. Il ne vous donne pas une adresse privée que vous pourriez épingler dans un fichier hosts et router via une passerelle. Les points de terminaison de service de réseau virtuel limitent quels sous-réseaux peuvent atteindre une ressource ; ils n'autorisent pas un client sur site qui arrive par un VPN.

Obtenir un accès privé suppose d'introduire un point de terminaison privé ou une conception de liaison privée, puis d'ajouter une zone DNS privée afin que le nom public réponde avec ce point de terminaison plutôt qu'avec internet. Un VPN combiné à une règle de point de terminaison de service est une autre architecture qui ne se ressemble que sur un schéma. App Service suit la même logique dans l'autre sens : l'intégration VNet permet à l'application d'émettre des appels sortants vers un VNet, et elle ne crée pas de chemin privé entrant depuis votre tunnel. L'accès privé entrant exige donc un point de terminaison privé, un App Service Environment ou une passerelle devant l'application, et lequel de ces choix vous pouvez utiliser dépend du plan.

Quatrième vérification : les produits qui ont leur propre porte d'entrée

Firebase Hosting ne peut pas être rattaché à un Cloud VPN, car la couche d'hébergement est un frontal mondial et non quelque chose à l'intérieur du VPC d'un projet. L'alternative documentée est de construire soi-même le point d'entrée contrôlé, avec une instance de proxy ou un répartiteur de charge adossé à un compartiment. Dans les deux cas le site cesse d'être un produit d'hébergement pur et devient une infrastructure que vous exploitez désormais. Ce compromis mérite d'être nommé avant que quelqu'un promette que le tunnel le couvrira.

Private API Gateway se situe plus près du côté des services du VPC : un point de terminaison VPC d'interface publie un nom d'hôte dont les réponses sont des adresses privées, et le trafic depuis vos locaux arrive par le tunnel ou par une interconnexion dédiée. Le point de terminaison doit être associé à l'API, et le certificat ainsi que le nom d'hôte doivent correspondre au domaine personnalisé utilisé par les appelants.

Les tunnels Google Cloud VPN se lient à des adresses IP de pairs, pas à des noms. Le transfert DNS est configuré séparément, ce qui explique qu'un tunnel puisse être parfaitement sain tandis que les recherches dans la zone privée distante échouent encore.

Localisez ensuite la frontière

Exécutez la même connexion depuis une VM à l'intérieur du VPC. Quand elle réussit là-bas et échoue depuis le client VPN, l'écart se situe entre le chemin du client et le point de terminaison du service : une route, un groupe de sécurité, une politique de point de terminaison ou un nom. Quand les deux tentatives échouent, rien dans ce réseau ne peut atteindre le service, et le VPN n'a jamais été l'obstacle.

getent hosts db.internal.example
nc -vz db.internal.example 5432

Faites la résolution de nom et le contrôle de port séparément, car ils échouent pour des raisons différentes et le couple vous dit quelle moitié du chemin est cassée. Un nom qui se résout en adresse publique vous dit que la zone DNS privée n'est pas en jeu.