Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

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
Routes par défaut générées par le système
0.0.0.0/0 pour IPv4
::/0 pour IPv6
default-internet-gateway S'applique à 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
Transmet les paquets à un saut suivant de route statique Pour plus d'informations sur chaque saut suivant de route statique, consultez les caractéristiques des éléments suivants :
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 :
  • Les routes statiques d'un réseau appairé qui utilisent des tags réseau ne sont jamais importées en tant que routes d'appairage personnalisées.
  • Les routes statiques d'un réseau appairé qui utilisent le saut suivant de la passerelle Internet par défaut ne sont jamais importées en tant que routes d'appairage personnalisées.
  • Les routes statiques d'un réseau appairé qui utilisent les sauts suivants de l'équilibreur de charge TCP/UDP interne peuvent s'appliquer à une seule région ou à toutes les régions, selon que l'accès mondial est activé ou non. Pour en savoir plus, consultez la section Considérations liées aux sauts suivants de l'équilibreur de charge TCP/UDP interne.
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.

Routes par défaut générées par le système

Lorsque vous créez un réseau VPC, celui-ci inclut une route par défaut IPv4 générée par le système (0.0.0.0/0). Lorsque vous créez un sous-réseau à double pile avec une plage d'adresses IPv6 externe dans un réseau VPC, une route IPv6 par défaut générée par le système (::/0) est ajoutée à ce réseau si elle n'existe pas déjà. Les routes par défaut répondent aux objectifs suivants :

Google Cloud n'utilise une route par défaut que si une route avec 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 la remplacer par une route statique personnalisée dont le saut suivant est une machine virtuelle proxy.

  • IPv4 et IPv6 : 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 IPv4 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. Si le sous-réseau comporte une plage IPv6, il existe une route de sous-réseau correspondant à la plage d'adresses IPv6. Pour en savoir plus sur les plages d'adresses IP de sous-réseau, consultez la section Sous-réseaux.

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.

Interactions avec les routes statiques personnalisées

Les routes de sous-réseau locales et les routes d'appairage de sous-réseau importées interagissent avec les routes statiques personnalisées des manières suivantes :

  • Google Cloud ne vous permet pas de créer une route statique personnalisée ayant une destination identique ou plus étroite qu'une route de sous-réseau ou une route d'appairage de sous-réseau. Par exemple, si une route de sous-réseau locale ou une route d'appairage de sous-réseau existe pour la destination 10.70.1.0/24, vous ne pouvez pas créer de route statique personnalisée pour 10.70.1.0/24, 10.70.1.0/25, 10.70.1.128/25 ou toute autre destination comprise dans 10.70.1.0/24.

  • En revanche, Google Cloud ne vous permet pas de créer une nouvelle route de sous-réseau ou d'appairage de sous-réseau dont la destination correspond exactement à une route statique personnalisée existante ou est plus large que celle-ci (la contiendrait). Par exemple, si votre réseau VPC dispose d'une route statique personnalisée pour la destination 10.70.1.128/25, Google Cloud interdit la création de toute route de sous-réseau ou d'appairage de sous-réseau avec une plage d'adresses IP de sous-réseau principale ou secondaire de 10.70.1.128/25, 10.70.1.0/24 ou de toute autre plage contenant toutes les adresses IP de 10.70.1.128/25.

Interactions avec les routes dynamiques personnalisées

Les routes de sous-réseau locales et les routes d'appairage de sous-réseau importées interagissent avec les routeurs Cloud des manières suivantes :

  • Lorsque les routeurs Cloud apprennent les préfixes qui correspondent exactement à la destination d'une route de sous-réseau ou d'appairage, Google Cloud ignore ces routes dynamiques personnalisées. Par exemple, si une route de sous-réseau ou d'appairage de sous-réseau existe pour la destination 10.70.1.0/24 et qu'un ou plusieurs routeurs Cloud du réseau VPC reçoivent le préfixe 10.70.1.0/24 via BGP, Google Cloud utilise la route de sous-réseau ou la route d'appairage de sous-réseau et ignore la route dynamique personnalisée en conflit.

  • Lorsque les routeurs Cloud apprennent les préfixes qui sont compris dans la destination d'une route de sous-réseau ou d'appairage de sous-réseau, Google Cloud ignore ces routes dynamiques personnalisées. Par exemple, si une route de sous-réseau ou d'appairage de sous-réseau existe pour la destination 10.70.1.0/24 et qu'un ou plusieurs routeurs Cloud du réseau VPC reçoivent le préfixe 10.70.1.0/25 via BGP, Google Cloud utilise la route de sous-réseau ou d'appairage de sous-réseau et ignore la route dynamique personnalisée en conflit.

Cycle de vie des routes de sous-réseau

Les routes de sous-réseau sont créées, mises à jour et supprimées lorsque vous créez, modifiez ou supprimez des sous-réseaux ou leurs plages d'adresses IP de sous-réseau :

  • 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 connexions réseau suivantes :

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).

Toutefois, la destination d'une route dynamique peut contenir (comporter un masque de sous-réseau plus petit que) la plage d'adresses IP d'un sous-réseau. Par exemple, si la plage d'adresses IP de votre sous-réseau est 10.10.10.0/24, vous pouvez disposer d'une route dynamique avec la destination 10.10.10.0/23. Si l'adresse IP de destination d'un paquet ne correspond pas à la destination de la route de sous-réseau, le paquet est envoyé au saut suivant de la route dynamique. La destination la plus large possible est 0.0.0.0/0.

Routes d'appairage de sous-réseau

Pour certaines ressources, les routes d'appairage de sous-réseau définissent des chemins d'accès 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 utilisée en mode privé. Vous pouvez configurer un pair pour importer les routes de sous-réseau qui utilisent des adresses IP publiques 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 de sous-réseaux 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.

  • Des chemins de retour spéciaux s'appliquent lors du réacheminement vers les équilibreurs de charge proxy, les systèmes de vérification d'état et d'autres services Google. Pour en savoir plus, consultez la section Chemins de retour pour les équilibreurs de charge. Ces routes ne sont affichées dans aucune table de routage.

  • 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.

  • Les routes dynamiques s'appliquent aux instances selon 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.

Ordre de routage

Le processus suivant modélise le comportement de sélection des routes du réseau VPC. En commençant par l'ensemble de routes applicables (comme décrit dans la section précédente), vous pouvez modéliser les décisions de sélection de route prises par Google Cloud pour un paquet en suivant ce processus.

  1. Destination la plus spécifique : Google Cloud détermine d'abord laquelle des routes applicables présente la destination la plus spécifique contenant l'adresse IP de destination du paquet. Google Cloud ignore toutes les autres routes avec des destinations moins spécifiques. Par exemple, 10.240.1.0/24 est une destination plus spécifique que 10.240.0.0/16. La destination la plus spécifique peut être n'importe quel type de route. Cependant, les routes de sous-réseau, les routes d'appairage de sous-réseau et les chemins de retour spéciaux sont les plus spécifiques par définition.

  2. Après cette étape, votre modèle de sélection de route ne contient que les routes ayant les destinations les plus spécifiques.

  3. Sauts suivants dans un seul réseau VPC : cette étape ne s'applique que si le réseau VPC dont vous modélisez le comportement de route est connecté à un ou plusieurs réseaux VPC à l'aide de l'appairage de réseaux VPC. Avec l'appairage de réseaux VPC, des routes personnalisées avec des destinations identiques peuvent exister dans plusieurs des réseaux du groupe d'appairage. L'exigence modélisée à cette étape est que Google Cloud sélectionne les sauts suivants qui se trouvent tous dans un seul réseau VPC.

    • Si une ou plusieurs routes de votre modèle de routage présentent des sauts suivants dans le réseau VPC que vous modélisez, ignorez toutes les routes qui présentent des sauts suivants dans les réseaux appairés. Dans ce cas, Google Cloud n'utilise que les sauts suivants dans le réseau VPC local, même si les sauts suivants pour la même destination existent dans un ou plusieurs réseaux VPC appairés.

    • Si aucune des routes de votre modèle de routage ne comporte de sauts suivants dans le réseau VPC que vous modélisez, et que tous les sauts suivants existent dans plusieurs réseaux appairés, Google Cloud utilise un algorithme interne pour sélectionner un seul réseau pair avec les sauts suivants pour les destinations les plus spécifiques. La priorité des routes n'est pas prise en compte à ce stade. En outre, si votre réseau VPC est appairé à un nouveau réseau VPC ou s'il se déconnecte d'un réseau VPC appairé existant, le réseau VPC sélectionné pour les sauts suivants peut changer.

    Après cette étape, votre modèle de sélection de route ne contient que les routes ayant les destinations les plus spécifiques et les sauts suivants pour ces routes se trouvent tous dans un seul réseau VPC.

  4. Ignorer les routes statiques personnalisées dont les sauts suivants sont indisponibles : cette étape modélise deux situations dans lesquelles Google Cloud ignore les sauts suivants qu'il considère comme indisponibles. Cette étape ne s'applique qu'aux routes statiques personnalisées. Les routes dynamiques personnalisées sont automatiquement ajoutées et supprimées à l'aide d'annonces BGP.

    • Google Cloud ignore chaque instance de VM du saut suivant (next-hop-instance ou next-hop-address) si la VM du saut suivant a été arrêtée ou supprimée. Pour en savoir plus, consultez le paragraphe Comportement lorsque des instances sont arrêtées ou supprimées de la section Considérations liées aux instances de saut suivant. Si votre modèle de routage contient des routes statiques dont les VM de saut suivant sont arrêtées ou supprimées, supprimez ces routes de votre modèle.

    • Google Cloud ignore chaque route statique personnalisée qui utilise un tunnel VPN classique de saut suivant si le tunnel ne dispose pas d'une association de sécurité de phase 1 (IKE). Pour en savoir plus, consultez la page Ordre de priorité des routes dans la documentation sur les VPN classiques. Si votre modèle de routage contient des routes statiques dont les sauts suivants sont des tunnels VPN classiques sans associations de sécurité IKE établies, supprimez ces routes de votre modèle.

  5. Ignorer les routes à faible priorité : cette étape modélise la manière dont Google Cloud supprime toutes les routes, à l'exception de celles dont la priorité est la plus élevée.

    Après cette étape, votre modèle de sélection de route peut être vide ou contenir une ou plusieurs routes. Si votre modèle contient des routes, toutes les routes présentent toutes les caractéristiques suivantes :

    • Destinations identiques et les plus spécifiques
    • Sauts suivants dans un seul réseau VPC (le réseau VPC local ou un seul réseau VPC appairé)
    • Sauts suivants qui ne sont pas considérés comme indisponibles
    • Priorités identiques et les plus élevées
  6. Ne sélectionner que la catégorie de préférence la plus adaptée : Google Cloud évite le routage ECMP entre différents types de sauts suivants. Vous pouvez modéliser ce comportement en tenant compte du système de catégorie des préférences décrit dans le tableau suivant. Cette étape permet d'affiner votre modèle de routage pour qu'il ne contienne que des routes ayant le même type ou la même combinaison de type de route et de saut suivant.

    Catégorie de préférence Combinaison de catégorie et de saut suivant
    Premier choix (priorité la plus élevée) Routes statiques personnalisées avec une instance de saut suivant en cours d'exécution (next-hop-instance ounext-hop-address ) ou un tunnel VPN classique de saut suivant établi par une association de sécurité IKE.
    Deuxième choix Routes dynamiques personnalisées apprises à partir de n'importe quelle session BGP d'un routeur Cloud.
    Troisième choix Une seule route statique personnalisée avec un équilibreur de charge TCP/UDP interne
    Google Cloud utilise un algorithme interne pour sélectionner un seul équilibreur de charge TCP/UDP interne de saut suivant en ignorant les autres sauts suivants de l'équilibreur de charge TCP/UDP interne avec la même priorité. Pour plus d'informations, consultez le paragraphe "Même destination et plusieurs équilibreurs de charge TCP/UDP internes de saut suivant" de la section Considérations liées aux sauts suivants de l'équilibreur de charge TCP/UDP interne.
    Quatrième choix Une route statique personnalisée utilisant le saut suivant default-internet-gateway.

    À la fin de cette étape, il pourrait y avoir zéro route, une route, deux routes ou plusieurs routes dans le modèle de routage.

  7. Envoi ou suppression de paquets : ce qui se produit dépend du nombre de routes restant dans le modèle de routage :

    • Si le modèle de routage est vide, le paquet est supprimé avec une erreur de destination ICMP ou de réseau inaccessible. Google Cloud ne revient jamais à une route moins spécifique qui pourrait avoir un saut suivant opérationnel.

    • Si le modèle de routage contient une seule route, Google Cloud envoie le paquet au saut suivant. Pour les sauts suivants de VM, Google Cloud ne vérifie pas que le saut suivant de la VM peut traiter des paquets. Pour en savoir plus, consultez la section Remarques courantes sur les sauts suivants de l'équilibreur de charge TCP/UDP interne et de l'instance. Si la route unique est une route de sous-réseau ou une route d'appairage de sous-réseau et qu'il n'existe aucune ressource Google Cloud à l'adresse IP de destination du paquet, le paquet est supprimé.

    • Si le modèle de routage contient deux routes ou plus, les routes partagent la même destination la plus spécifique et sont situées dans un réseau VPC unique. Leurs sauts suivants ne sont pas considérés comme indisponibles, elles partagent la même priorité la plus élevée et appartiennent à une seule combinaison de type de route et de saut suivant (catégorie de préférence). Google Cloud répartit les paquets entre les sauts suivants en mettant en œuvre un routage ECMP (Equal-Cost Multi-Path) à l'aide d'un algorithme de hachage. Les calculs de hachage sont effectués pour chaque paquet au moment de l'envoi, en fonction du nombre actuel de sauts suivants. Google Cloud utilise un hachage à cinq tuples si le paquet contient des informations de port ; sinon, il utilise un hachage à trois tuples. Si le modèle de routage change à mesure que les paquets suivants sont envoyés, Google Cloud peut diriger ces paquets vers un saut suivant différent, même si le hachage est identique.

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 d'é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.

Accès au VPC sans serveur

Une route pour 35.199.224.0/19 accepte l'accès au VPC sans serveur. Le réseau de production de Google n'accepte pas les routes pour 35.199.224.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). Toutefois, la destination d'une route statique peut contenir (comporter un masque de sous-réseau plus petit que) la plage d'adresses IP d'un sous-réseau. Par exemple, si la plage d'adresses IP de votre sous-réseau est 10.10.10.0/24, vous pouvez disposer d'une route statique avec la destination 10.10.10.0/23. Si l'adresse IP de destination d'un paquet ne correspond pas à la destination de la route de sous-réseau, le paquet est envoyé au saut suivant de la route statique. 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.

Remarques courantes sur les sauts suivants de l'équilibreur de charge TCP/UDP interne et de l'instance

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 qu'elles transmettent des paquets issus de n'importe quelle adresse IP source. Pour configurer le transfert, activez le transfert IP (can-ip-forward) par VM lors de la création de la VM. Pour les VM créées automatiquement dans un groupe d'instances géré, activez le transfert IP dans le 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.

  • Du point de vue de la destination d'un paquet, la région source du paquet est la région qui contient la VM de backend ou l'instance de saut suivant. Par exemple, les paquets traités par des VM de backend ou des instances de saut suivant dans us-west1 peuvent être envoyés à des destinations qui ne sont accessibles que dans us-west1, même si la source des paquets d'origine se trouve en dehors de us-west1. Voici des exemples de ressources de destination qui ne sont accessibles que si les ressources sources et de destination se trouvent dans la même région :

    • Équilibreurs de charge TCP/UDP internes avec accès mondial désactivé
    • Équilibreurs de charge HTTP(S) internes régionaux
    • Équilibreurs de charge proxy TCP régionaux internes

Considérations liées aux instances de saut suivant

  • Saut suivant par nom d'instance (next-hop-instance) : si la route et l'instance de saut suivant se trouvent dans le même projet, vous pouvez spécifier une instance de saut suivant en utilisant son nom et sa zone. Avant de pouvoir créer la route, Google Cloud exige qu'une instance de saut suivant existe et réponde à tous les critères suivants :

    • Le nom de l'instance doit correspondre au nom de la VM du saut suivant de la route.
    • La zone de l'instance doit correspondre à la zone du saut suivant de la route.
    • L'instance doit disposer d'une interface réseau sur le réseau VPC de la route.

    Google Cloud met automatiquement à jour une route dont le saut suivant est spécifié par next-hop-instance dans les situations suivantes :

    • Lorsque l'adresse IPv4 de l'instance de saut suivant change
    • Lorsque vous remplacez l'instance de saut suivant, tant que l'instance de remplacement répond aux mêmes critères que l'instance qui a été remplacée
  • Adresse IP interne de l'instance de saut suivant (next-hop-address) : vous pouvez spécifier une instance de saut suivant à l'aide d'une adresse IPv4 interne associée à une interface réseau du réseau VPC de la route. Avant de pouvoir créer la route, Google Cloud exige qu'une instance de saut suivant existe et réponde à tous les critères suivants :

    • L'instance doit disposer d'au moins une interface réseau sur le réseau VPC de la route.
    • L'interface réseau de l'instance doit avoir une adresse IPv4 interne correspondant à l'adresse de saut suivant de la route. L'adresse IPv4 interne peut être l'adresse IPv4 principale de l'interface réseau ou une adresse IPv4 d'une plage d'adresses IP d'alias sur l'interface réseau.

    Google Cloud met automatiquement à jour une route dont le saut suivant est spécifié par next-hop-address lorsque l'adresse IPv4 est déplacée vers une autre VM, à condition que la VM de remplacement réponde aux critères ci-dessus.

  • Sauts suivants dans un projet de service VPC partagé : si vous devez créer une route dans un réseau VPC partagé dont l'instance de saut suivant se trouve dans un projet de service, vous devez spécifier le saut suivant à l'aide de next-hop-address. Vous ne pouvez pas spécifier le saut suivant à l'aide de next-hop-instance.

  • Coûts et latence entre régions : lorsque vous utilisez une VM en tant que saut suivant, le saut suivant est situé dans une zone d'une région. La route qui utilise le saut suivant est disponible pour toutes les instances du même réseau VPC ou pour sélectionner des instances avec un tag réseau correspondant. Google Cloud ne tient pas compte de la distance régionale pour les routes qui utilisent une instance comme saut suivant. Il est donc possible de créer une route qui envoie du trafic vers une VM de saut suivant dans une autre région. L'envoi de paquets d'une région à une autre ajoute des coûts de sortie et entraîne une latence du réseau.

  • Aucune vérification de l'état, aucune validation de configuration : Google Cloud ne vérifie jamais si une instance de saut suivant répond à toutes les exigences décrites dans la section Remarques courantes sur les sauts suivants de l'équilibreur de charge TCP/UDP interne et de l'instance. Le fait de désactiver l'interface réseau de la VM en configurant le système d'exploitation invité de l'instance n'entraîne pas le fait que Google Cloud ignore l'instance de saut suivant. Pour plus de fiabilité, utilisez plutôt un équilibreur de charge TCP/UDP interne en tant que saut suivant.

  • Aucun hachage symétrique lors de la connexion de deux réseaux VPC : Google Cloud n'offre pas de hachage symétrique lors de l'utilisation d'au moins deux VM de saut suivant ayant plusieurs interfaces réseau dans une configuration qui répond à tous les critères suivants :

    • Les VM disposent d'une interface réseau dans un réseau VPC et d'une autre interface dans un deuxième réseau VPC.
    • Chaque réseau VPC contient un ensemble d'au moins deux routes statiques personnalisées pour la même destination, avec la même priorité, où chaque route de l'ensemble fait référence à une unique VM de saut suivant.

    Si vous utilisez au moins deux VM avec plusieurs interfaces pour connecter des réseaux VPC et que vous avez besoin que la même VM traite les paquets pour une connexion donnée dans les deux sens, vous devez utiliser un équilibreur de charge TCP/UDP interne de saut suivant. L'équilibreur de charge TCP/UDP interne de saut suivant est nécessaire, car il offre un hachage symétrique. Pour en savoir plus sur le hachage symétrique, consultez la documentation sur le hachage symétrique dans les équilibreurs de charge TCP/UDP internes en tant que sauts suivants.

  • Comportement lorsque des instances sont arrêtées ou supprimées : Google Cloud ne vous empêche pas d'arrêter ou de supprimer une instance de saut suivant, quelle que soit la manière dont vous l'avez spécifiée (à l'aide de next-hop-instance ou next-hop-address). Google Cloud supprime toutes les instances arrêtées ou supprimées lors de l'étape de classification des préférences de l'ordre de routage. Les exemples suivants clarifient ce comportement :

    • Supposons que vous disposez de trois routes statiques personnalisées pour la destination 192.168.168.0/24 : une avec la priorité 10 dont la VM de saut suivant est arrêtée, une deuxième avec la priorité 20 dont la VM de saut suivant est en cours d'exécution et une troisième avec la priorité 30 dont la VM de saut suivant est en cours d'exécution. Google Cloud envoie des paquets à la deuxième VM, même si sa route est moins prioritaire que la route dont la VM de saut suivant est arrêtée. Si vous démarrez la VM pour le premier saut, Google Cloud utilise la première route.

    • Supposons que vous disposiez de trois routes statiques personnalisées comme décrit précédemment, mais que toutes les VM de saut suivant soient arrêtées ou supprimées. Les paquets sont supprimés même s'il existe des routes moins spécifiques avec des sauts suivants fonctionnels, car Google Cloud prend en considération la spécificité de destination avant de déterminer si une VM de saut suivant est en cours d'exécution.

Considérations liées aux sauts suivants de l'équilibreur de charge TCP/UDP interne

  • Effet de l'accès mondial : les routes statiques personnalisées utilisant les sauts suivants de l'équilibreur de charge TCP/UDP interne sont programmées dans toutes les régions. La possibilité d'utilisation du saut suivant dépend du paramètre d'accès mondial de l'équilibreur de charge. Lorsque l'accès mondial est activé, le saut suivant de l'équilibreur de charge est accessible dans toutes les régions du réseau VPC. Lorsque l'accès mondial est désactivé, le saut suivant de l'équilibreur de charge n'est accessible que dans la même région que l'équilibreur de charge. Lorsque l'accès mondial est désactivé, les paquets envoyés depuis une autre région vers une route utilisant un équilibreur de charge TCP/UDP interne de saut suivant sont supprimés.
  • Lorsque tous les backends sont considérés comme non opérationnels. Lorsque tous les backends d'un équilibreur de charge TCP/UDP interne échouent aux vérifications d'état, les routes qui utilisent ce saut suivant d'équilibreur de charge TCP/UDP interne sont toujours en vigueur. Les paquets traités par la route sont envoyés à l'un des backends d'équilibreur de charge de saut suivant selon la distribution du trafic.

  • Les règles de transfert qui utilisent une adresse IP interne commune (--purpose=SHARED_LOADBALANCER_VIP) ne sont pas compatibles. L'équilibreur de charge TCP/UDP interne de saut suivant et les règles de transfert de l'équilibreur de charge TCP/UDP interne avec une adresse IP commune sont des caractéristiques exclusives. Un équilibreur de charge TCP/UDP interne de saut suivant doit utiliser une adresse IP unique à la règle de transfert de l'équilibreur de charge afin que seul un service de backend (un équilibreur de charge) soit référencé sans ambiguïté. Il est possible que les règles de transfert utilisent une adresse IP interne commune pour faire référence à différents services de backend (différents équilibreurs de charge TCP/UDP internes).

  • Même destination et plusieurs équilibreurs de charge TCP/UDP internes de saut suivant. Si vous créez plusieurs routes statiques personnalisées avec la même destination à l'aide des sauts suivants de l'équilibreur de charge TCP/UDP interne, Google Cloud ne répartit jamais le trafic entre les sauts suivants de l'équilibreur de charge à l'aide de ECMP. Si les routes ont des priorités uniques, Google Cloud utilise l'équilibreur de charge TCP/UDP interne de saut suivant de la route ayant la priorité la plus élevée. Si les routes ont des priorités égales, Google Cloud ne sélectionne qu'un seul équilibreur de charge TCP/UDP interne de saut suivant. Dans ce dernier cas, comme illustré dans le diagramme ci-dessous, Google Cloud utilise un algorithme interne déterministe pour sélectionner une seule règle de transfert de saut suivant (forwarding-rule-a), en ignorant les autres routes ayant la même priorité.

    Google Cloud sélectionne un seul saut suivant lorsque les routes statiques avec différents sauts suivants de l'équilibreur de charge TCP/UDP interne ont la même priorité et la même destination.
  • Plusieurs destinations et le même équilibreur de charge TCP/UDP interne de saut suivant.

    Avec des tags d'instance :

    Si vous appliquez des tags d'instance (également appelés tags réseau), vous pouvez utiliser le même équilibreur de charge TCP/UDP interne de saut suivant pour plusieurs routes statiques personnalisées. avec la même destination et la même priorité.

    Sans tags d'instance : sans tags d'instance, vous ne pouvez pas créer plusieurs routes statiques personnalisées ayant la même combinaison de destination, de priorité et d'équilibreur de charge TCP/UDP interne de saut suivant. Par exemple, route-x, route-y et route-z peuvent être créés, mais route-x-copy ne peut pas être créé.

    Les routes statiques sans tag d'instance ne peuvent pas être créées avec la même destination, la même priorité et le même saut suivant de l'équilibreur de charge TCP/UDP interne.
  • Tags d'instance.

    Vous pouvez spécifier des tags d'instance (également appelés tags réseau) pour que la route de saut suivant ne s'applique qu'aux instances clientes qui ont été configurées avec le tag. Cela vous permet de sélectionner les instances clientes dotées d'une route de saut suivant avec tags et l'ensemble des appareils vers lesquels acheminer le trafic.

    Vous n'avez pas besoin de répartir les différentes instances clientes dans des réseaux VPC distincts. Chacune d'elles pointe vers son équilibreur de charge TCP/UDP interne préféré afin d'interfacer un ensemble d'appareils.

  • Plusieurs routes vers le même préfixe de destination. Avec les tags, vous pouvez spécifier plusieurs routes vers la même destination avec différents équilibreurs de charge internes en tant que sauts suivants. Vous pouvez utiliser des propriétés ou des tags différents pour ces mêmes routes de destination.

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

  • Coûts et latence entre régions : 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 un tunnel VPN haute disponibilité avec routage dynamique, car cette configuration tient compte de la distance régionale.

  • Comportement lorsque les tunnels VPN classiques sont indisponibles : les routes statiques personnalisées dont les sauts suivants sont des tunnels VPN classiques ne sont pas automatiquement supprimées lorsque les tunnels VPN classiques sont indisponibles. Pour plus de détails sur ce qui se passe lorsque les tunnels sont indisponibles, consultez le cas où les tunnels sont indisponibles dans la documentation VPN classique.

Étapes suivantes