Routes statiques

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

Pour obtenir une présentation générale des routes dans Google Cloud, consultez la présentation des routes.

Éléments à prendre en compte pour créer des routes statiques

Vous pouvez créer des routes statiques de deux manières :

• Vous pouvez créer des routes statiques manuellement à l'aide de Google Cloud Console, de gcloud compute routes create ou de l'API routes.insert.

• Si vous utilisez la console Google Cloud pour créer un tunnel VPN classique qui n'utilise pas le routage dynamique, Cloud VPN peut créer automatiquement des routes statiques correspondantes. Pour en savoir plus, consultez la section Réseaux et options de routage pour les tunnels.

Vous pouvez échanger des routes statiques avec un réseau VPC appairé, comme décrit dans la section Options d'échange de routes statiques personnalisées de la documentation sur l'appairage de réseaux VPC.

Paramètres des routes

Les routes statiques sont compatibles avec les attributs 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.

• Saut suivant. le prochain saut identifie la ressource réseau à laquelle les paquets sont envoyés. Tous les types de prochains sauts sont compatibles avec les destinations IPv4, et certains d'entre eux sont compatibles avec les destinations IPv6. Pour en savoir plus, consultez Prochains sauts et caractéristiques.

• Plage de destination. La plage de destination est une notation CIDR IPv4 ou IPv6 unique.

  Les destinations des routes statiques doivent respecter les règles décrites dans la section Interactions avec les routes statiques et Interactions des routes de sous-réseau et des routes statiques. La destination la plus large possible pour une route statique IPv4 est 0.0.0.0/0. La destination la plus large possible pour une route statique IPv4 est ::/0.

• Priorité. des nombres inférieurs indiquent une priorité plus élevée. La priorité la plus élevée possible est 0, et la priorité la plus faible est 65,535.

• Tags réseau. vous pouvez rendre une route statique applicable uniquement à certaines instances de VM du réseau VPC identifiées par un tag réseau. Si vous ne spécifiez pas de tag réseau, Google Cloud rend la route statique applicable à toutes les instances du réseau. Les routes statiques avec des tags ne sont jamais échangées lors de l'utilisation de l'appairage de réseaux VPC.

Prochains sauts et caractéristiques

Le tableau suivant récapitule la compatibilité des caractéristiques des routes statiques par type de prochain saut :

Projet et réseau du prochain saut

Le prochain saut d'une route statique est associé à la fois à un réseau VPC et à un projet :

• Réseau : sauf indication contraire dans le tableau ci-dessous, le réseau VPC du prochain saut doit correspondre au réseau VPC de la route.

• Projet : sauf indication contraire dans le tableau ci-dessous, le prochain saut doit être situé dans le projet contenant le réseau VPC du prochain saut (un projet autonome ou un projet hôte de VPC partagé). Certains prochains sauts peuvent être situés dans des projets de service de VPC partagé.

Remarques courantes sur les instances et les équilibreurs de charge réseau passthrough internes utilisables comme sauts suivants

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

Équilibreur de charge réseau passthrough interne utilisé comme saut suivant fait référence à une route statique dont le saut suivant est un équilibreur de charge réseau passthrough interne (next-hop-ilb).

Lorsque vous configurez le routage basé sur une instance ou lorsque vous configurez un équilibreur de charge réseau passthrough 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.

• La région source d'un paquet envoyé par une VM de backend ou une instance de prochain saut est la région où se trouve la VM de backend ou l'instance de prochain saut. Par exemple, les paquets traités par des VM de backend ou des instances de prochain saut dans us-west1 peuvent être envoyés à des destinations qui ne sont accessibles que dans us-west1, même si la VM de backend ou l'instance de prochain saut a initialement reçu le paquet d'une ressource située dans une région différente de us-west1. Voici des exemples de ressources accessibles uniquement dans la même région qu'une VM envoyant un paquet :

  • Équilibreurs de charge réseau passthrough internes, équilibreurs de charge d'application internes et équilibreurs de charge réseau proxy internes régionaux avec accès mondial désactivé
  • Tunnels Cloud VPN, rattachements de VLAN Cloud Interconnect et VM d'appliance de routeur de connectivité réseau si le réseau VPC utilise le routage dynamique régional

Considérations liées aux instances de saut suivant

• Prochain saut par nom et zone d'instance (next-hop-instance) : lorsque vous créez une route statique qui comporte une instance de prochain saut spécifiée par un nom et une zone, Google Cloud requiert qu'une instance portant ce nom existe dans la zone spécifiée et réponde aux critères suivants :

  • L'instance est située dans le même projet que la route.
  • L'instance possède une interface réseau (carte d'interface réseau) dans le réseau VPC de la route (et non dans un réseau VPC appairé).

  Tant que la route statique existe, les règles suivantes s'appliquent:

  • Google Cloud met automatiquement à jour la programmation du prochain saut dans les cas suivants :

    • L'adresse IPv4 interne principale de l'instance de prochain saut change.
    • Vous remplacez l'instance de prochain saut et l'instance de remplacement porte le même nom, se trouve dans la même zone et le même projet, et dispose d'une interface réseau dans le réseau VPC de la route.

  • Google Cloud ne met pas à jour la programmation du prochain saut dans les cas suivants :

    • Lorsque l'instance est supprimée.
    • La plage d'adresses IPv6 attribuée à la carte d'interface réseau de l'instance change.
    • Lorsque l'adresse IPv4 ou IPv6 de l'instance n'est pas attribuée.

• Adresse IP de l'instance de prochain saut (next-hop-address) : les adresses IP de VM de prochain saut valides sont les suivantes :
  • Adresse IPv4 interne principale d'une interface réseau de VM.
  • Toute adresse IPv6 interne ou externe de la plage d'adresses IPv6 /96 attribuée à une interface réseau de VM.

  Lorsque vous créez une route statique avec une instance de prochain saut spécifiée par une adresse IP, Google Cloud accepte toute adresse IP attribuée à une VM qui correspond à la plage de sous-réseau d'un sous-réseau du même réseau VPC que la route. Toutefois, Google Cloud ne programme la route que si l'adresse de prochain saut est une adresse IP de VM de prochain saut valide. Par exemple, si vous créez une route et spécifiez le prochain saut en tant qu'adresse IP provenant d'une plage d'adresses IP d'alias, la route est créée. Toutefois, comme les adresses IP d'alias ne sont pas des adresses IP de VM de prochain saut valides, la route n'est pas programmée.

  Google Cloud met automatiquement à jour la programmation du prochain saut si l'adresse IP du prochain saut est déplacée vers une autre VM, si elle reste une adresse IP valide de VM de prochain saut.

  Lorsque vous spécifiez une instance de prochain saut par adresse IP, les paquets sont acheminés vers l'interface réseau de l'instance, et non vers l'adresse IP spécifique.

• Instances de prochain saut dans les projets de service de VPC partagé : lorsque vous spécifiez une VM de prochain saut par adresse IP, la VM peut être située soit dans le même projet que la route (projet autonome ou projet hôte de VPC partagé), soit dans un projet de service de VPC partagé. Lorsque vous spécifiez une VM de prochain saut par nom et zone d'instance, celle-ci doit être située dans le même projet que la route et le réseau VPC (projet autonome ou projet hôte de VPC partagé).

• Coûts et latence entre régions : lorsque vous utilisez une VM en tant que prochain saut, le prochain saut 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 prochain saut. Il est donc possible de créer une route qui envoie du trafic vers une VM de prochain saut dans une autre région. L'envoi de paquets d'une région à une autre ajoute des coûts de transfert de données sortant 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 prochain saut répond à toutes les exigences décrites dans la section Remarques courantes sur les instances et équilibreurs de charge réseau internes passthrough utilisés comme prochains sauts. 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 prochain saut.

• 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 prochain saut 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 avez besoin du hachage symétrique, qui n'est compatible qu'avec les équilibreurs de charge réseau passthrough internes utilisés en tant que prochain saut. Pour en savoir plus, consultez la section Hachage symétrique.

• Comportement lors de l'arrêt ou de la suppression d'instances : Google Cloud ne vous empêche pas d'arrêter ou de supprimer une VM de prochain saut d'une route statique (spécifiée par nom et zone ou adresse interne). Lorsqu'une VM de prochain saut n'est pas en cours d'exécution, le routage dépend de si d'autres routes existent pour la même destination et comportent des sauts suivants en cours d'exécution. Pour illustrer ce comportement, examinons les exemples suivants:

  • Vous disposez des routes et des états de VM suivants:

    • route-a, destination 192.168.168.0/24, priorité 10, VM de prochain saut vm-a arrêtée
    • route-b, destination 192.168.168.0/24, priorité 20, VM de prochain saut vm-b en cours d'exécution
    • route-c, destination 192.168.168.0/24, priorité 30, VM de prochain saut vm-c en cours d'exécution

    Dans cet exemple, les paquets dont les destinations correspondent à 192.168.168.0/24 sont envoyés au prochain saut vm-b, car le prochain saut vm-a de la route-a ayant la priorité la plus élevée n'est pas en cours d'exécution. Cela se produit, car l'étape Ignorer les routes statiques et dynamiques avec des sauts suivants inutilisables précède l'étape Ignorer les routes à faible priorité dans l'ordre de routage Google Cloud.

  • Vous disposez des routes et des états de VM suivants:

    • route-x, destination 192.168.168.0/24, priorité 10, VM de prochain saut vm-x arrêtée
    • route-y, destination 192.168.168.0/24, priorité 20, VM de prochain saut vm-y arrêtée
    • route-z, destination 192.168.0.0/16, priorité 0, VM de prochain saut vm-z en cours d'exécution

    Dans cet exemple, les paquets dont les destinations correspondent à 192.168.168.0/24 sont supprimés, car les VM de saut suivant pour les deux routes 192.168.168.0/24 (route-x et route-y) ne sont pas en cours d'exécution, même si une route pour la destination 192.168.0.0/16 plus large existe (route-z) avec une VM de saut suivant en cours d'exécution. Cela se produit, car l'étape destination la plus spécifique précède l'étape Ignorer les routes statiques et dynamiques avec des sauts suivants inutilisables dans l'ordre de routage Google Cloud.

Considérations liées aux équilibreurs de charge réseau passthrough internes utilisés en tant que saut suivant

• Règles de transfert compatibles. Google Cloud n'accepte que les règles de transfert des équilibreurs de charge réseau passthrough internes utilisés comme prochain saut. Google Cloud n'est pas compatible avec les règles de transfert de prochain saut utilisées par d'autres équilibreurs de charge, transferts de protocole ou points de terminaison Private Service Connect.

• Méthodes de spécification, réseau et projet des règles de transfert. Vous pouvez spécifier une règle de transfert de prochain saut à l'aide de l'une des trois méthodes suivantes. La méthode de spécification que vous utilisez détermine si le réseau de la règle de transfert doit correspondre au réseau de la route et le projet dans lequel se trouve la règle de transfert.

  Choisissez l'une des méthodes suivantes et assurez-vous que la version IP de votre règle de transfert correspond à la version IP de la route statique que vous créez:

  • Par nom (--next-hop-ilb) et région (--next-hop-ilb-region) de règle de transfert : lorsque vous spécifiez une règle de transfert de prochain saut par nom et par région, le réseau de la règle de transfert doit correspondre au réseau VPC de la route. La règle de transfert doit se trouver dans le projet qui contient le réseau de la règle de transfert (projet autonome ou projet hôte de VPC partagé).

  • Par lien de ressource de règle de transfert : le lien de ressource d'une règle de transfert utilise le format /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, où PROJECT_ID est l'ID du projet contenant la règle de transfert, REGION est la région de la règle de transfert et FORWARDING_RULE_NAME est le nom de la règle de transfert. Lorsque vous spécifiez une règle de transfert de prochain saut par son lien de ressource, le réseau de la règle de transfert doit correspondre au réseau VPC de la route. La règle de transfert peut se trouver soit dans le projet contenant le réseau de la règle de transfert (projet autonome ou projet hôte de VPC partagé), soit dans un projet de service de VPC partagé.

  • Par adresse IP de règle de transfert: lorsque vous spécifiez une règle de transfert de prochain saut par son adresse IPv4 ou IPv6 (preview), le réseau de la règle de transfert peut être soit le réseau VPC de la route, soit un réseau VPC appairé. La règle de transfert peut se trouver soit dans le projet contenant le réseau de la règle de transfert (projet autonome ou projet hôte de VPC partagé), soit dans un projet de service de VPC partagé.

• Effet de l'accès mondial : Les routes statiques personnalisées utilisant des équilibreurs de charge réseau passthrough internes en tant que saut suivant 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 réseau passthrough interne comme 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 réseau passthrough interne échouent aux vérifications d'état, les routes qui utilisent cet équilibreur de charge en tant que saut suivant restent 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. Les équilibreurs de charge réseau passthrough internes utilisés en tant que saut suivant et les règles de transfert de l'équilibreur de charge réseau passthrough interne avec adresse IP commune sont des caractéristiques exclusives. Un équilibreur de charge réseau passthrough interne utilisé en tant que saut suivant doit utiliser une adresse IP propre à la règle de transfert de l'équilibreur de charge, de sorte qu'un seul service de backend (un équilibreur de charge) soit clairement référencé. 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 réseau passthrough internes).

• Plusieurs routes avec les mêmes destinations et priorités, mais différents équilibreurs de charge réseau passthrough internes utilisés en tant que prochain saut. Google Cloud ne distribue jamais le trafic entre au moins deux équilibreurs de charge réseau passthrough internes utilisés en tant que prochain saut à l'aide d'ECMP. À la place, Google Cloud ne sélectionne qu'un seul équilibreur de charge réseau passthrough internes utilisé en tant que prochain saut à l'aide d'un algorithme interne déterministe. Pour éviter cette ambiguïté, vous pouvez utiliser des tags réseau uniques pour chaque route.

  

• Plusieurs routes avec les mêmes destinations, priorités et équilibreurs de charge réseau passthrough internes utilisés en tant que prochain saut. Sans tag réseau, Google Cloud ne vous permet pas de créer plusieurs routes statiques ayant la même combinaison de destination, de priorité et d'équilibreur de charge réseau passthrough internes utilisé en tant que prochain saut. Avec les tags réseau, vous pouvez créer plusieurs routes statiques ayant la même combinaison de destination, de priorité et d'équilibreur de charge réseau passthrough internes utilisé en tant que prochain saut.

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 prochain saut. L'envoi de trafic vers un tunnel VPN classique de prochain saut dans une autre région entraîne des coûts de transfert de données sortant et une latence 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 ne sont pas en cours d'exécution : les routes statiques personnalisées dont les prochains sauts sont des tunnels VPN classiques ne sont pas automatiquement supprimées lorsque les tunnels VPN classiques ne sont pas en cours d'exécution. Pour plus de détails sur ce qui se passe lorsque les tunnels ne sont pas en cours d'exécution, consultez la section Cas où les tunnels sont indisponibles dans la documentation sur les VPN classiques.

Étapes suivantes

• Pour créer et gérer des routes, consultez la page Utiliser des routes.
• Pour obtenir une présentation générale des routes Google Cloud, consultez Routes.