Traga seus próprios endereços IP

Trazer seus próprios endereços IP (BYOIP) permite que você provisione e use seus próprios endereços IPv4 públicos para os recursos do Google Cloud. Depois que os endereços IP forem importados, o Google Cloud os gerenciará da mesma maneira que os endereços IP fornecidos pelo Google, com estas exceções:

  • Os endereços IP estão disponíveis apenas para o cliente que os trouxe.

  • Não há cobranças para endereços IP inativos ou em uso.

A migração em tempo real permite que você controle quando o Google inicia as rotas de publicidade para seu prefixo. A migração em tempo real não está disponível por padrão. Para solicitar acesso, entre em contato com seu engenheiro de clientes do Google Cloud.

Informações gerais

Para trazer seu próprio IP para o Google, crie um prefixo público divulgado (PAP, na sigla em inglês). A verificação de propriedade é feita para esse prefixo público divulgado usando a ROA e a validação do DNS reversa. Após a conclusão da verificação, configuramos o anúncio desse prefixo para a Internet, mas o prefixo não é anunciado até que seja provisionado. O provisionamento do prefixo público divulgado pode levar até quatro semanas.

Enquanto aguarda o provisionamento do prefixo público anunciado, divida o prefixo em prefixos públicos delegados (PDP). É possível dividir ainda mais o prefixo público delegado ou usá-lo para criar endereços IP atribuíveis. O provisionamento do prefixo público delegado pode demorar até quatro semanas.

Depois que o provisionamento do prefixo público delegado for concluído, o prefixo público anunciado será anunciado para a Internet. Se você estiver usando a migração em tempo real, consulte Usar a migração em tempo real para mais etapas.

Figura 1. Fluxo de trabalho para criar prefixos públicos divulgado e prefixos delegados públicos.

Prefixo anunciado público

Um prefixo anunciado público (PAP, na sigla em inglês) é um recurso do Compute Engine que representa um prefixo de IP fornecido ao Google Cloud. Isso permite alocar endereços IP do seu próprio prefixo para os recursos do Google Cloud. O prefixo público anunciado é uma unidade única de divulgação de rota. O backbone global do Google anuncia o prefixo público anunciado de todos os pontos de presença. Os endereços IP no prefixo público anunciado sempre usam o nível Premium dos Níveis de serviço de rede.

Um prefixo público anunciado pode ser usado para criar prefixos delegados públicos globais ou prefixos delegados públicos regionais, mas não ambos.

Se o prefixo público anunciado foi criado antes de 10 de julho de 2023, consulte Mudanças de comportamento para BYOIP.

Ao criar um novo prefixo anunciado público, ele precisa ter um intervalo de IP IPv4 com um intervalo mínimo de CIDR de tamanho /24. Um intervalo CIDR menor, por exemplo /25, não pode ser criado como um novo prefixo público anunciado. No entanto, uma vez criado, é possível dividir um prefixo anunciado público, como /24 ou /23, em prefixos de delegação pública menor.

Prefixo delegado público

Um prefixo público delegado (PDP) é um bloco de endereço IP dentro do prefixo público anunciado configurado em um único escopo (uma região específica ou global). Os blocos de IP precisam ser delegados e atribuídos a um escopo antes da alocação de endereços IP para o projeto ou a organização.

A criação de prefixos delegados públicos globais é restrita. Para mais informações, consulte Prefixos delegados públicos globais.

É possível dividir um único prefixo delegado público em vários blocos menores, mas esses blocos precisam ter o mesmo escopo do bloco pai. É possível configurar vários prefixos delegados públicos não contíguos em um determinado escopo. Esses blocos menores são prefixos delegados públicos, mas também são chamados de sub-prefixos.

Prefixos delegados públicos globais

Para criar um prefixo delegado público global, use um prefixo público anunciado usado para criar apenas prefixos delegados públicos globais. Crie o prefixo delegado público em um projeto que recebeu acesso para criar prefixos globais.

Para solicitar acesso, abra um caso de suporte e solicite que seu projeto seja incluído na lista de permissões para a criação de prefixos delegados públicos globais.

Endereços IP

Ao criar endereços IP a partir de um prefixo ou subprefixo público delegado, os endereços IP só podem ser usados no projeto e no escopo em que foram alocados. Todos os endereços IP no prefixo ou subprefixo público delegado são disponibilizados. Não há endereço de rede ou de transmissão reservado. Por exemplo, se você usar um prefixo ou subprefixo público delegado /28 para criar endereços IP, 16 recursos de endereço IP serão criados.

Qualquer pessoa com as permissões do IAM apropriadas no projeto pode usar os endereços IP:

  • compute.addresses.* para endereços IP regionais

  • compute.globalAddresses.* para endereços IP globais

Mudanças de comportamento para BYOIP

As seguintes mudanças de comportamento entraram em vigor em 10 de julho de 2023:

  • Um prefixo público anunciado pode ser usado para criar prefixos delegados públicos globais ou prefixos delegados públicos regionais, mas não ambos.
  • Os prefixos públicos anunciados que foram criados antes de 10 de julho de 2023 só podem ser usados para criar prefixos delegados públicos regionais.
  • Para criar prefixos delegados públicos globais, você precisa solicitar acesso.

As configurações de prefixo delegado público global não são afetadas.

Portas abertas em endereços BYOIP

A execução de uma verificação de portas em um endereço BYOIP pode retornar resultados inesperados. Os endereços BYOIP globais são implementados por um serviço de infraestrutura chamado Google Front End (GFE). Um endereço BYOIP, mesmo que não usado, pode parecer que tem portas abertas, já que são usadas por outros serviços do Google que também compartilham o GFE. O tráfego para essas portas é descartado e não é registrado.

Somente balanceadores de carga compatíveis podem usar endereços IP globais. Para mais informações sobre portas abertas em balanceadores de carga, consulte:

Papel Administrador de IP público

É possível designar um administrador para os prefixos e endereços de BYOIP atribuindo a eles o papel "Administrador de IP público do Compute" (roles/compute.publicIpAdmin). Esse papel permite que eles gerenciem IPs roteáveis publicamente na organização.

O administrador de IP público pode fazer as seguintes tarefas:

  • Configurar prefixos anunciados públicos em um projeto próprio.
  • Configure os prefixos anunciados públicos em prefixos delegados públicos em um projeto próprio.
  • Delegar prefixos dos prefixos delegados públicos para projetos específicos na organização.
  • Revogue os subatributos que foram delegados anteriormente dos prefixos públicos delegados para um projeto específico na organização.
  • Excluir prefixos delegados públicos.

Como planejar sua implantação

É importante planejar a implantação porque os processos de provisionamento e exclusão levam várias semanas para serem concluídos. Para saber mais sobre o cronograma de provisionamento e os tamanhos de prefixo permitidos, consulte Limitações.

Veja algumas decisões que precisam ser consideradas ao planejar sua implantação:

  • Quem é responsável por administrar endereços IP BYO? Normalmente, é um administrador ou grupo, mas não costuma ser o mesmo usuário que gerencia projetos individuais. Use papéis e permissões do IAM para distinguir quem tem privilégios para os prefixos anunciados públicos e os prefixos delegados públicos que você planeja provisionar.

  • Como os prefixos são gerenciados? É provável que você queira usar os endereços de BYOIP em projetos diferentes. É possível gerenciar prefixos de maneira centralizada em um projeto diferente dos destinos finais dos endereços IP. Recomendamos isolar a administração do prefixo em um projeto próprio, incluindo os usuários e grupos próprios dele com permissões de administrador de IP público. Isso ajuda a evitar confusões sobre a administração de prefixos e uso não autorizado ou acidental de prefixos. Para ver mais informações, consulte Arquitetura do projeto.

  • Como os prefixos são nomeados? Cada recurso BYOIP (prefixo público anunciado, prefixo público público, sub-prefixo) exige um nome, e o nome é usado para gerenciar cada recurso. Você atribui o nome durante a criação do recurso, e os nomes não podem ser alterados sem excluir e recriar o recurso. Por isso, recomendamos que você crie nomes fáceis de gerenciar. Por exemplo, pap-203-0-113-0-24, pdp-203-0-113-0-25, sub-203-0-113-0-28, em que as letras indicam o tipo de recurso, e os números indicam o prefixo e o comprimento do prefixo específicos.

  • Onde os endereços IP são provisionados? É útil pensar no processo de provisionamento como "estoque" em IPs nas regiões (ou no escopo global). O processo de provisionamento para a concessão de endereços IP leva várias semanas para ser concluído. Por isso, é útil planejar e implantar prefixos delegadas públicos antes de serem necessários.

    Não é necessário usar todos os IPs em um prefixo de delegação público imediatamente. Se você não tiver certeza de onde precisa, provisione apenas os prefixos delegados públicos que você tem certeza de que precisa usar. A transferência de um prefixo de delegação público requer a exclusão completa e a recriação, o que pode levar até oito semanas.

    Após a conclusão do provisionamento de prefixos de delegação públicos, é possível delegar subprefixos para projetos e criar endereços para uso com recursos. Se você antecipar a necessidade de endereços de IPO em uma região, conclua o processo de provisionamento do prefixo delegado público com antecedência para poder atender posteriormente às necessidades de endereçamento sob demanda.

    Por exemplo, se você precisar de alguns endereços IP em us-central1 e de alguns para balanceadores de carga globais e quiser reservar alguns outros para o futuro, crie o plano a seguir.

    Tipo de prefixo Prefixo Escopo
    Prefixo público anunciado 203.0.113.0/24
    Prefixo público anunciado para balanceadores de carga globais 192.0.2.0/24
    Prefixo de delegação público 203.0.113.0/28 us-central1
    Prefixo de delegação público 203.0.113.16/28 us-east-4
    Prefixo de delegação público 192.0.2.0/28 global

    Os endereços IP restantes são reservados para uso futuro.

Migração em tempo real

A migração em tempo real é um recurso eficiente que requer planejamento e execução detalhados.

Use a migração em tempo real para importar um prefixo BYOIP quando qualquer parte do prefixo já for anunciada publicamente. Importar um prefixo anunciado sem usar a migração em tempo real pode causar roteamento inesperado e perda de pacotes.

A migração em tempo real tem disponibilidade limitada. Entre em contato com seu Engenheiro de clientes do Google Cloud para ter acesso antes de criar um prefixo de delegação público com a migração em tempo real ativada.

Você ativa a migração em tempo real ao criar um prefixo delegado público. Para impedir que o Google divulgue o prefixo público anunciado para os pares, você precisa garantir o seguinte:

  • Todos os prefixos delegados públicos no prefixo público público são configurados com escopo regional, não escopo global. Consulte as recomendações de migração em tempo real para mais informações.

  • Nenhum endereço IP no intervalo do prefixo público público é atribuído aos recursos.

A Figura 2 exibe o mesmo projeto com configurações diferentes. Uma delas impede que o prefixo seja divulgado e duas que fazem com que o prefixo público divulgado seja anunciado.

Figura 2. Divulgação de prefixo público durante a migração em tempo real (clique para ampliar).

A Figura 2 ilustra os seguintes cenários:

  • No primeiro exemplo de projeto, todos os prefixos públicos delegados no prefixo público divulgado são configurados com a migração em tempo real ativada. Nenhuma VM é configurada com endereços IP desse prefixo.

    Resultado: o prefixo público divulgado não é divulgado.

  • No segundo exemplo de projeto, todos os prefixos públicos delegados no prefixo público divulgado são configurados com a migração em tempo real ativada. Uma VM é configurada com um endereço IP desse prefixo.

    Resultado: o prefixo público divulgado é divulgado.

  • No terceiro exemplo de projeto, um prefixo público delegado dentro do prefixo público divulgado não é configurado com a migração em tempo real ativada. Nenhuma VM é configurada com endereços IP desse prefixo.

    Resultado: o prefixo público divulgado é divulgado.

Você controla quando a divulgação começa atribuindo endereços IP do seu prefixo delegado público aos recursos do Google Cloud. Para mais informações, consulte Usar a migração em tempo real.

Depois que a migração em tempo real for concluída, entre em contato com seu Engenheiro de clientes do Google Cloud para que ele possa desativar a migração em tempo real para seu prefixo. Por padrão, a migração em tempo real é desativada 30 dias após o início da divulgação do prefixo anunciado público. Se você precisar disponibilizar a opção de migração em tempo real por mais de 30 dias, entre em contato com o engenheiro de clientes.

Limitações da migração em tempo real

Ao planejar uma migração em tempo real, é importante que você entenda os seguintes requisitos e limitações:

  • Não será possível criar um prefixo de delegação público com a migração em tempo real ativada se o escopo estiver definido como global. Para mais informações sobre como gerenciar a migração em tempo real de recursos globais, consulte recomendações de migração em tempo real.

  • O prefixo mais longo que pode ser migrado é um /24 porque /24 é o tamanho máximo do prefixo roteável na Internet.

  • Não suponha que todos os colegas do Google respeitem o prefixo mais longo entre dois sites. Talvez alguns pares não tenham tabelas de roteamento completas. Como resultado, um prefixo menor anunciado pelo Google para esses pares é o único prefixo (e, portanto, o mais longo) que o peer vê. Como resultado, a existência de qualquer prefixo do Google tem precedência, mesmo que você esteja anunciando uma rota mais específica do seu local.

    Exemplo:

    Um cliente tem um /23 que é ativamente roteado do local onde está. O cliente planeja desagregar o /23 em dois prefixos /24 e anunciar as rotas mais específicas do local local. Depois da desagregação, eles planejam configurar um prefixo público de /23 divulgado para BYOIP. Elas presumem que as rotas mais específicas do local no local têm precedência sobre o prefixo mais curto de BYOIP e que o tráfego continua roteando para os prefixos locais mais específicos.

    Infelizmente, este plano só funciona parcialmente:

    • Os pares do Google que têm tabelas de roteamento completas preferem os prefixos locais /24 mais específicos.

    • Os pares do Google que não têm tabelas de roteamento completas preferem o prefixo divulgado publicamente do Google, já que as tabelas de roteamento deles não incluem os prefixos mais específicos.

  • Seu tráfego não será entregue se o Google receber tráfego para um prefixo público anunciado válido para o qual você não provisionou serviços, mesmo que haja um anúncio local ativo para o prefixo.

    Exemplo:

    Um cliente tem uma rede local com dois prefixos /24. O prefixo anunciado público é o /23 agregado.

    O cliente migra um único /24 para o Google e remove o prefixo local, mas deixa o outro /24 ativo no local.

    Essa configuração resulta em parte do roteamento de tráfego para o Google por todo o prefixo /23, mesmo que ainda haja um prefixo /24 mais específico anunciado do local local. É difícil diagnosticar esse cenário, porque vários sistemas autônomos enviam tráfego ao seu local, mas outros passam ao Google e, nesse caso, o tráfego é descartado.

Recomendações de migração em tempo real

Como prática recomendada, siga estas recomendações ao usar a migração em tempo real.

  • Divida todos os prefixos de migração em tempo real nos prefixos mais longos que reflitam como você quer anunciar esses prefixos durante a migração. Nos exemplos anteriores, o /23 precisa ser desagregado em dois prefixos /24 e anunciado como no local local antes de criar o prefixo público anunciado.

  • Crie solicitações ROA de comprimento exato de prefixo e não dependa do parâmetro de comprimento máximo para ser respeitado.

  • Certifique-se de que as solicitações ROA RPKI existem para ASN de origem local e ASN de origem do Google. Se não houver ROA para o prefixo local, a criação de uma ROA de origem do Google poderá fazer com que os ISPs de terceiros filtrem esses prefixos locais, caso estejam usando a filtragem de RPKI automática.

  • Crie prefixos públicos anunciados separados para recursos globais e recursos regionais se você precisar usar a migração em tempo real. Quando você ativa a migração em tempo real em um prefixo de delegação pública, precisa especificar uma região para o escopo. A especificação do escopo global para um prefixo de delegação pública com a migração em tempo real ativada não é compatível. Se você criar um prefixo delegado público com escopo global e migração em tempo real ativada, o prefixo será imediatamente anunciado.

    Ter prefixos regionais em um prefixo divulgado público e prefixos globais em outro prefixo anunciado permite que você os gerencie separadamente. É possível gerenciar a migração em tempo real dos recursos regionais e entrar em contato com seu Engenheiro de clientes do Google Cloud para gerenciar a migração em tempo real dos recursos globais.

Arquitetura do projeto

Recomendamos que você use as organizações para se beneficiar de recursos como permissões do IAM no nível da organização e VPC compartilhada. Consulte Como criar e gerenciar organizações para mais informações sobre como usar uma organização.

Administração de endereço do BYOIP em uma organização

Neste exemplo de um projeto que pertence a uma organização, há um projeto dedicado, Public IP project, usado para gerenciar endereços O BY. O administrador de IP público da organização criou o prefixo público e os prefixos delegados públicos no Public IP project.

Quando a VPC project precisa de endereços IP públicos, o administrador de IP público da organização cria os endereços IP no VPC project.

A organização pode conter vários projetos e o administrador de IP público pode delegar endereços IP a todos eles a partir da Public IP project.

Figura 3. É possível usar organizações e projetos para gerenciar endereços BYOIP.

BYOIP administre a VPC compartilhada

Neste exemplo de uma organização que contém a VPC compartilhada, há um projeto dedicado, Public IP project, usado para gerenciar endereços BYOIP. O administrador de IP público da organização criou o prefixo divulgado público e os prefixos delegados públicos no Public IP project.

Quando a Shared VPC host project ou os projetos de serviço relacionados precisam de endereços IP públicos, o administrador de IP público da organização cria os endereços IP na Shared VPC host project. Os projetos de serviço e de serviço podem acessar os endereços de IPO do projeto host.

A criação de endereços IP em um projeto de serviço de VPC compartilhada não é compatível.

Figura 4. É possível delegar endereços IP BY à IP a um projeto host da VPC compartilhada, mas não a um projeto de serviço. No entanto, um projeto de serviço pode usar endereços BYOIP que foram delegados para o projeto host.

Administração de endereços do BYOIP sem uma organização

Se você usa um projeto que não pertence a uma organização, não é possível criar um projeto separado para a administração de endereço do BYOIP. Crie o prefixo divulgado público e os prefixos delegados públicos no mesmo projeto que precisam dos endereços de IPO.

Cotas e limites

Há cotas e limites para prefixos delegados públicos (PDPs, na sigla em inglês) e prefixos publicados públicos (PAPs, na sigla em inglês). Para mais informações, consulte Cotas e limites da VPC.

A seguir