Pourquoi votre VM GCP ne peut pas répondre au pool IPv6 d’OpenVPN

Votre client VPN IPv6 atteint la charge de travail, la charge répond dans le tunnel, et la réponse n’arrive jamais. Le réflexe est d’accuser le pare-feu ou le tunnel, et ni l’un ni l’autre n’est généralement en cause. Une adresse fournie par OpenVPN est un réseau interne qui n’existe qu’à l’intérieur du tunnel ; Google Cloud ignore que fd42:90::/64 est censé se trouver derrière une VM précise tant que vous ne le lui dites pas.

Deux systèmes distincts doivent apprendre ce fait, et un seul d’entre eux est OpenVPN. Le VPC a besoin d’une route avant de pouvoir renvoyer quoi que ce soit, et la VM doit être autorisée à transférer ce qui arrive. Trompez-vous sur l’une des deux moitiés et le symptôme est identique.

Le pool est un réseau interne, pas un sous-réseau

OpenVPN peut distribuer des adresses IPv6 depuis une plage que vous choisissez, et cette plage est une fiction sur laquelle les deux extrémités du tunnel s’accordent. Ce n’est pas un sous-réseau Google Cloud, elle n’apparaît pas dans la liste des sous-réseaux du VPC, et l’interface réseau de la VM n’acquiert pas ces adresses. Une charge qui répond à un client envoie donc un paquet vers une adresse que le réseau considère comme non routable.

Gardez le pool hors de chaque plage que le VPC utilise déjà. Gardez-le aussi hors des plages situées derrière vos autres tunnels. Un chevauchement transforme une panne de routage nette en panne intermittente qui n’apparaît que sous charge.

Un adressage local unique comme fd42:90::/64 est un choix raisonnable pour ce réseau interne. Le préfixe rappelle aussi que la conception est privée par construction. Rien dans un pool ULA n’en fait une source légitime sur l’internet public.

Donnez au VPC une destination et un saut suivant

La réponse a besoin d’une route VPC dont la destination est le pool et dont le saut suivant est la VM VPN. La documentation actuelle sur les routes statiques couvre les plages de destination IPv6 et indique quels types de saut suivant sont éligibles, alors vérifiez la forme prise en charge pour votre topologie au lieu de copier un ancien exemple IPv4.

Une adresse de saut suivant doit être une adresse réellement attribuée à l’interface cloud de l’instance. L’adresse interne du tunnel de la VM n’est pas cette adresse. L’utiliser quand même produit une route qui s’installe proprement et ne correspond jamais à un paquet. Lisez la liste des interfaces avant d’écrire la route.

La priorité des routes compte autant que l’entrée elle-même. Les routes de sous-réseau sont plus spécifiques que les routes personnalisées que vous ajoutez, donc un pool découpé dans une plage de sous-réseau existante perdra face à la route de sous-réseau, quelle que soit la façon dont la route personnalisée est écrite. Choisissez un pool distinct, puis confirmez que la route affiche l’instance comme saut suivant et le bon préfixe de destination :

gcloud compute routes create vpn6-return \
  --network=vpn-vpc \
  --destination-range=fd42:90::/64 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b

Le transfert doit être activé deux fois

Une route achemine le paquet vers l’instance. Elle ne rend pas l’instance disposée à transférer quelque chose qui ne lui est pas adressé, et cette autorisation existe à deux niveaux.

Le côté cloud a besoin de la capacité de transfert de l’instance activée ; c’est le réglage qui permet à une VM de recevoir du trafic pour des adresses qu’elle ne possède pas et de le transmettre. Le côté invité a besoin de son propre transfert IPv6, car le noyau applique une décision distincte après l’arrivée du paquet. Les deux doivent être activés avant qu’une seule réponse ne traverse le tunnel.

sysctl -w net.ipv6.conf.all.forwarding=1

Les règles de pare-feu doivent ensuite admettre la plage source interne dans les deux sens. Google Cloud évalue le paquet désencapsulé, donc une règle qui ne couvre que le sous-réseau du VPC abandonne le trafic du pool une fois le tunnel déjà réussi. Ajoutez le pool comme plage source dans la règle d’entrée, et vérifiez qu’aucune politique de sortie personnalisée ne bloque la réponse. La règle d’autorisation implicite couvre le cas par défaut, une règle de sortie écrite à la main non.

Dites à OpenVPN qui possède quoi

OpenVPN transfère vers un client lorsqu’il sait que ce client possède la destination. Les adresses client du pool sont gérées par la directive serveur qui définit le pool, mais un sous-réseau derrière un client est une autre disposition et nécessite une entrée de propriété explicite pour ce client.

Confondre les deux produit un tunnel où les pings vers le serveur fonctionnent et rien derrière lui. Décidez quel cas vous construisez, puis écrivez l’entrée correspondante au lieu d’ajouter une seconde ligne push en espérant.

Gardez la sortie internet hors de cette conception

L’accès privé et l’accès internet sont deux plans distincts. Un pool ULA peut atteindre les charges de travail du VPC via le tunnel une fois le routage et le transfert d’accord, et ce même pool n’a aucun chemin vers l’internet public à travers le VPC, car la passerelle cloud n’acceptera pas une source de tunnel arbitraire comme la sienne.

Si les clients ont aussi besoin d’une sortie internet, planifiez pour cela une conception d’adressage et de routage prise en charge, gardez-la indépendante du pool privé et testez les deux chemins séparément. Un chemin qui fonctionne ne dit rien de l’autre, et une conception qui les confond échoue d’une manière qui ressemble à un tunnel cassé.