Ordre de priorité des routes

Cette page décrit le fonctionnement des routes personnalisées avec les sauts suivants de tunnels Cloud VPN dans Google Cloud.

Types de routes

Un tunnel Cloud VPN peut être un saut suivant pour une route personnalisée dans votre réseau VPC. Chaque route personnalisée avec un tunnel Cloud VPN de saut suivant définit un chemin de sortie pour les paquets quittant votre réseau VPC :

  • Un tunnel VPN classique qui utilise le routage dynamique ou un tunnel VPN haute disponibilité est toujours géré par Cloud Router. Cloud Router reçoit des publicités BGP d'une passerelle VPN de pairs et envoie des messages BGP à cette passerelle. Cloud Router crée et supprime automatiquement les routes dynamiques personnalisées 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 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. L'ensemble de routes importées et exportées par Cloud Router est contrôlé par le mode de routage dynamique de votre réseau VPC.

  • Un tunnel VPN classique basé sur des règles ou des routes utilise le routage statique. Si vous créez l'un de ces tunnels à l'aide de Cloud Console, Google Cloud crée automatiquement des routes statiques personnalisées en fonction des plages IP distantes spécifiées dans la configuration Cloud VPN. Si vous utilisez des commandes gcloud 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 saut suivant 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. La plage d'adresses IP sur site est 10.2.0.0/16.

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/16
Identique à la plage d'adresses IP sur site
Google Cloud ne vous permet pas de créer de routes statiques personnalisées dont la destination est 10.2.0.0/16 et dont le saut suivant est un tunnel Cloud VPN. Le 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.
10.0.0.0/8
Plus 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 personnalisées dont la destination est 10.2.0.0/16 et dont le saut suivant est un tunnel Cloud VPN. Le 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.
10.2.99.0/24
Plus é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 personnalisée avec la destination 10.2.0.0/16 et le tunnel Cloud VPN de saut suivant. Toutefois, le trafic vers les adresses IP dans 10.2.99.0/24 reste dans votre réseau VPC. Le 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.

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 Cloud Router qui le gère supprime automatiquement les routes dynamiques personnalisées apprises en 40 secondes environ. Les routes dynamiques personnalisées peuvent être de nouveau ajouté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 tient jamais compte d'un tunnel Cloud VPN qui n'a pas établi d'association de sécurité IKE (SA, Security Association) en tant que saut suivant valide. Toutefois, cela ne signifie pas que le trafic sera automatiquement envoyé vers un saut suivant pour un tunnel Cloud VPN opérationnel.

Les cas de figure suivants illustrent les comportements attendus :

  • Si vous disposez de plusieurs routes statiques personnalisées pour la même destination, chacune ayant un tunnel Cloud VPN de saut suivant différent, Google Cloud ne prend en compte que les routes ayant des associations de sécurité IKE établies (Phase 1). Les tunnels indisponibles, c'est-à-dire sans associations de sécurité IKE valides, sont ignorés avant de tenir compte de la priorité des routes.

    Par exemple, supposons que vous ayez trois routes statiques personnalisées pour la destination 192.168.168.0/24 : une avec la priorité 10 dont le tunnel Cloud VPN de saut suivant est indisponible, une deuxième avec une priorité 20 dont le tunnel de saut suivant est disponible, et une troisième avec la priorité 30 dont le tunnel du saut suivant est également disponible. Google Cloud envoie du trafic vers le deuxième saut suivant, même si sa route est moins prioritaire que la route dont le saut suivant est indisponible. Si le premier tunnel est rétabli, Google Cloud le considère comme un saut suivant valide et utilise cette route à la place.

  • Le trafic est interrompu si tous les tunnels Cloud VPN qui servent de sauts suivants pour les routes statiques personnalisées avec la même destination sont indisponibles. Cela est vrai même s'il existe une route statique personnalisée pour une destination plus large avec un tunnel de saut suivant opérationnel.

    Par exemple, supposons que vous ayez une route statique personnalisée pour 192.168.168.0/24 dont le tunnel Cloud VPN de saut suivant est indisponible (aucune association de sécurité IKE valide). Même si vous avez une route pour 192.168.0.0/16 dont le saut suivant est un tunnel Cloud VPN opérationnel, le trafic vers 192.168.168.0/24 est interrompu. En effet, Google Cloud sélectionne toujours les routes avec les destinations les plus spécifiques.

Lorsque le trafic passe d'un tunnel Cloud VPN de saut suivant à 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 saut suivant actif (association de sécurité IKE établie), Google Cloud distribue les paquets entre les tunnels à l'aide d'ECMP.

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 que ce dernier est actif.

Pour tester le comportement ECMP, utilisez iperf3 pour envoyer plusieurs flux TCP simultanés, idéalement depuis plusieurs VM GCP, 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).

Étapes suivantes