Adresses BYOIP

Les adresses BYOIP (Bring your own IP) vous permettent de provisionner et d'utiliser vos propres adresses IPv4 publiques pour les ressources Google Cloud. Une fois les adresses IP importées, Google Cloud les gère de la même manière que les adresses IP fournies par Google, à quelques exceptions près :

  • L'adresse IP n'est disponible que pour le client qui les a fournis.

  • Les adresses IP inactives ou en cours d'utilisation sont gratuites.

La migration à chaud vous permet de contrôler le moment où Google commence à annoncer des routes pour votre préfixe. La migration à chaud n'est pas disponible par défaut. Pour demander l'accès, contactez votre ingénieur client Google Cloud.

Présentation

Pour utiliser votre propre adresse IP avec Google, vous devez créer un préfixe public annoncé (PAP). La validation de la propriété de ce préfixe public annoncé est effectuée à l'aide de la ROA (autorisation d'origine de route) et de la validation DNS inverse. Une fois la validation terminée, nous configurons l'annonce de ce préfixe sur Internet, mais le préfixe n'est pas annoncé tant qu'il n'est pas provisionné. Le provisionnement du préfixe public annoncé peut prendre jusqu'à quatre semaines.

En attendant que le préfixe public annoncé soit provisionné, vous le divisez en préfixes délégués publics (PDP). Vous pouvez ensuite diviser davantage le préfixe délégué public ou l'utiliser pour créer des adresses IP attribuables. Le provisionnement du préfixe public délégué peut prendre jusqu'à quatre semaines.

Une fois le provisionnement du préfixe public délégué terminé, le préfixe public annoncé est annoncé sur Internet. Si vous utilisez la migration à chaud, consultez la page Utiliser la migration à chaud pour connaître les étapes supplémentaires.

Figure 1. Workflow de création de préfixes publics annoncés et de préfixes publics délégués.

Préfixes annoncés publics

Un préfixe annoncé public (PAP) est une ressource dans Compute Engine qui représente un préfixe d'adresse IP que vous apportez à Google Cloud. Cela vous permet d'allouer des adresses IP de votre propre préfixe aux ressources Google Cloud. Le préfixe public annoncé est une unité unique d'annonce de routage. Le réseau backbone mondial de Google annonce le préfixe public annoncé depuis tous ses points de présence. Les adresses IP du préfixe public annoncé utilisent toujours le niveau Premium des niveaux de service réseau.

Un préfixe public annoncé peut être utilisé pour créer des préfixes délégués publics globaux ou des préfixes délégués publics régionaux, mais pas les deux.

Si votre préfixe public annoncé a été créé avant le 10 juillet 2023, consultez la section Modifications du comportement pour BYOIP.

Lors de la création d'un nouveau préfixe public annoncé, celui-ci doit avoir une plage d'adresses IPv4 avec une plage CIDR minimale de taille /24. Une plage CIDR plus petite, par exemple /25, ne peut pas être créée en tant que nouveau préfixe public annoncé. Cependant, une fois créé, vous pouvez diviser un préfixe annoncé public, tel qu'un /24 ou un /23, en préfixes plus petits publics délégués.

Préfixes délégués publics

Un préfixe délégué public (PDP) est un bloc d'adresses IP appartenant au préfixe annoncé public qui est configuré dans un champ d'application unique (une région spécifique ou globale). Les blocs d'adresses IP doivent être délégués et affectés à un champ d'application avant de pouvoir allouer des adresses IP à votre projet ou à votre organisation.

La création de préfixes publics délégués globaux est limitée. Pour en savoir plus, consultez la page Préfixes délégués publics globaux.

Vous pouvez diviser un préfixe délégué public unique en plusieurs blocs plus petits, mais ceux-ci doivent avoir le même champ d'application que le bloc parent. Vous pouvez configurer plusieurs préfixes délégués publics non contigus pour un champ d'application donné. Ces petits blocs sont des préfixes délégués publics, mais également appelés sous-préfixes.

Préfixes délégués publics globaux

Pour créer un préfixe délégué public global, vous devez utiliser un préfixe public annoncé qui n'est utilisé que pour créer des préfixes délégués publics globaux. Vous devez créer le préfixe délégué public dans un projet autorisé à créer des préfixes globaux.

Pour demander l'accès, envoyez une demande d'assistance pour que votre projet soit ajouté à la liste d'autorisation pour la création du préfixe délégué public global.

Adresses IP

Lorsque vous créez des adresses IP à partir d'un préfixe ou d'un sous-préfixe public délégué, les adresses ne peuvent être utilisées que dans le projet et le champ d'application auxquels elles sont allouées. Toutes les adresses IP du préfixe ou du sous-préfixe public délégué sont rendues disponibles. Il n'y a pas d'adresse réseau réservée ni d'adresse de diffusion. Par exemple, si vous utilisez un préfixe ou un sous-préfixe public délégué /28 pour créer des adresses IP, 16 ressources d'adresse IP sont créées.

Toute personne disposant des autorisations IAM appropriées dans le projet peut utiliser les adresses IP :

  • compute.addresses.* pour les adresses IP régionales

  • compute.globalAddresses.* pour les adresses IP globales

Changements de comportement pour BYOIP

Les changements de comportement suivants prendront effet le 10 juillet 2023 :

  • Un préfixe public annoncé peut être utilisé pour créer des préfixes publics délégués globaux ou des préfixes délégués publics régionaux, mais pas les deux.
  • Les préfixes publics annoncés qui ont été créés avant le 10 juillet 2023 ne peuvent être utilisés que pour créer des préfixes délégués publics régionaux.
  • Pour créer des préfixes délégués publics globaux, vous devez demander un accès.

Les configurations de préfixes délégués publics globaux existants ne sont pas affectées.

Ports ouverts sur des adresses BYOIP

L'exécution d'une analyse de port sur une adresse BYOIP peut renvoyer des résultats inattendus. Les adresses BYOIP globales sont implémentées par un service d'infrastructure appelé Google Front End (GFE). Même si elle n'est pas utilisée, une adresse BYOIP peut sembler avoir des ports ouverts, car ces ports sont utilisés par d'autres services Google qui partagent également le GFE. Le trafic vers ces ports est interrompu et n'est pas consigné.

Seuls les équilibreurs de charge compatibles peuvent utiliser des adresses IP globales. Pour en savoir plus sur les ports ouverts sur les équilibreurs de charge, consultez les sections suivantes :

Rôle d'administrateur des adresses IP publiques

Vous pouvez désigner un administrateur pour vos préfixes et adresses BYOIP en leur affectant le rôle d'administrateur des adresses IP publiques Compute (roles/compute.publicIpAdmin). Ce rôle leur permet de gérer les adresses IP routables publiquement dans votre organisation.

L'administrateur d'adresses IP publiques peut effectuer les tâches suivantes :

  • Configurer les préfixes annoncés publics dans un projet dont il est le propriétaire.
  • Configurer les préfixes annoncés publics en préfixes délégués publics dans un projet dont ils sont propriétaires.
  • Déléguer les sous-préfixes des préfixes délégués publics à des projets spécifiques de l'organisation.
  • Révoquer les sous-préfixes qui étaient précédemment délégués du préfixe public délégué d'un projet spécifique de l'organisation.
  • Supprimez les préfixes publics délégués.

Planification de votre déploiement

Il est important de planifier votre déploiement, car les processus de provisionnement et de suppression nécessitent plusieurs semaines. Pour en savoir plus sur la chronologie du provisionnement et les tailles de préfixe autorisées, consultez la section Limites.

Voici quelques décisions à prendre en compte lorsque vous planifiez votre déploiement :

  • Qui est responsable de l'administration des adresses BYOIP ? Il s'agit généralement d'un administrateur ou d'un groupe, mais il ne s'agit généralement pas des mêmes utilisateurs qui gèrent des projets individuels. Utilisez les rôles et les autorisations IAM pour identifier qui dispose de droits sur les préfixes publics annoncés et les préfixes délégués publics que vous souhaitez provisionner.

  • Comment les préfixes sont-ils gérés ? Vous souhaitez probablement utiliser vos adresses BYOIP dans différents projets. Vous pouvez gérer les préfixes de manière centralisée dans un projet distinct des destinations ultimes des adresses IP. Nous vous recommandons d'isoler l'administration du préfixe dans un projet, y compris ses propres utilisateurs et groupes disposant d'autorisations d'administrateur d'adresses IP publiques. Cette isolation permet d'éviter toute confusion concernant l'administration des préfixes, ainsi que l'utilisation involontaire ou non autorisée des préfixes. Pour en savoir plus, consultez la section Architecture du projet.

  • Comment les préfixes sont-ils nommés ? Chaque ressource BYOIP (préfixe public annoncé, préfixe délégué public, sous-préfixe) nécessite un nom et le nom permet de gérer chaque ressource. Vous attribuez ce nom lors de la création de la ressource, et vous ne pouvez pas le modifier sans supprimer et recréer la ressource. C'est la raison pour laquelle nous vous recommandons de créer des noms faciles à gérer. Par exemple, pap-203-0-113-0-24, pdp-203-0-113-0-25, sub-203-0-113-0-28, où les lettres indiquent le type de ressource, et les chiffres indiquent les valeurs spécifiques de préfixe et de longueur du préfixe.

  • Où les adresses IP sont-elles provisionnées ? Il est utile de considérer le processus de provisionnement comme un processus de "stockage" des adresses IP en régions (ou du champ d'application global). Le processus de provisionnement pour le stockage des adresses IP prend plusieurs semaines. Il est donc utile de planifier et de déployer les préfixes délégués publics bien avant qu'ils ne soient nécessaires.

    Vous n'avez pas besoin d'utiliser immédiatement toutes les adresses IP d'un préfixe délégué public. Si vous ne savez pas où vous en avez besoin, provisionnez uniquement les préfixes délégués publics que vous êtes certain d'utiliser. Pour déplacer un préfixe délégué public, vous devez d'abord le supprimer, puis le recréer, ce qui peut prendre jusqu'à huit semaines.

    Une fois le provisionnement de préfixe délégué public terminé, vous pouvez déléguer les sous-préfixes aux projets et créer des adresses à utiliser avec les ressources. Si vous pensez avoir besoin d'adresses BYOIP dans une région, effectuez le processus provisionnement de préfixe délégué public à l'avance afin de pouvoir répondre ultérieurement aux besoins à la demande.

    Par exemple, si vous avez besoin d'adresses IP dans us-central1 et d'adresses IP pour les équilibreurs de charge globaux, et que vous souhaitez réserver des adresses IP pour l'avenir, vous devez créer le plan suivant.

    Type de préfixe Préfixe Champ d'application
    Préfixe public annoncé 203.0.113.0/24
    Préfixe public annoncé pour les équilibreurs de charge globaux 192.0.2.0/24
    Préfixe délégué public 203.0.113.0/28 us-central1
    Préfixe délégué public 203.0.113.16/28 us-east-4
    Préfixe délégué public 192.0.2.0/28 Mondial

    Les adresses IP restantes sont réservées pour une utilisation future.

Migration à chaud

La migration à chaud est une fonctionnalité puissante qui nécessite une planification et une exécution minutieuses.

La migration à chaud permet d'importer un préfixe BYOIP lorsqu'une partie du préfixe est déjà annoncée publiquement. L'importation d'un préfixe annoncé sans migration à chaud peut entraîner une perte de paquets et un routage inattendu.

La migration à chaud a une disponibilité limitée. Contactez votre ingénieur client Google Cloud pour obtenir l'accès avant de créer un préfixe délégué public avec la migration à chaud activée.

Vous activez la migration à chaud lorsque vous créez un préfixe délégué public. Pour empêcher Google d'annoncer le préfixe public annoncé aux pairs, vous devez vous assurer que :

  • Tous les préfixes délégués publics au sein du préfixe annoncé public sont configurés avec un champ d'application régional, et non un champ d'application global. Pour en savoir plus, consultez la section Recommandations de migration à chaud.

  • Aucune adresse IP comprise dans la plage du préfixe public annoncé n'est attribuée aux ressources.

La figure 2 affiche le même projet avec des configurations différentes, l'une empêche l'annonce du préfixe et l'autre déclenchant l'annonce du préfixe public.

Figure 2. Annonce de préfixe public annoncé lors d'une migration à chaud (cliquez pour agrandir).

La figure 2 illustre les scénarios suivants :

  • Dans le premier exemple de projet, tous les préfixes publics délégués du préfixe public annoncé sont configurés avec la migration à chaud activée. Aucune VM n'est configurée avec les adresses IP de ce préfixe.

    Résultat : le préfixe public annoncé n'est pas annoncé.

  • Dans le deuxième exemple de projet, tous les préfixes publics délégués du préfixe public annoncé sont configurés avec la migration à chaud activée. Une VM est configurée avec une adresse IP de ce préfixe.

    Résultat : le préfixe public annoncé est annoncé.

  • Dans le troisième exemple de projet, un préfixe public délégué du préfixe public annoncé n'est pas configuré avec la migration à chaud activée. Aucune VM n'est configurée avec les adresses IP de ce préfixe.

    Résultat : le préfixe public annoncé est annoncé.

Vous contrôlez le moment où l'annonce commence en attribuant des adresses IP de votre préfixe délégué public aux ressources Google Cloud. Pour en savoir plus, consultez la section Utiliser la migration à chaud.

Une fois la migration à chaud terminée, contactez votre ingénieur client Google Cloud pour qu'il puisse désactiver la migration à chaud pour votre préfixe. Par défaut, la migration à chaud est désactivée 30 jours après le lancement de l'annonce du préfixe public annoncé. Si vous avez besoin de l'option de migration à chaud pendant plus de 30 jours, contactez votre ingénieur client.

Limites de la migration à chaud

Lors de la planification d'une migration à chaud, il est important de connaître les exigences et limitations suivantes :

  • La création d'un préfixe délégué public avec la migration à chaud activée n'est pas disponible si le champ d'application est défini sur "global". Consultez la section Recommandations de migration à chaud pour en savoir plus sur la gestion de la migration à chaud des ressources globales.

  • Le préfixe le plus long pouvant être migré est /24, car /24 est la longueur maximale de préfixe pouvant être routée sur Internet.

  • Ne partez pas du principe que tous les pairs de Google respectent le préfixe le plus long entre deux sites. Il est possible que certains pairs ne disposent pas de tables de routage complètes. Par conséquent, un préfixe plus court annoncé par Google à ces pairs est le seul préfixe (et donc le plus long) visible par le pair. Par conséquent, l'existence de tout préfixe de Google est prioritaire, même si vous annoncez d'une route plus spécifique depuis votre emplacement sur site.

    Exemple :

    Un client dispose d'un /23 qui est acheminé activement à partir de son emplacement sur site. Le client prévoit de dissocier /23 en deux préfixes /24 et annonce les routes plus spécifiques à partir de son emplacement sur site. À la suite de la désagrégation, ils prévoient de configurer un préfixe public annoncé /23 pour la BYOIP. Ils partent du principe que les routes plus spécifiques de leur emplacement sur site sont prioritaires sur le préfixe BYOIP le plus court et que le trafic continue à acheminer vers les préfixes sur site plus spécifiques.

    Malheureusement, ce cas de figure ne fonctionne que partiellement :

    • Les pairs Google disposant de tables de routage complètes préfèrent les préfixes /24 sur site plus spécifiques.

    • Les pairs Google qui ne possèdent pas de table de routage complet préfèrent le préfixe public annoncé par Google, car leurs tables de routage n'incluent pas les préfixes plus spécifiques.

  • Votre trafic n'est pas distribué si Google reçoit du trafic pour un préfixe public annoncé pour lequel vous n'avez pas provisionné de services, même s'il existe une annonce sur site active pour ce préfixe.

    Exemple :

    Un client dispose d'un réseau sur site composé de deux préfixes /24. Le préfixe annoncé public qui lui est associé est l'agrégation /23.

    Le client migre un seul /24 vers Google et supprime le préfixe sur site, mais conserve l'autre /24 actif dans l'emplacement sur site.

    Cette configuration entraîne une partie du routage du trafic vers Google pour l'intégralité du préfixe /23, même s'il existe toujours un préfixe /24 plus spécifique annoncé depuis l'emplacement sur site. Ce scénario est difficile à analyser, car différents systèmes autonomes acheminent du trafic vers votre emplacement sur site, tandis que d'autres le transmettent à Google, auquel cas le trafic est interrompu.

Recommandations pour la migration à chaud

Nous vous recommandons de suivre ces recommandations lorsque vous utilisez la migration à chaud.

  • Dissociez tous les préfixes de migration à chaud par les préfixes les plus longs correspondant à la manière dont vous souhaitez annoncer ces préfixes lors de la migration. Dans les exemples précédents, /23 doit être dissocié en deux préfixes /24 et annoncés comme tel à partir de leur emplacement sur site avant de créer le préfixe annoncé public.

  • Créez des requêtes ROA exactes de longueur de préfixe et ne comptez pas sur le paramètre de longueur maximale à respecter.

  • Assurez-vous que les requêtes RPKI ROA existent pour le numéro ASN d'origine sur site et pour le numéro ASN d'origine de Google. En l'absence de ROA pour le préfixe sur site, la création d'une ROA d'origine Google peut entraîner l'exclusion par des FAI tiers ces préfixes sur site s'ils utilisent le filtre automatique RPKI.

  • Créez des préfixes annoncés publics séparés pour les ressources globales et les ressources régionales si vous devez utiliser la migration à chaud. Lorsque vous activez la migration à chaud sur un préfixe délégué public, vous devez spécifier une région pour le champ d'application. La spécification du champ d'application global d'un préfixe délégué public pour lequel la migration à chaud est activée n'est pas disponible. Si vous créez un préfixe délégué public avec le champ d'application global et la migration à chaud activées, le préfixe est immédiatement annoncé.

    Le fait d'avoir des préfixes régionaux dans un préfixe public annoncé et des préfixes globaux dans un autre préfixe annoncé public vous permet de les gérer séparément. Vous pouvez gérer la migration à chaud des ressources régionales et contacter votre ingénieur client Google Cloud pour gérer la migration à chaud des ressources globales.

Architecture du projet

Nous vous recommandons d'utiliser des organisations pour bénéficier de fonctionnalités telles que les autorisations IAM au niveau de l'organisation et le VPC partagé. Pour en savoir plus sur l'utilisation d'une organisation, consultez la page Créer et gérer des organisations.

Administration des adresses BYO au sein d'une organisation

Dans cet exemple de projet appartenant à une organisation, il existe un projet dédié, Public IP project, utilisé pour gérer les adresses BYOIP. L'administrateur d'adresses IP publiques de l'organisation a créé le préfixe public annoncé et les préfixes délégués publics dans Public IP project.

Lorsque VPC project nécessite des adresses IP publiques, l'administrateur d'IP publiques de l'organisation crée les adresses IP dans VPC project.

L'organisation peut contenir plusieurs projets, et l'administrateur d'adresses IP publiques peut leur déléguer des adresses IP à partir du Public IP project.

Figure 3. Vous pouvez gérer les adresses BYOIP à l'aide d'organisations et de projets.

Administration des adresses BYOIP avec un VPC partagé

Dans cet exemple d'organisation contenant un VPC partagé, il existe un projet dédié, Public IP project, utilisé pour gérer les adresses BYOIP. L'administrateur d'adresses IP publiques de l'organisation a créé le préfixe public annoncé et les préfixes publics délégués dans Public IP project.

Lorsque Shared VPC host project ou les projets de service associés ont besoin d'adresses IP publiques, l'administrateur d'adresses IP publiques de l'organisation crée les adresses IP dans Shared VPC host project. Le projet hôte et les projets de service peuvent accéder aux adresses BYOIP du projet hôte.

Il n'est pas possible de créer des adresses IP dans un projet de service VPC partagé.

Figure 4. Vous pouvez déléguer des adresses BYOIP à un projet hôte de VPC partagé, mais pas à un projet de service de VPC partagé. Toutefois, un projet de service peut utiliser des adresses BYOIP déléguées au projet hôte.

Administration des adresses BYOIP sans organisation

Si vous utilisez un projet n'appartenant pas à une organisation, vous ne pouvez pas créer de projet distinct pour l'administration des adresses BYOIP. Créez le préfixe public annoncé et les préfixes délégués publics dans le même projet qui a besoin des adresses BYOIP.

Quotas et limites

Il existe des quotas et des limites pour les préfixes délégués publics (PDP) et les préfixes annoncés publics (PAP). Pour en savoir plus, consultez la section Quotas et limites des VPC.

Étapes suivantes