Cette page décrit le fonctionnement des routes personnalisées avec les sauts suivants de tunnels Cloud VPN dans Google Cloud.
Pour plus d'informations sur les routes Google Cloud, y compris l'applicabilité et l'ordre de priorité, ainsi que les paramètre de commande et de route statique, consultez la présentation des routes du cloud privé virtuel (VPC).
Types de routes
Un tunnel Cloud VPN peut être un prochain saut pour une route personnalisée dans votre réseau VPC. Chaque route personnalisée avec un tunnel Cloud VPN de prochain saut définit un chemin de sortie pour les paquets quittant votre réseau VPC :
Un routeur cloud gère toujours un tunnel VPN classique qui utilise le routage dynamique ou un tunnel VPN haute disponibilité. Ce routeur cloud reçoit des annonces BGP d'une passerelle VPN de pairs et envoie des messages BGP à cette passerelle. Cloud Router crée et supprime automatiquement les routes dynamiques dans votre réseau VPC. Il s'agit de routes avec des destinations dans un réseau pair. Il diffuse également les routes vers les réseaux pairs : ce sont des routes vers les plages d'adresses IP de sous-réseaux de votre réseau VPC, ou vers les destinations personnalisées que vous spécifiez dans une configuration Cloud Router. Le mode de routage dynamique de votre réseau VPC contrôle l'ensemble des routes importées et exportées par Cloud Router.
Un tunnel VPN classique basé sur des règles ou des routes utilise le routage statique. Si vous utilisez la console Google Cloud pour créer l'un de ces tunnels, Google Cloud crée automatiquement des routes statiques en fonction des plages d'adresses IP distantes spécifiées dans la configuration de Cloud VPN. Si vous utilisez Google Cloud CLI pour créer l'un de ces tunnels, vous devez créer manuellement les routes statiques qui utilisent le tunnel comme saut suivant.
Exemples de cas de figure
Google Cloud suit une applicabilité et un ordre de priorité bien définis lors de la sélection du prochain saut auquel un paquet doit être envoyé. Les exemples suivants illustrent les interactions courantes entre les routes et Cloud VPN.
Interaction avec les routes de sous-réseau
Le tableau suivant montre l'interaction entre les routes de sous-réseau et les routes personnalisées.
Chaque ligne représente une plage d'adresses IP possible d'un sous-réseau dans un réseau VPC. Les plages sur site sont 10.2.0.0/16 pour IPv4 et fd20:a:b:c::/64 pour IPv6.
Le trafic IPv6 n'est compatible qu'avec les passerelles VPN haute disponibilité configurées avec un type IPv4 et IPv6 à double pile.
| Réseau VPC | Routage du tunnel Cloud VPN | |
|---|---|---|
| Plage d'adresses IP du sous-réseau Google Cloud | Statique (basé sur des règles, basé sur des routes) VPN classique uniquement |
Dynamique (BGP) VPN classique ou VPN haute disponibilité |
10.2.0.0/16Identique à la plage d'adresses IP sur site |
Google Cloud ne vous permet pas de créer de routes statiques dont la destination est 10.2.0.0/16 et dont le prochain saut est un tunnel Cloud VPN. |
Le routeur Cloud Router associé au tunnel ignore toutes les routes annoncées dont la destination est 10.2.0.0/16. Le trafic destiné à 10.2.0.0/16 reste sur votre réseau VPC. |
fd20:a:b:c::/64Identique à la plage d'adresses IP sur site |
Le VPN classique n'est pas compatible avec IPv6. | Le routeur Cloud Router associé au tunnel ignore toutes les routes annoncées dont la destination est fd20:a:b:c::/64. Le trafic destiné à fd20:a:b:c::/64 reste sur votre réseau VPC. |
10.0.0.0/8Plus large que la plage d'adresses IP sur site (masque de sous-réseau plus petit) |
Google Cloud ne vous permet pas de créer de routes statiques dont la destination est 10.2.0.0/16 et dont le prochain saut est un tunnel Cloud VPN. |
Le routeur Cloud Router associé au tunnel ignore toutes les routes annoncées dont les destinations correspondent ou sont comprises dans 10.0.0.0/8, y compris 10.2.0.0/16. Le trafic destiné à 10.0.0.0/8 reste sur votre réseau VPC. |
fd20:a:b::/48Plus large que la plage d'adresses IP sur site (masque de sous-réseau plus petit) |
Le VPN classique n'est pas compatible avec IPv6. | Le routeur Cloud Router associé au tunnel ignore toutes les routes annoncées dont les destinations correspondent ou sont comprises dans fd20:a:b::/48, y compris fd20:a:b:c::/64. Le trafic destiné à fd20:a:b::/48 reste sur votre réseau VPC. |
10.2.99.0/24Plus étroit que la plage d'adresses IP sur site (masque de sous-réseau plus long) |
Google Cloud vous permet de créer une route statique avec la destination 10.2.0.0/16 et le tunnel Cloud VPN de prochain saut. Toutefois, le trafic vers les adresses IP dans 10.2.99.0/24 reste dans votre réseau VPC. |
Le routeur Cloud Router associé au tunnel accepte une route annoncée dont la destination est 10.2.0.0/16. Toutefois, le trafic vers les adresses IP dans 10.2.99.0/24 reste dans votre réseau VPC. |
fd20:a:b:c::/80Plus étroit que la plage d'adresses IP sur site (masque de sous-réseau plus long) |
Le VPN classique n'est pas compatible avec IPv6. | Le routeur Cloud Router associé au tunnel accepte une route annoncée dont la destination est fd20:a:b:c::/64. Toutefois, le trafic vers les adresses IP dans fd20:a:b:c::/80 reste dans votre réseau VPC.
|
Cas où les tunnels sont indisponibles
Routage dynamique (BGP)
Lorsqu'un tunnel VPN classique qui utilise le routage dynamique ou un tunnel VPN haute disponibilité devient indisponible, le routeur Cloud Router qui le gère supprime automatiquement les routes apprises. La durée nécessaire pour détecter la faille varie selon que la détection de transfert bidirectionnel (BFD) est activée ou pas. Si BFD est activé, la détection se produit à l'expiration du timer de préservation BGP. Sinon, la détection se produit en moins de 60 secondes. Les routes apprises peuvent être rajoutées lorsque le tunnel est rétabli.
Ce processus est entièrement automatique, mais il peut tout de même entraîner une perte de paquets pendant que Cloud Router supprime les routes concernées.
Routage statique
Google Cloud ne considère jamais un tunnel Cloud VPN comme saut suivant valide qui n'a pas mis en place une association de sécurité IKE (SA). Si un tunnel Cloud VPN a établi une association de sécurité IKE, Google Cloud le considère comme opérationnel. Un tunnel Cloud VPN opérationnel ne transmet le trafic que s'il est sélectionné comme prochain saut selon l'ordre de routage. Le prochain saut pour une route différente, avec une destination plus spécifique ou une priorité plus élevée, peut être utilisé à la place.
Les cas de figure suivants illustrent les comportements attendus :
Si vous disposez de plusieurs routes statiques pour la même destination, chacune ayant un tunnel Cloud VPN de prochain saut différent, Google Cloud ne prend en compte que les tunnels ayant des associations de sécurité IKE établies (Phase 1). Les tunnels qui ne sont pas opérationnels (c'est-à-dire, qui n'ont pas d'association de sécurité IKE valide) sont ignorés avant que la priorité des routes soit envisagée.
Par exemple, supposons que vous ayez trois routes statiques pour la destination
192.168.168.0/24: une avec la priorité10dont le tunnel Cloud VPN de prochain saut est indisponible, une deuxième avec une priorité20dont le tunnel de prochain saut est disponible, et une troisième avec la priorité30dont le tunnel du prochain saut est également disponible. Google Cloud envoie du trafic vers le deuxième prochain saut, même si sa route est moins prioritaire que la route dont le prochain saut est indisponible. Si le premier tunnel est rétabli, Google Cloud le considère comme un prochain saut valide et utilise cette route à la place.Le trafic est interrompu si tous les tunnels Cloud VPN qui servent de prochains sauts pour les routes statiques avec la même destination sont indisponibles. Le trafic est interrompu même s'il existe une route statique pour une destination plus large avec un tunnel de prochain saut opérationnel.
Par exemple, supposons que vous ayez une route statique pour
192.168.168.0/24dont le tunnel Cloud VPN de prochain saut est indisponible (aucune association de sécurité IKE valide). Même si vous avez une route pour192.168.0.0/16dont le prochain saut est un tunnel Cloud VPN opérationnel, le trafic vers192.168.168.0/24est interrompu. En effet, Google Cloud sélectionne toujours les routes ayant les destinations les plus spécifiques.
Lorsque le trafic passe d'un tunnel Cloud VPN de prochain saut à un autre, vous devez quand même vous attendre à une perte de paquets. Les paquets en cours de transfert peuvent être supprimés et doivent être retransmis.
ECMP sur les tunnels
Pour le routage dynamique et le routage statique, s'il existe plusieurs routes personnalisées pour la même destination, avec la même priorité et un tunnel de prochain saut actif (association de sécurité IKE établie), Google Cloud utilise le routage multi-chemin à coût égal (ECMP) pour distribuer les paquets entre les tunnels.
Cette méthode d'équilibrage est basée sur un hachage, de sorte que tous les paquets du même flux utilisent le même tunnel tant qu'il est actif.
Pour tester le comportement ECMP, utilisez iperf3 pour envoyer plusieurs flux TCP simultanés, idéalement depuis plusieurs instances de machines virtuelles (VM) Google Cloud, via des tunnels Cloud VPN. N'effectuez pas de tests avec ICMP (ping) si vous devez valider le comportement ECMP. Un test ping d'une instance de VM n'est pas suffisant pour tester la sortie basée sur l'ECMP via les tunnels Cloud VPN, car un seul tunnel est sélectionné lorsque vous avez une source et une destination fixes.
ICMP n'a pas de concept de port et est un protocole fixe. Le hachage est donc calculé à partir de deux informations seulement : les adresses source et de destination (hachage double).
Étape suivante
- Pour en savoir plus sur les concepts de base de Cloud VPN, consultez la présentation de Cloud VPN.
- Pour vous aider à résoudre les problèmes courants que vous pouvez rencontrer lors de l'utilisation de Cloud VPN, consultez la page Dépannage.