Saiba como usar o IP particular

Nesta página, você verá informações sobre como usar o IP particular com o Cloud SQL. Para instruções detalhadas sobre como configurar uma instância do Cloud SQL para usar o IP particular, consulte esta página.

Para soluções do Terraform para rede do Cloud SQL, consulte Soluções de configuração de rede do Cloud simplificadas.

Visão geral

Para configurar uma instância do Cloud SQL para usar o IP particular, você precisa de acesso a serviços particulares. O acesso a serviços particulares permite criar conexões particulares entre sua rede VPC e a rede VPC subjacente do produtor de serviços do Google Cloud. As entidades do Google Cloud que oferecem serviços, como o Cloud SQL, são chamadas de produtores de serviços. Cada serviço do Google Cloud cria uma sub-rede para provisionar recursos. O intervalo de endereços IP da sub-rede geralmente é um bloco CIDR /24 escolhido pelo serviço e proveniente do intervalo de endereços IP alocado.

Conexões particulares tornam os serviços acessíveis sem passar pela Internet ou usando endereços IP externos. Por esse motivo, o IP privado fornece menor latência de rede do que o IP público.

Use o acesso a serviços particulares para se conectar a instâncias do Cloud SQL:

É possível se conectar por endereço IP privado entre as regiões. Também é possível se conectar usando uma VPC compartilhada entre projetos.

Intervalos de endereços IP atribuídos

Para usar instâncias do Cloud SQL em uma rede VPC com IP particular, é necessário alocar intervalos de endereços IP para configurar o acesso a serviços particulares para essa VPC. Para organizar suas instâncias do Cloud SQL, convém alocar vários intervalos de endereços IP para a conexão particular. Ao configurar uma instância do Cloud SQL para um IP privado, é possível selecionar a rede VPC e o intervalo de endereços IP alocado.

Tamanho do intervalo alocado

Aloque intervalos IP suficientes para o Cloud SQL e outros serviços gerenciados do Google Cloud que você planeja usar. Cada um deles requer blocos de IP dedicados dos intervalos alocados. O tamanho mínimo é um único bloco /24 (256 endereços), mas o recomendado é um bloco /16 (65.536 endereços).

Ao alocar um intervalo de endereços IP, você precisa considerar o número de instâncias que planeja criar.

Máscara de sub-rede Endereços Instâncias utilizáveis do Cloud SQL
/2425650
/23512100
/221024200
/212048400
/204096800

O Cloud SQL usa intervalos CIDR /24 como uma unidade de intervalo, e cada unidade só pode ser usada para instâncias do Cloud SQL em uma única região. Por exemplo, se você criar duas instâncias do Cloud SQL, mas para duas regiões diferentes, será necessário que haja pelo menos dois intervalos CIDR /24.

Além disso, se um projeto começou a usar o Cloud SQL antes de 1º de abril de 2021, as instâncias do Postgres não podem compartilhar a mesma unidade de intervalo com instâncias do MySQL e do SQL Server, e precisam ter as próprias em todas as regiões. Projetos mais recentes não estão sujeitos a essa limitação.

Configurar o acesso a serviços particulares para sua rede

Ao configurar a conectividade do IP particular pela primeira vez em uma rede VPC específica, você precisa executar um procedimento único para configurar o acesso a serviços particulares no Cloud SQL.

Depois de estabelecer o acesso a serviços particulares, crie uma instância do Cloud SQL definida para usar o IP particular ou configure o IP particular em uma instância atual do Cloud SQL. Consulte Como configurar o IP particular para instruções detalhadas.

Toda vez que você alterar uma conexão estabelecida, será preciso atualizar vpc-peerings.

Requisitos do IP privado

Para usar o IP particular, sua rede e o ambiente do seu aplicativo precisam atender aos requisitos listados abaixo. Além disso, configurar o IP particular pela primeira vez requer permissões extras do IAM.

Requisitos de ambiente do aplicativo

  • Se você estiver se conectando a partir do GKE, será preciso executar o GKE 1.8 ou uma versão posterior em um cluster nativo da VPC.

Requisitos de API e IAM

  • Você precisa ativar a API Service Networking no projeto.

    • Se você estiver usando uma rede VPC compartilhada, também será preciso ativar a API Service Networking no projeto host.

  • Para gerenciar uma conexão de acesso a serviços privados, o usuário precisa ter as seguintes permissões do IAM. Se o usuário não tiver as permissões necessárias, você poderá receber erros de permissões insuficientes.
    • compute.networks.list
    • compute.addresses.create
    • compute.addresses.list
    • servicenetworking.services.addPeering

    Se você estiver usando uma rede VPC compartilhada, também precisará adicionar o mesmo usuário e atribuir as mesmas permissões no projeto host.

Exemplo

No exemplo a seguir, a rede VPC do cliente alocou o intervalo de endereços 10.240.0.0/16 para os serviços do Google Cloud e estabeleceu uma conexão particular que usa o intervalo alocado. Cada serviço do Google Cloud (por exemplo, o Cloud SQL) cria uma sub-rede com base no bloco alocado para provisionar novos recursos em uma determinada região, como instâncias do Cloud SQL.

Visão geral do diagrama da configuração de IP privado.

  • A conexão particular é atribuída ao intervalo alocado 10.240.0.0/16. A partir dessa alocação, os serviços do Google Cloud podem criar sub-redes em que novos recursos são provisionados.
  • No lado dos serviços do Google Cloud da conexão particular, o Google Cloud cria um projeto para o cliente. O projeto é isolado, o que significa que ele não é compartilhado com nenhum outro cliente e o cliente é cobrado apenas pelos recursos fornecidos.
  • Cada serviço do Google Cloud cria uma sub-rede para provisionar recursos. O intervalo de endereços IP da sub-rede geralmente é um bloco CIDR /24 escolhido pelo serviço e proveniente do intervalo de endereços IP alocado. Não é possível modificar a sub-rede do produtor de serviços. Um serviço provisiona novos recursos nas sub-redes regionais atuais que foram criadas anteriormente por esse serviço. Se uma sub-rede estiver cheia, o serviço criará uma nova sub-rede na mesma região.
  • As instâncias de VM na rede do cliente podem acessar recursos de serviço em qualquer região quando o serviço é compatível. No entanto, alguns serviços podem não aceitar a comunicação entre regiões. Para mais informações, consulte a documentação do serviço relevante.
  • Quando uma instância de VM se comunica com recursos de uma região diferente, os custos de transferência de dados de saída para tráfego entre regiões continuam sendo aplicáveis.
  • A instância do Cloud SQL recebe o endereço IP 10.240.0.2. Na rede VPC do cliente, as solicitações com o destino 10.240.0.2 são roteadas para a conexão particular pela rede do produtor de serviços. Quando elas alcançam a rede do serviço, essa rede encaminha a solicitação para o recurso correto.
  • O tráfego entre redes VPC é transmitido internamente na rede do Google Cloud, e não pela Internet pública.

Problemas na rede

O Cloud SQL aloca uma sub-rede /24 do intervalo de IP de acesso a serviços particulares para cada região. Por exemplo, para colocar instâncias do SQL Server em duas regiões, é necessário que o intervalo de endereços IP alocado contenha pelo menos duas sub-redes disponíveis de tamanho /24.

As conexões com uma instância do Cloud SQL usando um endereço IP privado são autorizadas automaticamente para intervalos de endereços RFC 1918. Dessa forma, todos os clientes particulares podem acessar o banco de dados sem passar pelo proxy de autenticação do Cloud SQL.

Por padrão, o Cloud SQL não aprende as rotas de sub-rede não RFC 1918 da sua VPC. É necessário atualizar o peering de rede ao Cloud SQL para exportar rotas que não sejam RFC 1918.

Segurança

O tráfego por acesso a serviços particulares é fornecido com um determinado nível de criptografia. Para mais informações, consulte Criptografia e autenticação de rede virtual do Google Cloud.

É possível configurar o proxy de autenticação do Cloud SQL para se conectar por IP particular. Além disso, ele fornece autenticação com credenciais do IAM e criptografia de ponta a ponta usando um certificado SSL/TLS com alternância.

Se os requisitos de segurança exigirem certificados SSL/TLS gerenciados por você, consulte as instruções em Como configurar o SSL/TLS.

A criação de uma rede VPC para cada instância com um endereço IP privado fornece um isolamento de rede melhor do que colocar todas as instâncias na rede VPC "padrão".

Várias conectividade de VPCs

O Cloud SQL oferece suporte a endereços IP particulares por meio do acesso a serviços particulares. Quando você cria uma instância do Cloud SQL, ela é criada na própria nuvem privada virtual (VPC), chamada de VPC do Cloud SQL. Ativar o IP privado requer a configuração de uma conexão de peering entre a VPC do Cloud SQL e sua rede VPC. Isso permite que os recursos na rede VPC acessem os endereços IP internos dos recursos do Cloud SQL na rede VPC do Cloud SQL.

Usando o Peering de rede VPC, o Cloud SQL implementa o acesso privado a serviços internamente, o que permite que os endereços IP internos se conectem entre duas redes VPC, independentemente de pertencerem ao mesmo projeto ou organização. No entanto, como o peering de rede VPC não é transitivo, ele só transmite rotas entre as duas VPCs com peering direto. Se você tiver uma VPC adicional, ela não poderá acessar os recursos do Cloud SQL usando a conexão configurada com a VPC original.

Para atenuar essa limitação e conectar sua instância do Cloud SQL a várias VPCs usando endereços IP privados, use as seguintes opções de conexão:

  • Conectar usando rotas anunciadas personalizadas
  • Conectar usando um proxy intermediário (SOCKS5)
  • Conectar usando o Cloud SQL Auth Proxy como serviço

Para mais informações sobre como conectar várias VPCs, consulte Conectar a instância a várias VPCs.

Referência rápida com tópicos sobre o IP privado

Ao gerenciar instâncias do Cloud SQL usando o IP particular, alguns dos tópicos a seguir podem ser relevantes para você:

Tópico Discussão
Redes VPC compartilhadas É possível criar instâncias do Cloud SQL com endereços IP particulares em uma rede VPC compartilhada. No entanto, não é possível atribuir um endereço IP particular em uma rede VPC compartilhada a uma instância atual do Cloud SQL.
Regiões É possível se conectar por IP privado entre as regiões.
Redes legadas Não é possível se conectar ao IP particular de uma instância do Cloud SQL a partir de uma rede legada. As redes legadas não são compatíveis com o peering de rede VPC ou com o acesso a serviços particulares.
Como remover um IP privado Depois de configurar uma instância do Cloud SQL para usar o IP particular, não será possível remover o recurso de IP particular dessa instância.
IP público e privado Use o IP público e particular para se conectar à mesma instância do Cloud SQL. Um método de conexão não afeta o outro.
Instâncias atuais do Cloud SQL Configure uma instância para usar o IP particular no momento da criação dela. Também é possível configurar uma instância atual para usar o IP privado. Quando você faz isso ou altera a rede a que a instância está conectada, essa instância é reiniciada, o que leva a alguns minutos de inatividade.
Endereços IP estáticos Para endereços IP públicos e privados, o endereço de entrada da instância do Cloud SQL é estático. não muda. O endereço de saída nem sempre é estático, exceto para endereços IP públicos de saída de réplicas de servidores externos que são sempre estáticos.
Réplicas A réplica herda o status de IP particular da instância principal dela. Não é possível configurar o IP privado diretamente em uma réplica. Caso esteja se conectando a uma réplica usando um endereço IP privado, você não precisará criar mais uma conexão particular da VPC para a réplica, porque ela também é herdada da instância principal.
O proxy de autenticação do Cloud SQL: Para se conectar a uma instância do Cloud SQL usando o IP particular, o proxy de autenticação do Cloud SQL precisa estar em um recurso com acesso à mesma rede VPC que a instância. Se a instância tiver os dois tipos de IP ativados, ele usará como padrão o IP público. Para garantir que ele esteja usando o IP particular, transmita a flag -ip_address_types=PRIVATE ao proxy de autenticação do Cloud SQL. Saiba mais.
Acesso VPC sem servidor Para se conectar por meio de uma origem sem servidor, como o ambiente padrão do App Engine, o Cloud Run, ou o Cloud Run functions, o aplicativo ou a função se conecta diretamente à instância pelo acesso VPC sem servidor sem o proxy do Cloud SQL Auth.
Peering de rede VPC Uma conexão que usa o acesso a serviços particulares depende de um peering de rede VPC. No entanto, você não cria o peering de rede VPC explicitamente, porque ele é interno ao Google Cloud. Depois de criar a conexão de acesso a serviços privados, você verá seu peering de rede VPC subjacente na página de Peering de rede VPC no console do Google Cloud. No entanto, não o exclua, a menos que queira remover a conexão particular.

Saiba mais sobre o peering de rede VPC.
VPC Service Controls O VPC Service Controls melhora a capacidade de reduzir o risco de exfiltração de dados. Com o VPC Service Controls, você cria perímetros em torno da instância do Cloud SQL. O VPC Service Controls restringe o acesso externo a recursos dentro do perímetro. Somente clientes e recursos dentro do perímetro podem interagir entre si. Para mais informações, consulte a Visão geral do VPC Service Controls. Analise também as limitações do Cloud SQL ao usar o VPC Service Controls. Para usar o VPC Service Controls com o Cloud SQL, consulte Como configurar o VPC Service Controls.
Peering transitivo Somente redes com peering direto podem se comunicar. O peering transitivo não é aceito. Ou seja, se a rede VPC N1 estabelecer peering com a N2 e a N3, mas a N2 e a N3 não tiverem uma conexão direta, a rede VPC N2 não poderá se comunicar com a rede VPC N3 por Peering de rede VPC.

Os clientes em um projeto podem se conectar a instâncias do Cloud SQL em vários projetos usando redes VPC compartilhadas.
Como migrar instâncias do Cloud SQL As instâncias do Cloud SQL só podem ser migradas entre redes de propriedade do projeto em que residem. Além disso, não é possível migrar as instâncias do Cloud SQL entre os projetos nem entre redes hospedadas por projetos diferentes.

A seguir