API Google via VPN : routez la VIP, pas seulement le sous-réseau

Connectez-vous en SSH au serveur local, montez le tunnel, et la VM privée répond ; ensuite le premier appel à une API Google échoue faute de route. Le sous-réseau de la VM et les VIP de l’API sont des destinations différentes, donc une route pour l’une ne sélectionne pas l’autre. Trois conditions doivent être réunies pour qu’un appel d’API privé fonctionne. Le nom de l’API doit se résoudre en une VIP, le préfixe VIP doit être annoncé à travers le tunnel, et le VPC doit savoir comment renvoyer la réponse. Un ping ne vous dit rien de tout cela, et une session SSH fonctionnelle vers une machine du sous-réseau non plus.

Les VIP de l’API sont des destinations distinctes

Google publie des VIP dédiées pour l’accès à l’API depuis le réseau local, et ce sont ces adresses que votre DNS doit renvoyer pour les noms d’API. Les deux sont de petits préfixes et aucune n’appartient à l’espace RFC 1918 :

Des adresses d’apparence publique ne signifient pas que la route doit quitter le tunnel pour l’internet ordinaire. Les préfixes existent pour qu’un client local atteigne les frontaux de Google par un chemin pris en charge plutôt que par un point de sortie arbitraire. Traitez-les comme des destinations qui appartiennent au tunnel, pas comme des hôtes à sonder. Une règle de pare-feu écrite pour la sortie internet les écarte généralement, et c’est une raison courante pour qu’un appel échoue avant même de commencer.

Le DNS décide de l’extrémité que vous atteignez

Pointez le résolveur local vers les enregistrements que Google documente pour l’extrémité choisie, afin que les noms dont l’application a besoin répondent avec cette VIP. Le simple googleapis.com n’est pas un inventaire : les registres de paquets, les registres de conteneurs et les connecteurs de migration ont leurs propres noms documentés. La VIP restreinte ne transporte pas non plus tous les services, donc un nom qui se résout peut rester non pris en charge. Notez les domaines que l’application contacte réellement avant de toucher au résolveur.

Deviner une adresse de VM du VPC à la place d’un nom de service n’est pas une correction, et cela masque généralement la lacune DNS jusqu’à ce qu’un autre client échoue.

Annoncez le préfixe VIP, conservez le reste

Avec une connexion fondée sur BGP, le Cloud Router doit annoncer le préfixe VIP choisi pour que le routeur local apprenne cette plage via la session prévue. Annoncer uniquement les sous-réseaux du VPC n’ajoute pas cette plage, et le routeur local continue d’utiliser sa route par défaut pour ces adresses. Le préfixe de la table de routage est la seule preuve que l’annonce a traversé la session.

Conservez les annonces existantes pendant que vous ajoutez la nouvelle, car les options au niveau du routeur et au niveau du pair n’ont pas la même portée, et remplacer l’ensemble peut retirer des réseaux qui fonctionnaient déjà. Vérifiez ensuite l’annonce effective sur chaque session plutôt que sur le routeur entier. Un préfixe absent et un préfixe retiré se ressemblent côté local, donc c’est la vue de la session qui sépare un oubli d’une régression.

Le côté VPC a besoin de sa propre route et de son chemin de retour

Dans le VPC, le chemin de la VIP doit utiliser la passerelle internet par défaut comme saut suivant, et malgré son nom ce trafic reste dans le réseau de Google. Le VPC a aussi besoin d’une route de retour vers la source locale via le VPN, et c’est un objet distinct du préfixe annoncé. Tenez compte des exigences régionales de routage documentées lorsque le tunnel et le client ne sont pas dans la même région.

Vérifiez le chemin de retour indépendamment, car une direction de requête qui fonctionne peut masquer une direction de réponse cassée. Deux directions, deux routes, et chacune échoue avec son propre symptôme.

Testez la requête, puis lisez le rejet

L’écho ICMP n’obtient aucune réponse de ces VIP, donc un ping échoué ne prouve rien et un ping réussi très peu. Depuis le vrai client, examinez la réponse du nom et la route sélectionnée, puis faites une requête HTTPS autorisée vers le service qui vous intéresse. Si la requête atteint le service et est rejetée, regardez les identifiants, l’IAM et toute politique de périmètre de service applicable.

Le routage privé ne confère pas d’autorisation API et ne change pas ce que l’identité est autorisée à faire. Le succès du transport et une réponse autorisée sont deux résultats distincts, et il vous faut les deux. Gardez aussi le chemin IPv6 explicite, car configurer les préfixes IPv4 ne dit rien d’un client qui préfère IPv6.

Le guide de Google sur Private Google Access depuis le réseau local couvre ensemble les enregistrements DNS et les exigences de routage, alors comparez-y vos réglages de résolveur et d’annonce plutôt qu’à un message de forum. Relancez ensuite la même requête et notez la réponse et la route dans le même ticket.