GCP Cloud VPN : vérifier la passerelle, le tunnel et le pare-feu dans l'ordre

Votre console affiche un tunnel vert, la supervision sur site n'atteint toujours pas la moindre instance, et reconstruire le tunnel semble la solution évidente. Elle l'est rarement. Un tunnel établi prouve seulement que deux passerelles ont terminé l'échange IKE. Il ne dit rien sur le fait qu'un paquet ait jamais été autorisé à entrer dans votre VPC.

Quatre décisions séparent cette icône verte d'une réponse, et elles échouent dans un ordre prévisible. Traitez-les de la moins coûteuse à la plus coûteuse.

Trois objets, et un seul d'entre eux chiffre

Une passerelle VPN possède l'adresse externe vers laquelle votre homologue chiffre. Dans la console, vous ne la créez jamais à la main : choisissez ou réservez une adresse dans le formulaire de connexion et la passerelle apparaît avec elle. Une passerelle HA prend deux adresses sur deux interfaces, ce qui compte lors du contrôle des quotas plus tard.

Un tunnel est l'appariement entre cette passerelle et l'homologue. Il transporte le secret partagé et les sélecteurs de trafic qu'il promet de protéger. C'est dans ces sélecteurs que commencent la plupart des défaillances silencieuses. Un tunnel dont le sélecteur local couvre 10.0.0.0/24 ne livrera pas 10.0.1.0/24, quel que soit l'état de santé affiché.

L'extrémité distante tient sa propre liste, généralement appelée domaine de chiffrement, et le matériel de terminaison la compare à la vôtre. Aucun côté ne négocie un sélecteur qui ne lui a jamais été donné.

Le type de routage décide de ce qui atteint la table de routage

Cloud VPN propose trois formes de routage et elles ne se mélangent pas proprement. Le routage basé sur des règles conserve les paires de sélecteurs statiques, le routage basé sur des routes attend que vous ajoutiez vous-même des routes statiques, et le routage dynamique annonce des préfixes via un Cloud Router sur BGP. Choisissez-en une délibérément.

Un tunnel dynamique accompagné de routes statiques écrites à la main produit une table de routage qui se vide chaque fois que la session BGP oscille.

Le dynamique est la seule forme qui laisse les préfixes protégés changer sans reconstruire le tunnel, et il entraîne le Cloud Router dans l'ensemble des objets que vous devez vérifier. Les sélecteurs statiques restent viables lorsque l'homologue est un pare-feu matériel incapable de parler BGP. Les deux extrémités ont alors besoin des mêmes plages, et l'entrée la plus spécifique doit l'emporter des deux côtés. Une paire qui diffère d'un sous-réseau s'établit puis transporte la moitié de votre trafic.

Le refus implicite se tient derrière le tunnel

Le trafic entrant est évalué contre un refus implicite à la priorité la plus basse, et cette règle ne se soucie pas que le paquet soit arrivé chiffré. Tant qu'une règle de pare-feu ne nomme pas la plage sur site et le port utilisé, le paquet est déchiffré, inspecté et rejeté. Le journal VPN reste propre tout du long, car le tunnel a fait exactement ce qu'il promettait.

Lisez plutôt le journal de refus du pare-feu lorsque le tunnel est actif et que la sonde expire, puis limitez une règle à la plage source et aux ports dont vous avez besoin :

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

Un seul sens qui fonctionne est un indice de pare-feu

Le trafic sortant se comporte différemment, car la règle d'autorisation implicite laisse les instances envoyer n'importe où. Un centre de données qui n'atteint pas une VM se trouve souvent derrière un chemin sortant parfaitement fonctionnel dans l'autre sens. Cette asymétrie sépare un oubli de pare-feu d'une panne de routage, car une panne de routage casse les deux sens à la fois. Testez le sens inverse avant de modifier une règle de plus.

La création d'adresses est aussi une opération de quota. Un projet proche de sa limite d'adresses externes en usage refuse la connexion avec une erreur qui ressemble à un échec de permission.

Sélecteurs, quotas, puis les quatre contrôles

Les tunnels créés dans la console renvoient parfois un sélecteur de trafic distant vide via gcloud compute vpn-tunnels describe, tandis que les routes générées transportent correctement le trafic. Comparez ce que l'API enregistre aux plages que vous protégez réellement avant de conclure que le tunnel est fautif. Le créer via l'API ou le SDK garde le sélecteur explicite.

Les quotas sont l'autre oubli facile. Demandez l'augmentation avant la fenêtre de maintenance plutôt que pendant, et vérifiez le nombre d'adresses dans le même projet que la passerelle.

Travaillez de l'extérieur vers l'intérieur : état de l'homologue, les deux listes de sélecteurs, une route par côté, une règle d'entrée pour la plage source et le port, puis une capture de paquets. Inscrivez l'adresse de la passerelle, les deux listes de sélecteurs et le type de routage dans le ticket de changement tant que le tunnel est neuf, car le prochain ingénieur qui ajoutera un sous-réseau aura besoin des trois.