Activer le transfert IP sur une passerelle GCE VPN existante

La VM a été créée sans transfert IP, elle exécute déjà le logiciel VPN, et le réflexe est de la reconstruire à partir du modèle avec l’option activée. Cette reconstruction est inutile. Compute Engine expose canIpForward comme une propriété modifiable, et le chemin de mise à jour documenté l’applique avec un refresh plutôt qu’un redémarrage. Ce que l’option contrôle réellement est étroit : sans elle, la plateforme abandonne les paquets qui arrivent sur l’instance mais qui ne sont pas adressés à l’adresse propre de l’instance. Une passerelle qui transfère le trafic d’autres machines fait exactement cela, donc l’option doit être activée. Tout ce qui suit relève de la configuration de l’invité et du routage, que l’option ne touche pas.

Ce que l’option autorise, et ce qu’elle n’autorise pas

Lorsque le transfert est désactivé, la plateforme traite l’instance comme un point de terminaison. Les paquets dont la destination est l’adresse propre de l’instance sont livrés ; les paquets que l’instance est censée relayer pour le compte de quelqu’un d’autre ne le sont pas.

Lorsque le transfert est activé, l’instance peut servir de saut suivant pour une route VPC, ce qui est le rôle dont a besoin une appliance VPN. L’option ne dit rien des pare-feu, du routage de l’invité, de la configuration du tunnel ni des chemins de retour, et une valeur true sur une passerelle cassée reste une passerelle cassée.

Lire la propriété actuelle

Inspectez le réglage avant de changer quoi que ce soit, avec un describe en lecture seule sur l’instance, le projet et la zone visés :

gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'

Une valeur false n’a d’importance que si cette VM doit être un saut suivant. Si c’est le cas, le reste du chemin doit tout de même être vérifié séparément, car la propriété n’est qu’une ligne dans une chaîne plus longue.

Mettre à jour l’instance existante

La procédure de mise à jour des propriétés d’instance de Google exporte la ressource actuelle, modifie la propriété et soumet le résultat. C’est un flux de travail différent de l’option --can-ip-forward de la création, et c’est celui qui fonctionne sur une VM en marche.

Exportez d’abord la définition vers un fichier local, et conservez une copie inchangée pour la comparaison :

gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml

Dans ce fichier exporté, définissez la propriété et ne changez rien d’autre :

canIpForward: true

Conservez toute la ressource, empreinte comprise. Remplacer le fichier par un document YAML d’une ligne, ou regrouper des modifications sans rapport sur le type de machine, le disque ou l’interface dans la même soumission, est la façon dont un changement de propriété devient une panne.

Demandez au mécanisme de mise à jour de valider le fichier et d’indiquer ce qu’il exigerait, avant qu’un quelconque changement effectif soit autorisé :

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT

Cette exécution de validation n’active pas le transfert. Lisez la réponse pour repérer les propriétés invalides et l’action annoncée comme nécessaire. Pour ce changement isolé, l’action documentée est REFRESH. Si le résultat demande un redémarrage, le fichier contient plus que la propriété que vous vouliez modifier : inspectez-le au lieu d’accorder le redémarrage.

Appliquez le fichier relu avec la limite refresh :

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH

Vérifiez que l’opération est terminée et relancez la commande describe. Si l’empreinte ne correspond plus, quelqu’un d’autre a modifié l’instance pendant votre édition : exportez une copie fraîche et relisez le changement au lieu d’imposer votre fichier périmé.

L’invité doit encore router le paquet

Une autorisation cloud ne fait pas de l’appliance un routeur. Confirmez qu’une route VPC sélectionne cette VM comme saut suivant pour le préfixe de destination, et que l’invité route entre le tunnel et la bonne interface avec sa propre politique de transfert activée.

La politique de pare-feu doit autoriser le flux interne ainsi que l’écouteur externe. Ouvrir seulement le port VPN décrit le transport chiffré et ne dit rien de l’échange applicatif à l’intérieur.

Enfin, la destination a besoin d’un chemin de retour vers le pool de clients, ou la conception doit traduire les sources délibérément. Si la destination voit du trafic traduit, vérifiez la source traduite ; si la conception préserve le pool, vérifiez ce pool dans la route de retour et les règles d’accès. Ajouter du NAT avant d’avoir décidé quelle conception vous voulez masque une route manquante et change la politique que voit la destination.

Sur une passerelle Linux, le transfert du noyau fait partie de la configuration de l’invité. Une appliance pfSense a son propre équivalent, et y copier une commande sysctl Linux n’est pas l’étape correspondante.

Vérifier depuis le client qui a besoin d’accès

Testez depuis un client VPN vers un service cible, pas depuis la passerelle elle-même. Une connexion lancée sur la passerelle utilise une autre source et n’exerce jamais les règles de transfert que vous venez d’activer.

Consignez la propriété dans ce qui gère l’appliance. Une VM corrigée à la main fonctionne jusqu’à son prochain remplacement, qui réintroduit discrètement le réglage d’origine, et cette défaillance ressemblera à une régression du logiciel VPN.

Ordre du travail : lire la propriété, exporter et modifier une ligne, valider avec NO_EFFECT, appliquer avec REFRESH, confirmer que l’invité transfère, puis tester depuis un client.