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) 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'une destination (CIDR) unique 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. Même si certaines routes peuvent être définies de manière sélective, 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 sortant d'une VM est acheminé vers le saut suivant approprié d'une route applicable, en fonction d'un ordre de priorités 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 réseaux VPC peuvent inclure des routes générées par le système ou des routes personnalisées.

Le tableau suivant récapitule les routes générées par le système, qui sont ajoutées ou mises à jour automatiquement lorsque vous créez un réseau VPC, que vous ajoutez un sous-réseau, que vous étendez la plage d'adresses IP principale d'un sous-réseau ou que vous modifiez la plage d'adresses IP secondaire d'un sous-réseau. Elles s'appliquent à toutes les instances du réseau VPC.

Routes générées par le système
Type Destination Saut suivant Amovible
Route par défaut 0.0.0.0/0 default-internet-gateway Oui
Route de sous-réseau Plages d'adresses IP de sous-réseau principales et secondaires
Réseau VPC, qui transmet les paquets aux VM dans ses sous-réseaux Seulement lorsque le sous-réseau est supprimé ou lorsque vous modifiez les plages d'adresses IP secondaires du sous-réseau

Le tableau suivant récapitule les routes personnalisées que vous créez et gérez directement ou à l'aide de Cloud Router.

Routes personnalisées
Type Destination Saut suivant Amovible Applicable à
Route statique • Plage d'adresses IP qui ne chevauche pas partiellement ou exactement une plage d'adresses IP de sous-réseau
• Plage d'adresses IP plus large qu'une plage d'adresses IP de sous-réseau
L'un des éléments suivants :
• Instance par nom
• Instance par adresse IP
• Tunnel Cloud VPN
Oui Soit :
• Toutes les instances du réseau
• Instances spécifiques du réseau, identifiées par un tag réseau, si la route peut être limitée par un tag réseau
Route dynamique • Plage d'adresses IP qui ne chevauche pas partiellement ou exactement une plage d'adresses IP de sous-réseau
• Plage d'adresses IP plus large qu'une plage d'adresses IP de sous-réseau
Adresse IP du pair BGP du routeur cloud Uniquement par un routeur Cloud Router s'il ne reçoit plus la route de son pair BGP • Instances dans la même région que le routeur cloud si le réseau VPC est en mode de routage dynamique régional
• Toutes les instances si le réseau VPC est en mode de routage dynamique global

Route par défaut

Lorsque vous créez un réseau VPC, Google Cloud crée une route par défaut générée par le système. Cette route 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 d'accès 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. Consultez la section Ordre de priorités de routage pour savoir comment la spécificité de destination et la priorité de routage sont utilisées pour sélectionner une route.

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 router le "trafic Internet" vers un saut suivant différent. Vous pouvez par exemple la remplacer par une route statique personnalisée dont le saut suivant est un tunnel Cloud VPN ou une autre instance, telle qu'un serveur 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 sont des routes générées par le système qui définissent les chemins d'accès à chaque sous-réseau du 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, Google Cloud crée une route de sous-réseau avec une destination correspondante pour chaque plage secondaire. 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. Vous pouvez créer une route personnalisée comportant une plage de destination plus large qui contient la plage de destination de la route du sous-réseau.

En cas de chevauchement de plage d'adresses IP : étant donné que Google Cloud utilise la spécificité de destination comme premier critère pour définir l'ordre de priorités de routage, la route de sous-réseau sera toujours considérée comme saut suivant prioritaire pour les paquets dont les destinations correspondent à sa plage de destination. Ceci est également le cas même si une autre route, dont la destination contient la destination de la route de sous-réseau, a une priorité plus élevée.

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

  • Lorsqu'un sous-réseau est créé, une route de sous-réseau correspondant à la plage d'adresses IP principale du sous-réseau est également créée.

    • Si vous ajoutez une plage d'adresses IP secondaire à un sous-réseau, une route de sous-réseau correspondante est créée pour cette plage secondaire.
  • 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.

  • Lorsque des réseaux sont connectés via l'appairage de réseaux VPC, les routes de sous-réseau d'un réseau sont importées dans l'autre réseau, et inversement. C'est pourquoi toutes les plages d'adresses IP de sous-réseau principales et secondaires doivent être uniques.

    • Les routes de sous-réseau pour les sous-réseaux dans les réseaux appairés ne peuvent être supprimées que si vous interrompez la relation d'appairage. Lorsque vous interrompez cette relation, toutes les routes de sous-réseau importées depuis l'autre réseau sont automatiquement supprimées.

Les règles de pare-feu peuvent bloquer la communication entre les instances. Pour plus d'informations sur la communication entre instances, reportez-vous à la section Communication au sein du réseau.

Routes personnalisées

Les routes personnalisées sont soit des routes statiques que vous créez manuellement, soit des routes dynamiques gérées automatiquement par un ou plusieurs routeurs Cloud Router.

Les destinations des routes personnalisées ne peuvent pas être identiques ou avoir une spécificité supérieure aux autres routes de sous-réseau au sein du réseau.

Si votre réseau VPC est en mode automatique, n'utilisez pas les destinations 10.128.0.0/9 du bloc CIDR, car celui-ci définit l'espace d'adressage actuel et futur des routes de sous-réseau. Pour plus d'informations, consultez la section Plages d'adresses IP du mode automatique.

Dans un réseau VPC en mode automatique, les routes statiques avec des destinations comprises dans la plage 10.128.0.0/9 peuvent être désactivées à tout moment. Cela peut se produire si une nouvelle région Google Cloud devient disponible et qu'un nouveau sous-réseau est créé automatiquement (avec sa route de sous-réseau). Pour plus d'informations, consultez la section Remarques sur les réseaux VPC en mode automatique.

Routes statiques

Les routes statiques peuvent utiliser n'importe quel saut suivant de route statique. Vous pouvez créer des routes statiques de deux manières :

  • Vous pouvez les créer manuellement.

  • Si vous utilisez Google Cloud Console pour créer un tunnel Cloud VPN utilisant un routage basé sur des règles ou un VPN basé sur le routage, des routes statiques pour les sélecteurs de trafic distants sont créées pour vous. Pour plus d'informations, consultez la page Réseaux et options de routage pour les tunnels.

Consultez la section Paramètres des routes statiques pour plus d'informations.

Routes dynamiques

Les routes dynamiques sont gérées par un ou plusieurs routeurs Cloud Router. Leurs destinations représentent toujours des plages d'adresse IP en dehors de votre réseau VPC, et leurs sauts suivants sont toujours des adresses de pairs BGP. Un routeur Cloud Router peut gérer des routes dynamiques pour :

Applicabilité et ordre

Routes applicables

Chaque instance possède un ensemble de routes applicables, qui constituent un sous-ensemble parmi 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 générées par le système s'appliquent à toutes les instances d'un réseau VPC. Le champ d'application des instances auxquelles s'appliquent les routes de sous-réseau ne peut pas être modifié. Cependant, vous pouvez remplacer la route par défaut.

  • 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 un tag réseau correspondant. 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. Reportez-vous à la section Instances utilisées comme sauts suivants pour plus d'informations.

    • 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 tunnels indisponibles, reportez-vous à 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 le réseau VPC est en mode de routage dynamique régional, tous les routeurs Cloud Router appliquent les routes récupérées dans leurs régions respectives. Si le réseau est en mode de routage dynamique global, tous les routeurs Cloud Router appliquent les routes récupérées sur l'intégralité du réseau.

    • Cloud Router supprime automatiquement les routes dynamiques personnalisées apprises qui correspondent à des sauts suivants inaccessibles (tunnels Cloud VPN utilisant un routage dynamique ou Cloud Interconnect). En fonction de votre réseau, Cloud Router peut 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 des é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 sont prioritaires, car Google Cloud exige que les destinations les plus spécifiques des routes de sous-réseau correspondent aux plages d'adresses IP de leurs sous-réseaux respectifs. Les routes de sous-réseau sont des routes pour les plages d'adresses IP de sous-réseau principale et secondaire(s) de chaque sous-réseau de votre réseau VPC et les plages d'adresses IP de sous-réseau principales et secondaires des sous-réseaux dans les réseaux appairés. Si la destination d'un paquet correspond à la destination d'une route de sous-réseau, celui-ci est distribué à ce sous-réseau Google Cloud. Vous ne pouvez pas remplacer une route de sous-réseau par un autre type de route.

    • Google Cloud ne vous permet pas de créer une route statique personnalisée ayant une destination équivalente à une route de sous-réseau ou plus spécifique.

    • Lorsqu'une route statique possède un préfixe de la même longueur qu'une route dynamique, la route statique est prioritaire par rapport à la route dynamique Cloud Router. Une route statique avec le même préfixe et la même métrique de routage qu'une route dynamique est toujours prioritaire. Par conséquent, les routes dynamiques en conflit sont ignorées.

    • Pour les routes dynamiques personnalisées, Cloud Router ignore une route vers d'autres réseaux reçue par un routeur Cloud Router si sa destination est équivalente à une route de sous-réseau ou plus spécifique.

    • Lorsque vous connectez des réseaux VPC à l'aide de l'appairage de réseaux VPC, ces réseaux partagent toutes les routes de sous-réseau. Dans les réseaux appairés, Google Cloud donne la priorité aux routes de sous-réseau semblables à celles du réseau local : les routes de sous-réseau dans les réseaux appairés doivent utiliser les destinations les plus spécifiques possibles.

  2. Si le paquet ne correspond pas à la destination d'une route de sous-réseau, Google Cloud cherche une route personnalisée avec la destination la plus spécifique.

    • Supposons que la destination d'un paquet quittant une VM est 10.240.1.4, et qu'il existe deux routes avec des destinations différentes : 10.240.1.0/24 et 10.240.0.0/16. Étant donné que la destination la plus spécifique pour 10.240.1.4 est 10.240.1.0/24, la route dont la destination est 10.240.1.0/24 va définir le saut suivant pour le paquet.
  3. Si plusieurs routes personnalisées possèdent la même destination plus spécifique, Google Cloud utilise le processus suivant pour en sélectionner une parmi les routes candidates. Les routes candidates sont des routes personnalisées (statiques ou dynamiques) ayant la même destination la plus spécifique.

    1. Si votre réseau VPC est connecté à d'autres réseaux via l'appairage de réseaux VPC, Google Cloud commence par limiter les routes candidates qui proviennent toutes d'un seul réseau VPC :

      • Si au moins une route candidate est définie dans votre réseau VPC local, Google Cloud utilise la route locale candidate et ignore toutes les candidates des réseaux appairés.

      • Si les routes candidates sont issues de plusieurs réseaux appairés, Google Cloud sélectionne l'un des réseaux appairés dans lesquels au moins une route candidate est définie et ignore les routes candidates des autres réseaux appairés. À l'aide d'une méthode non déterministe, Google Cloud sélectionne le réseau appairé unique, indépendamment de la priorité associée à chaque route. Si vous ajoutez ou supprimez des réseaux du groupe d'appairage, Google Cloud peut choisir des routes candidates d'un autre réseau appairé.

      Google Cloud passe ensuite à la sélection d'une route parmi les routes candidates d'un réseau unique.

    2. Si une route ayant la priorité la plus élevée est disponible, Google Cloud envoie le paquet à son saut suivant.

    3. Si plusieurs routes possèdent la priorité la plus élevée, Google Cloud sélectionne une route en fonction de son caractère statique ou dynamique et de la valeur de son saut suivant. Google Cloud utilise l'ordre de préférence suivant :

      1. Google Cloud sélectionne une route statique personnalisée dont le saut suivant est "Instance de saut suivant", "Adresse IP de saut suivant" ou "Tunnel VPN de saut suivant".

      2. Google Cloud sélectionne une route dynamique personnalisée annoncée par un routeur cloud.

      3. Google Cloud sélectionne une route statique personnalisée avec "Équilibreur de charge TCP/UDP interne comme saut suivant".

      4. Google Cloud sélectionne une route statique personnalisée en utilisant la passerelle Internet par défaut comme saut suivant.

    4. Si aucune route unique ne peut être sélectionnée, Google Cloud répartit le trafic entre les sauts suivants des routes candidates en utilisant un hachage quintuple pour l'affinité, en mettant en œuvre une conception de routage ECMP. Le hachage est calculé à partir du protocole, des adresses IP source et de destination, ainsi que des ports source et de destination du paquet envoyé. Ce calcul est effectué pour chaque paquet envoyé en fonction du nombre de routes candidates disponibles. Si le nombre de routes candidates disponibles change, le hachage peut diriger le paquet vers un autre saut suivant.

  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 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 d'état. Ces routes sont décrites plus en détail dans les sections suivantes. 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.

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

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 avoir un nom unique.

  • 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. Google Cloud n'est pas compatible avec les plages de destination IPv6. Les destinations doivent être exprimées à l'aide de la notation CIDR, et 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 positif le plus petit possible. Comme zéro est le nombre entier positif 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.

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

  • 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 dans lequel 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 ne valide que l'existence d'une VM de saut suivant 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. Reportez-vous à la section Instances utilisées comme sauts suivants pour plus d'informations.

  • Équilibreur de charge TCP/UDP interne comme saut suivant (next-hop-ilb) : pour l'équilibrage de charge TCP/UDP interne, vous pouvez répartir le trafic entre les instances de 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 comme saut suivant si cette adresse correspond à la plage d'adresses IP principale ou secondaire d'un sous-réseau existant de votre réseau VPC. Vous ne pouvez pas utiliser une adresse IP publique ou une adresse IP interne dans un réseau sur site.

    • Lorsque vous utilisez next-hop-address, Google Cloud transmet le trafic à toute instance de VM affecté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 du saut suivant. Si l'adresse IP du 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.

  • 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 des routes, vous pouvez diriger le trafic vers le tunnel VPN en créant des routes dont les sauts suivants se réfèrent 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, reportez-vous à la section Exemples de routage Cloud VPN.

Considérations liées à l'instance et aux sauts suivants de l'é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 d'acheminement doivent inclure les adresses IP des sources des paquets acheminé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 d'acheminement doivent inclure les adresses IP des destinations des paquets acheminé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'adresses 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, il est donc possible de créer une route qui envoie du trafic vers une instance de 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 considère toujours une route qui utilise cette instance comme un 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 un processus d'acheminement 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 d'état configurée, qui détermine le mode d'acheminement 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.

Étapes suivantes