Présentation des routes

Les routes Google Cloud définissent les chemins d'accès du trafic réseau depuis une instance de machine virtuelle (VM) vers d'autres destinations. Ces destinations peuvent se trouver à l'intérieur de votre réseau cloud privé virtuel (VPC, Virtual Private Cloud) Google Cloud (par exemple, au sein d'une autre VM) ou à l'extérieur de celui-ci.

Dans un réseau VPC, une route se compose d'un seul préfixe de destination au format CIDR et d'un saut suivant unique. Lorsqu'une instance d'un réseau VPC envoie un paquet, Google Cloud le transmet au saut suivant de la route, à condition que l'adresse de destination du paquet se trouve dans la plage de destination de la route.

Cette page offre un aperçu du fonctionnement des routes dans Google Cloud.

Routage dans Google Cloud

Chaque réseau VPC utilise un mécanisme de routage virtuel distribué et évolutif. Aucun appareil physique n'est attribué au réseau. Certaines routes peuvent être appliquées de manière sélective, mais la table de routage d'un réseau VPC est définie au niveau du réseau VPC.

Chaque instance de VM dispose d'un contrôleur qui reçoit en permanence des informations sur toutes les routes applicables depuis la table de routage du réseau. Chaque paquet quittant une VM est acheminé vers le saut suivant approprié d'une route applicable, en fonction d'un ordre de routage. Lorsque vous ajoutez ou supprimez une route, l'ensemble des modifications est propagé aux contrôleurs des VM selon un modèle de cohérence à terme.

Types de routes

Les tableaux suivants récapitulent comment Google Cloud classe les routes dans les réseaux VPC.

Type et destination Saut suivant Remarques
Routes générées par le système
Route par défaut générée par le système
0.0.0.0/0
default-internet-gateway Applicable à l'ensemble du réseau VPC

Peut être supprimée ou remplacée
Route de sous-réseau
Créée automatiquement pour chaque plage d'adresses IP du sous-réseau
Réseau VPC
Transmet les paquets aux VM et aux équilibreurs de charge internes
S'applique à l'ensemble du réseau VPC

Créée, mise à jour et supprimée automatiquement par Google Cloud lorsque vous créez, modifiez ou supprimez un sous-réseau ou une plage d'adresses IP secondaire d'un sous-réseau.
Routes personnalisées
Route statique
Accepte différentes destinations
Saut suivant de route statique valide Pour les équilibreurs de charge TCP/UDP internes de saut suivant, ne s'applique qu'au trafic TCP et UDP dans la même région que l'équilibreur de charge, sauf si l'accès mondial est activé.

Pour les autres sauts suivants statiques, la route peut s'appliquer à des VM spécifiques si vous spécifiez des tags réseau sur la route. Si vous ne spécifiez aucun tag réseau, la route s'applique à toutes les VM du réseau VPC.
Route dynamique
Destinations qui n'entrent pas en conflit avec les routes de sous-réseau ou les routes statiques
Pair d'une session BGP sur un routeur cloud Les routes sont ajoutées et supprimées automatiquement par les routeurs cloud de votre réseau VPC.

Les routes s'appliquent aux VM conformément au mode de routage dynamique du réseau VPC.
Routes d'appairage
Route d'appairage de sous-réseau
Représente une plage d'adresses IP de sous-réseau dans un réseau connecté à l'aide de l'appairage de réseaux VPC.
Réseau VPC appairé
Transmet les paquets aux VM et aux équilibreurs de charge internes du réseau appairé
S'applique à l'ensemble du réseau VPC

Créée, mise à jour et supprimée automatiquement par Google Cloud lorsque des sous-réseaux sont créés, modifiés ou supprimés dans le réseau appairé.
Route d'appairage personnalisée
Route statique ou dynamique personnalisée dans un réseau connecté à l'aide de l'appairage de réseaux VPC
Saut suivant dans le réseau VPC appairé Les routes d'appairage personnalisées reposant sur des routes statiques du réseau appairé s'appliquent comme suit :
  • Si la route d'appairage personnalisée repose sur une route statique personnalisée dont le saut suivant est un équilibreur de charge TCP/UDP interne, la route s'applique au trafic TCP et UDP dans la même région que l'équilibreur de charge, sauf si l'accès mondial est activé sur la règle de transfert de l'équilibreur de charge.
  • Si la route d'appairage personnalisée est basée sur une route statique personnalisée dont le saut suivant n'est pas un équilibreur de charge TCP/UDP interne, et que la route statique personnalisée n'est pas associée à un tag : la route s'applique à toutes les VM du réseau VPC qui l'importent.
  • Les routes statiques d'un réseau appairé qui utilisent des tags réseau ou dont les sauts suivants sont la passerelle Internet par défaut ne sont jamais exportées dans une relation d'appairage.
Les routes d'appairage personnalisées reposant sur des routes dynamiques dans le réseau appairé s'appliquent au mode de routage dynamique du réseau VPC qui les importe.

Route par défaut générée par le système

Lorsque vous créez un réseau VPC, celui-ci inclut une route par défaut générée par le système. Cette route par défaut a une double finalité :

  • Elle définit le chemin sortant du réseau VPC, y compris le chemin d'accès à Internet. Pour accéder à Internet, les instances doivent utiliser cette route, mais également répondre à des exigences supplémentaires.

  • Elle définit le chemin standard pour l'Accès privé à Google.

La route par défaut générée par le système a une priorité d'une valeur de 1000. Comme sa destination est la plus large possible (0.0.0.0/0), Google Cloud ne l'utilise que si une route ayant une destination plus spécifique ne s'applique pas à un paquet. Pour savoir comment la spécificité de destination et la priorité de routage sont utilisées pour sélectionner une route, consultez la section Ordre de routage.

Vous pouvez supprimer la route par défaut pour la remplacer par une route personnalisée, ou si vous souhaitez isoler complètement votre réseau d'Internet :

  • Vous pouvez remplacer la route par défaut par une route statique ou dynamique personnalisée si vous souhaitez acheminer le trafic Internet vers un saut suivant différent. Par exemple, vous pouvez le remplacer par une route statique personnalisée dont le saut suivant est une machine virtuelle proxy.

  • Si vous supprimez la route par défaut sans la remplacer, les paquets destinés aux plages d'adresses IP non couvertes par d'autres routes sont supprimés.

Routes de sous-réseau

Les routes de sous-réseau définissent des chemins d'accès à des ressources telles que des VM et des équilibreurs de charge internes dans un réseau VPC.

Chaque sous-réseau comporte au moins une route de sous-réseau dont la destination correspond à la plage d'adresses IP principale du sous-réseau. Si le sous-réseau comporte des plages d'adresses IP secondaires, il existe une route de sous-réseau correspondant à chacune de ses plages d'adresses IP secondaires. Pour en savoir plus sur les plages d'adresses IP de sous-réseau, consultez la section Réseaux et sous-réseaux.

Aucune autre route ne peut avoir une destination identique à celle d'une route de sous-réseau, ou plus spécifique que celle-ci (masque de sous-réseau plus long).

Les routes de sous-réseau ont toujours les destinations les plus spécifiques. Elles ne peuvent pas être remplacées par d'autres routes, même si une autre route a une priorité plus élevée. En effet, Google Cloud prend en considération la spécificité de destination avant la priorité pour sélectionner une route. Google Cloud utilise 0 comme priorité pour toutes les routes de sous-réseau.

Les points suivants décrivent la façon dont les routes de sous-réseau sont créées et supprimées :

  • Lorsque vous ajoutez un sous-réseau, Google Cloud crée une route de sous-réseau correspondant à la plage d'adresses IP principale du sous-réseau.

  • Les réseaux VPC en mode automatique créent une route de sous-réseau pour les plages d'adresses IP principales de chacun de leurs sous-réseaux créés automatiquement. Vous ne pouvez supprimer ces sous-réseaux que si vous basculez le réseau VPC du mode automatique vers le mode personnalisé.

  • Vous ne pouvez pas supprimer une route de sous-réseau sans modifier ou supprimer le sous-réseau :

    • Lorsque vous supprimez une plage secondaire d'un sous-réseau, la route de sous-réseau de cette plage secondaire est automatiquement supprimée.

    • Lorsque vous supprimez un sous-réseau, toutes les routes de sous-réseau des plages principales et secondaires sont automatiquement supprimées. Il n'existe aucune autre façon de supprimer la route de sous-réseau de la plage principale du sous-réseau.

Le nombre de routes de sous-réseau dans un réseau VPC est limité par le nombre maximal de plages d'adresses IP de sous-réseau (principales et secondaires).

Routes statiques

Les routes statiques sont définies à l'aide de paramètres de route statique et acceptent les sauts suivants de route statique. Vous pouvez créer des routes statiques de deux manières :

Routes dynamiques

Les routes dynamiques sont gérées par les routeurs cloud dans le réseau VPC. Leurs destinations représentent toujours des plages d'adresses IP en dehors de votre réseau VPC, reçues d'un pair BGP. Les routes dynamiques sont utilisées par :

Les réseaux VPC ignorent les destinations reçues par les routeurs Cloud lorsqu'elles correspondent à l'un de ces critères :

  • La destination correspond exactement à une plage d'adresses IP de sous-réseau.

  • La destination correspond à une plage d'adresses IP de sous-réseau (son masque de sous-réseau est plus long).

Il est possible que la destination d'une route dynamique contienne une plage d'adresses IP de sous-réseau (que son masque de sous-réseau soit plus court). Dans ce cas, les paquets ne sont envoyés au saut suivant de la route dynamique que s'ils ne correspondent pas à la destination de la route de sous-réseau. La destination la plus large possible est 0.0.0.0/0.

Routes d'appairage de sous-réseau

Les routes d'appairage de sous-réseau définissent des chemins d'accès à des ressources utilisant des sous-réseaux dans un autre réseau VPC connecté à l'aide de l'appairage de réseaux VPC. L'autre réseau est appelé réseau VPC appairé.

Les réseaux de pairs partagent les routes de sous-réseau de la manière suivante :

  • Les réseaux de pairs exportent toujours leurs routes de sous-réseau, pour toutes les plages d'adresses IP principale et secondaire.

  • Les réseaux de pairs importent automatiquement les routes de sous-réseau tant que la destination (plage d'adresses IP du sous-réseau) n'est pas une adresse IP publique réutilisée en mode privé. Vous pouvez configurer un pair pour importer les routes de sous-réseau qui utilisent des adresses IP publiques réutilisées en mode privé en cas de besoin.

  • Les routes d'appairage de sous-réseau importées ne peuvent être supprimées que si vous désactivez l'appairage. Lorsque vous désactivez l'appairage, toutes les routes d'appairage de sous-réseau importées sont automatiquement supprimées.

  • Google Cloud empêche les conflits de plages d'adresses IP du sous-réseau entre les réseaux appairés.

Le nombre combiné de routes de sous-réseau dans un réseau VPC et de routes d'appairage de sous-réseau importées depuis tous les réseaux appairés est limité par le nombre maximal de plages d'adresses IP de sous-réseau (principales et secondaires).

Routes d'appairage personnalisées

Vous pouvez configurer les réseaux appairés pour exporter ou importer des routes personnalisées. Dans ce contexte, les routes personnalisées désignent les routes statiques et dynamiques d'un réseau VPC.

Même lorsqu'un réseau VPC est configuré pour exporter ses routes personnalisées, il omet les types de routes suivants :

Le nombre combiné de routes statiques et dynamiques dans un réseau VPC et de routes d'appairage personnalisées importées à partir de tous les réseaux appairés est limité par :

  • Nombre maximal de routes statiques dans un groupe d'appairage
  • Nombre maximal de routes dynamiques dans un groupe d'appairage

Applicabilité et ordre

Routes applicables

Chaque instance possède un ensemble de routes applicables, qui constituent un sous-ensemble de toutes les routes du réseau VPC. Les routes applicables représentent les chemins de sortie possibles qu'un paquet peut emprunter lorsqu'il est envoyé depuis l'instance.

  • Les routes de sous-réseau et d'appairage s'appliquent à toutes les instances. Les routes de sous-réseau et les routes d'appairage de sous-réseau correspondent aux sous-réseaux de votre réseau VPC et à ceux importés depuis des réseaux appairés.

  • La route par défaut générée par le système s'applique à toutes les instances. Si vous le souhaitez, vous pouvez remplacer la route par défaut générée par le système par une route statique personnalisée.

  • Les routes statiques personnalisées s'appliquent à toutes les instances ou à des instances spécifiques. Les routes statiques avec un attribut de tag s'appliquent aux instances qui comportent le même tag réseau. Si la route ne comporte pas de tag réseau, elle s'applique à toutes les instances du réseau.

    • Lorsqu'une route statique personnalisée utilise une instance de VM comme saut suivant, la route est toujours valide, même si la VM de saut suivant est supprimée, mise hors tension ou défectueuse. Pour en savoir plus, consultez la section traitant des instances utilisées comme sauts suivants.

    • Lorsqu'une route statique personnalisée utilise un tunnel Cloud VPN comme saut suivant, la route reste valide tant que le tunnel est opérationnel. Pour plus d'informations sur la manière dont Google Cloud traite les routes des tunnels indisponibles, consultez la section Cas où les tunnels sont indisponibles dans la documentation Cloud VPN.

  • Les routes dynamiques s'appliquent aux instances basées sur le mode de routage dynamique du réseau VPC. Si un réseau VPC utilise le mode de routage dynamique régional, tous ses routeurs cloud ne créent des routes dynamiques que pour les préfixes appris dans leur région locale. Si un réseau VPC utilise le mode de routage dynamique global, tous ses routeurs cloud créent des routes dynamiques pour les préfixes appris dans toutes les régions.

    • Les routeurs cloud ignorent automatiquement les préfixes appris qui correspondent aux sauts suivants inaccessibles (tunnels Cloud VPN ou rattachements Cloud Interconnect). En fonction de votre réseau, les routeurs cloud peuvent prendre jusqu'à 40 secondes de temps de traitement pour supprimer une route dynamique avec un saut suivant indisponible.
  • Pour une partie du trafic à équilibrage de charge, les routes applicables proviennent de l'extérieur de votre réseau VPC. Pour en savoir plus, consultez la section Chemins de retour pour les équilibreurs de charge.

Ordre de routage

Lorsqu'une instance envoie un paquet, Google Cloud tente de sélectionner une route à partir de l'ensemble de routes applicables en fonction de l'ordre de routage suivant.

  1. Les routes de sous-réseau et routes d'appairage de sous-réseau sont prioritaires, car elles ont les destinations les plus spécifiques. Google Cloud considère les routes d'appairage de sous-réseau de la même manière que les routes de sous-réseau locales.

    • Si l'adresse IP de destination d'un paquet correspond à la destination d'une route de sous-réseau ou d'appairage :

      • Les paquets sont transmis à l'adresse IP interne d'une instance de VM en cours d'exécution ou à un équilibreur de charge interne configuré.

      • Les paquets destinés à une instance de VM arrêtée sont supprimés.

      • Les paquets destinés à une adresse IP interne sont supprimés si aucune ressource Google Cloud n'a été configurée pour utiliser l'adresse IP.

    • Google Cloud ne vous permet pas de créer une route statique personnalisée ayant une destination identique ou plus spécifique qu'une route de sous-réseau ou une route d'appairage de sous-réseau.

    • Les routeurs cloud ignorent les préfixes appris qui correspondent exactement à la destination d'une route de sous-réseau ou d'une route d'appairage de sous-réseau.

    • Les routeurs cloud ignorent les préfixes appris qui correspondent à (masque de sous-réseau plus long) une route de sous-réseau ou une route d'appairage de sous-réseau.

  2. Si le paquet ne peut pas être acheminé par une route de sous-réseau ni une route d'appairage de sous-réseau, Google Cloud recherche une route statique, dynamique ou d'appairage personnalisée qui dispose de la destination la plus spécifique. Par exemple, 10.240.1.0/24 est une destination plus spécifique que 10.240.0.0/16 pour les paquets avec la destination 10.240.1.4.

  3. Si plusieurs routes possèdent la même destination la plus spécifique, Google Cloud utilise le processus suivant pour en sélectionner une parmi les routes candidates. Les routes candidates sont les routes personnalisées (statiques, dynamiques ou d'appairage) ayant la même destination la plus spécifique.

    1. Si votre réseau VPC est connecté à des réseaux appairés, Google Cloud élimine toutes les routes candidates, à l'exception de celles d'un seul réseau VPC.

      • Si une ou plusieurs routes candidates existent sur votre réseau VPC local, Google Cloud ignore toutes les routes candidates des réseaux appairés.

      • Si aucune des routes candidates ne se trouve sur votre réseau VPC local, mais qu'il en existe dans plusieurs réseaux appairés, Google Cloud ignore toutes les routes candidates, à l'exception de celles définies dans l'un des réseaux appairés. Google Cloud utilise un algorithme interne pour sélectionner le réseau appairé unique. Cet algorithme ne prend pas en compte la priorité des routes à ce stade du processus. Si vous vous appairez avec un nouveau réseau ou que vous vous déconnectez d'un réseau appairé existant, cela risque de modifier le réseau VPC unique choisi par Google Cloud.

    2. Google Cloud élimine toutes les routes candidates, à l'exception de celles dont la priorité est la plus élevée. S'il ne reste qu'une seule route, Google Cloud envoie le paquet à son saut suivant.

    3. Si plusieurs routes candidates ont la même priorité, Google Cloud poursuit le processus d'élimination à l'aide du saut suivant et du type de route. S'il ne reste qu'une seule route, Google Cloud envoie le paquet à son saut suivant.

      1. Les routes statiques personnalisées dont le saut suivant est "instance de saut suivant", "adresse IP de saut suivant" ou "tunnel VPN de saut suivant" sont préférables. Toutes les autres routes candidates sont supprimées si une route candidate utilisant ce type de saut suivant existe.

      2. Les routes dynamiques personnalisées sont la deuxième option privilégiée.

      3. Les routes statiques personnalisées dont le saut suivant est l'équilibreur de charge TCP/UDP interne sont la troisième option privilégiée.

      4. Les routes statiques personnalisées qui utilisent le saut suivant de la passerelle Internet par défaut sont les moins prioritaires.

    4. S'il reste plusieurs routes candidates, ces routes existent toutes dans le même réseau VPC et ont la même priorité la plus élevée. Google Cloud répartit le trafic entre les sauts suivants des routes candidates en utilisant un hachage à cinq tuples pour l'affinité, en mettant en œuvre un routage multi-chemins à coût égal (ECMP, Equal-Cost Multi-Path). Les calculs de hachage sont effectués pour chaque paquet, au moment de l'envoi, en fonction du nombre de routes candidates déterminées par l'algorithme de sélection. Si le nombre de routes candidates est modifié, le hachage peut diriger un paquet avec le même hachage à cinq tuples vers un saut suivant différent.

  4. Si aucune destination applicable n'est trouvée, Google Cloud supprime le paquet et envoie un message d'erreur ICMP pour indiquer que la destination ou le réseau est inaccessible.

Chemins de retour spéciaux

Les réseaux VPC disposent de routes spéciales pour certains services. Ces routes sont définies en dehors de votre réseau VPC, au sein du réseau de production de Google. Elles n'apparaissent pas dans la table de routage de votre réseau VPC. Vous ne pouvez pas les supprimer ni les remplacer, même si vous supprimez ou remplacez une route par défaut de votre réseau VPC. Toutefois, vous pouvez contrôler le trafic depuis et vers ces services à l'aide de règles de pare-feu.

Chemins de retour pour les équilibreurs de charge

Si vous utilisez l'un des équilibreurs de charge Google Cloud suivants, sachez que Google Cloud possède des routes spéciales pour ces équilibreurs de charge et leurs vérifications de l'état. Ces routes sont décrites plus en détail dans les sections suivantes.

Chemins de retour pour les équilibreurs de charge HTTP(S), proxy SSL et proxy TCP

Pour ces types d'équilibreurs de charge, les systèmes Google Front End (GFE) servent de proxy. Lorsqu'un client envoie une requête à l'équilibreur de charge, un proxy interrompt la session TCP et en ouvre une nouvelle avec votre VM de backend. Les routes définies en dehors du réseau VPC facilitent la communication entre les proxys GFE et vos VM de backend, et inversement.

Pour en savoir plus, consultez les pages suivantes :

Chemins de retour pour les équilibreurs de charge réseau

Lorsqu'un client sur Internet envoie une requête TCP ou UDP à une VM de backend via un équilibreur de charge réseau, Google Cloud utilise des routes définies en dehors du réseau VPC pour faciliter la communication entre le client et votre VM de backend, et inversement.

Pour en savoir plus, consultez la page sur l'équilibrage de charge réseau.

Vérifications de l'état pour tous les types d'équilibreurs de charge

Les paquets envoyés depuis les systèmes de vérification de l'état Google Cloud possèdent des sources telles que décrites dans la section Plages d'adresses IP de vérification et règles de pare-feu. Les routes qui facilitent la communication entre les systèmes de vérification de l'état Google Cloud et vos VM de backend existent en dehors du réseau VPC et ne peuvent pas être supprimées. Cependant, le réseau VPC doit disposer de règles de pare-feu autorisant les entrées afin d'accepter le trafic provenant de ces systèmes.

IAP

Une route pour 35.235.240.0/20 est incluse afin de permettre le transfert TCP via IAP. Le réseau de production de Google n'accepte pas les routes pour 35.235.240.0/20 provenant d'autres sources sur Internet.

Cloud DNS

Une route vers 35.199.192.0/19 accepte la connectivité aux cibles de transfert qui utilisent le routage privé ou à des serveurs de noms alternatifs qui utilisent le routage privé. Le réseau de production de Google n'accepte pas les routes pour 35.199.192.0/19 provenant d'autres sources sur Internet.

Paramètres des routes statiques

Chaque route statique comprend les composants suivants :

  • Nom et Description : ces champs permettent d'identifier la route. Le nom est requis, mais la description est facultative. Chaque route de votre projet doit posséder un nom qui lui est propre.

  • Réseau : chaque route doit être associée à un seul réseau VPC.

  • Plage de destination : la plage de destination est un bloc CIDR IPv4 unique contenant les adresses IP des systèmes qui reçoivent des paquets entrants. Les destinations doivent être exprimées à l'aide de la notation CIDR. Elles ne peuvent pas correspondre exactement à une plage d'adresses IP de sous-réseau ni correspondre à une plage d'adresses IP de sous-réseau (elles ne peuvent pas avoir de masque de sous-réseau plus long). Il est possible que la destination d'une route statique contienne une plage d'adresses IP de sous-réseau (que son masque de sous-réseau soit plus court). Dans ce cas, les paquets ne sont envoyés au saut suivant de la route statique que s'ils ne correspondent pas à la destination de la route de sous-réseau. La destination la plus large possible est 0.0.0.0/0.

  • Priorité : la priorité permet de déterminer quelle route utiliser si plusieurs routes comportent des destinations identiques. Plus les valeurs sont faibles, plus la priorité est élevée. Par exemple, une route dont la valeur est 100 est prioritaire par rapport à celle dont la valeur est 200. La priorité la plus élevée pour une route correspond au nombre entier non négatif le plus petit possible. Comme zéro est le nombre entier non négatif le plus petit possible, il possède la priorité la plus élevée.

  • Saut suivant : les routes statiques peuvent comporter des sauts suivants qui pointent vers la passerelle Internet par défaut, vers une instance Google Cloud ou vers un tunnel Cloud VPN. Pour en savoir plus, consultez la section Sauts suivants des routes statiques.

  • Tags : vous pouvez spécifier une liste de tags réseau pour que la route s'applique uniquement aux instances qui comportent au moins un des tags répertoriés. Si vous n'indiquez aucun tag, Google Cloud applique la route à toutes les instances du réseau. Les équilibreurs de charge TCP/UDP internes de saut suivant ne sont pas compatibles avec les tags réseau.

Sauts suivants des routes statiques

Vous trouverez ci-dessous la liste des sauts suivants valides pour les routes statiques. Pour en savoir plus sur chaque type, consultez la documentation de référence sur gcloud.

  • Passerelle de saut suivant (next-hop-gateway) : vous pouvez spécifier une passerelle Internet par défaut pour définir un chemin d'accès vers des adresses IP externes.

  • Instance de saut suivant (next-hop-instance) : vous pouvez diriger le trafic vers une instance existante dans Google Cloud en spécifiant son nom et sa zone. Le trafic est dirigé vers l'adresse IP interne principale de l'interface réseau de la VM dans le réseau VPC où vous définissez la route.

    • Si l'adresse IP interne principale de l'interface réseau de l'instance de VM dans le réseau VPC change, Google Cloud met automatiquement à jour la table de routage du réseau VPC afin que le trafic continue d'être envoyé à la VM sous sa nouvelle adresse IP.

    • Si la VM est remplacée par une nouvelle VM portant le même nom dans la même zone, Google Cloud met automatiquement à jour la table de routage du réseau VPC afin que le trafic soit dirigé vers la VM de remplacement.

    • Google Cloud vérifie uniquement qu'une VM de saut suivant existe lorsque vous créez la route. Il ne confirme pas que la VM est capable de traiter ou de transférer des paquets. Si la VM est supprimée, mais pas remplacée, la route s'applique toujours, ce qui peut entraîner une perte de paquets. Pour en savoir plus, consultez la section traitant des instances utilisées comme sauts suivants.

  • Équilibreur de charge TCP/UDP interne de saut suivant (next-hop-ilb) : pour l'équilibrage de charge TCP/UDP interne, vous pouvez répartir le trafic entre les instances backend opérationnelles en utilisant l'adresse IP de l'équilibreur de charge comme saut suivant. Par exemple, vous pouvez répartir le trafic entre les VM de backend à l'aide d'une route statique personnalisée dont le saut suivant est un équilibreur de charge TCP/UDP interne. Les routes statiques personnalisées qui utilisent ce saut suivant ne peuvent pas être limitées à des instances spécifiques par le tag réseau.

  • Adresse IP de saut suivant (next-hop-address) : vous pouvez fournir une adresse IP interne attribuée à une VM Google Cloud en tant que saut suivant.

    • Lorsque vous utilisez next-hop-address, Google Cloud transmet le trafic à toute instance de VM attribuée à cette adresse IP. Si vous remplacez une instance de VM par une autre qui utilise la même adresse IP, le trafic ira à la VM de remplacement, même si elle porte un nom différent. Pour définir un saut suivant par nom de VM, utilisez plutôt l'instance de saut suivant.

    • Google Cloud vérifie uniquement que l'adresse IP est un membre valide de la plage d'adresses IP principale ou secondaire d'un sous-réseau lorsque vous créez la route. Il ne valide pas l'existence d'une instance à l'adresse IP de saut suivant. Si l'adresse IP de saut suivant n'est attribuée à aucune instance, la route s'applique toujours, ce qui peut entraîner la perte de paquets. Pour en savoir plus, consultez la section Considérations liées à l'instance et aux sauts suivants de l'équilibreur de charge.

    • Vous ne pouvez pas spécifier une adresse IP arbitraire comme saut suivant : les adresses situées en dehors de la plage d'adresses IP d'un sous-réseau de votre réseau VPC ne sont pas autorisées.

  • Tunnel VPN de saut suivant (next-hop-vpn-tunnel) : dans le cas de tunnels Cloud VPN utilisant le routage basé sur des règles et les VPN basés sur le routage, vous pouvez diriger le trafic vers le tunnel VPN en créant des routes dont les sauts suivants font référence au tunnel par son nom et sa région. Google Cloud ignore les routes dont les sauts suivants sont des tunnels Cloud VPN indisponibles. Pour plus d'exemples sur la manière dont les routes et les tunnels Cloud VPN interagissent, consultez les exemples de routage Cloud VPN.

Considérations liées aux sauts suivants de type instance et équilibreur de charge

Le routage basé sur une instance fait référence à une route statique dont le saut suivant est une instance de VM (next-hop-instance ou next-hop-address).

L'équilibreur de charge TCP/UDP interne en tant que saut suivant fait référence à une route statique dont le saut suivant est un équilibreur de charge TCP/UDP interne (next-hop-ilb).

Lorsque vous configurez le routage basé sur une instance ou un équilibreur de charge TCP/UDP interne en tant que saut suivant, tenez compte des instructions suivantes :

  • Vous devez configurer les VM de backend ou l'instance de saut suivant pour transférer des paquets depuis d'autres sources (can-ip-forward). Vous pouvez activer le transfert IP par VM au moment de la création de la VM. Pour activer le transfert IP pour des VM créées automatiquement dans un groupe d'instances géré, vous devez activer le transfert IP au niveau du modèle d'instance utilisé par le groupe d'instances. Vous devez ajouter cette modification de configuration à toute configuration du système d'exploitation nécessaire au routage des paquets.

  • Les logiciels exécutés sur la VM de backend ou sur l'instance de saut suivant doivent être correctement configurés. Par exemple, les VM de dispositifs tiers qui agissent en tant que routeurs ou pare-feu doivent être configurées conformément aux instructions du fabricant.

  • Les VM de backend ou l'instance de saut suivant doivent disposer de règles de pare-feu appropriées. Vous devez configurer les règles de pare-feu qui s'appliquent aux paquets en cours d'acheminement. Tenez bien compte des éléments suivants :

    • Les règles de pare-feu d'entrée applicables aux instances qui exécutent des fonctions de routage doivent inclure les adresses IP des sources des paquets routés. La règle implicite d'entrée interdite bloque tous les paquets entrants. Vous devez donc a minima créer des règles de pare-feu personnalisées autorisant certaines entrées.
    • Les règles de pare-feu de sortie applicables aux instances qui exécutent des fonctions de routage doivent inclure les adresses IP des destinations des paquets routés. La règle implicite de sortie autorisée permet cette opération, sauf si vous avez créé une règle de refus du trafic sortant spécifique pour la remplacer.
    • Vérifiez si la VM de backend ou l'instance de saut suivant effectue la traduction d'adresse réseau (NAT, Network Address Translation) lors de la création de vos règles de pare-feu.

    Pour en savoir plus, consultez la section Règles de pare-feu implicites.

Considérations liées aux instances de saut suivant

  • Lorsque vous utilisez une instance en tant que saut suivant (next-hop-instance ou next-hop-address), n'oubliez pas que l'instance est une ressource zonale. La sélection d'une zone implique que vous avez sélectionné une région. Google Cloud ne tient pas compte de la distance régionale pour les routes qui utilisent une instance de saut suivant. Il est donc possible de créer une route qui envoie du trafic vers un saut suivant dans une autre région. Dans ce cas, les coûts de sortie sont plus élevés et une latence risque de se produire au niveau du réseau.

  • Google Cloud n'effectue l'une des validations de base suivantes que lorsque vous créez la route :

    • Si vous spécifiez next-hop-instance, l'instance doit déjà exister.
    • Si vous spécifiez next-hop-address, l'adresse IP doit appartenir à une plage d'adresses IP principale ou secondaire d'un sous-réseau existant.
  • Si, par exemple, vous supprimez une instance ou un sous-réseau ultérieurement, Google Cloud tient toujours compte d'une route qui utilise cette instance comme saut suivant au moment d'évaluer les routes applicables. Cela peut entraîner la suppression de tout ou partie des paquets d'une destination donnée, en fonction des autres routes de votre réseau.

  • De même, en cas de défaillance du logiciel d'une instance de VM (tel que son système d'exploitation ou son processus de routage des paquets), les paquets destinés à cette instance sont supprimés. Pour plus de fiabilité, nous vous conseillons plutôt d'utiliser un équilibreur de charge TCP/UDP interne en tant que saut suivant. Un équilibreur de charge TCP/UDP interne nécessite une vérification de l'état configurée, qui détermine le mode de routage des nouvelles connexions.

  • Le fait de désactiver une interface réseau via la configuration du système d'exploitation invité de l'instance n'implique pas que Google Cloud cesse de considérer cette interface comme le saut suivant d'une route.

Considérations liées aux sauts suivants du tunnel VPN classique

Google Cloud ne tient pas compte de la distance régionale pour les routes qui utilisent un tunnel VPN classique de saut suivant. L'envoi de trafic vers un tunnel VPN classique de saut suivant dans une autre région entraîne des coûts de sortie plus élevés et un risque de latence au niveau du réseau. Il est recommandé d'utiliser des tunnels VPN haute disponibilité ou des tunnels VPN classiques utilisant le routage dynamique.

Étapes suivantes