Redes VPC

Uma rede de nuvem privada virtual (VPC) é uma versão virtual de uma rede física que é implementada dentro da rede de produção do Google usando Andromeda.

Uma rede VPC faz o seguinte:

• Fornece conectividade às suas instâncias de máquina virtual (VM) do Compute Engine.
• Oferece balanceadores de carga de rede internos de passagem e sistemas proxy para balanceadores de carga de aplicativo internos.
• Conecta-se a redes locais usando túneis do Cloud VPN e anexos da VLAN para o Cloud Interconnect.
• Distribui o tráfego dos balanceadores de carga externos do Google Cloud para back-ends.

Os projetos podem conter várias redes VPC. A menos que você crie uma política organizacional que proíba isso, os novos projetos começam com uma rede padrão (uma rede VPC de modo automático) que tem uma sub-rede (sub-rede) em cada região.

Importante: esta página descreve as redes VPC, que são diferentes das redes legadas. As redes legadas não podem mais ser criadas e não são recomendadas para produção porque não são compatíveis com recursos avançados de rede. É possível converter uma rede legada em uma rede VPC. Para ver o tipo da sua rede, consulte Visualizar as redes.

Redes e sub-redes

O termo subnet ("sub-rede", em português) é uma abreviação da palavra subnetwork. Eles são usados indistintamente no Console do Google Cloud, nos comandos gcloud e na documentação da API.

Uma sub-rede não é a mesma coisa que uma rede VPC. As redes e sub-redes são diferentes tipos de recursos no Google Cloud.

Para mais informações, consulte Sub-redes.

Instâncias de máquina virtual

Uma instância de máquina virtual (VM) do Compute Engine é uma máquina virtual hospedada na infraestrutura do Google. Os termos instância do Compute Engine, instância de VM e VM são sinônimos. Eles são usados de maneira intercambiável no console do Google Cloud, na referência da Google Cloud CLI e na documentação da API.

As instâncias de VM incluem clusters do Google Kubernetes Engine (GKE), instâncias de ambiente flexível do App Engine e outros produtos do Google Cloud criados em VMs do Compute Engine.

Para mais informações, consulte Instâncias de máquina virtual na documentação do Compute Engine.

Especificações

As redes VPC têm as seguintes propriedades:

• Redes VPC, inclusive as rotas associadas e regras de firewall, são recursos globais. Elas não estão associadas a nenhuma região ou zona específica.

• Sub-redes são recursos regionais.

• Cada sub-rede define um intervalo de endereços IPv4. Sub-redes em redes VPC no modo personalizado também podem ter um intervalo de endereços IPv6.

• O tráfego para instâncias e a partir delas pode ser controlado com regras de firewall da rede. As regras são implementadas nas próprias VMs, portanto, o tráfego só pode ser controlado e registrado quando sai ou chega a uma VM.

• Os recursos em uma rede VPC podem se comunicar uns com os outros por meio de endereços IPv4 internos, endereços IPv6 internos ou endereços IPv6 externos, sujeitos às regras de firewall de rede aplicáveis. Para mais informações, consulte Comunicação dentro da rede.

• Instâncias com endereços IPv4 ou IPv6 internos podem se comunicar com serviços e APIs do Google. Para mais informações, consulte Opções de acesso privado para serviços.

• A administração da rede pode ser protegida usando papéis de gerenciamento de identidade e acesso (IAM, na sigla em inglês).

• Uma organização pode usar a VPC compartilhada para manter uma rede VPC em um projeto host comum. Os membros autorizados do Cloud IAM de outros projetos na mesma organização podem criar recursos que usem sub-redes da rede VPC compartilhada.

• As redes VPC podem ser conectadas a outras redes VPC em diferentes projetos ou organizações usando o Peering de rede VPC.

• As redes VPC podem ser conectadas com segurança em ambientes híbridos usando Cloud VPN ou Cloud Interconnect.

• As redes VPC são compatíveis com o tráfego GRE, incluindo o tráfego no Cloud VPN e no Cloud Interconnect. As redes VPC não são compatíveis com GRE para Cloud NAT ou para regras de encaminhamento de balanceamento de carga e encaminhamento de protocolo. A compatibilidade com GRE permite que você encerre o tráfego GRE de uma VM da Internet (endereço IP externo) e do Cloud VPN ou do Cloud Interconnect (endereço IP interno). O tráfego delimitado pode ser encaminhado para um destino acessível. O GRE permite que você use serviços como o Secure Access Service Edge (SASE) e o SD-WAN.

  Observação: o suporte a GRE para o Cloud Interconnect foi testado apenas com a GRE versão 0. Além disso, o suporte ao tráfego GRE não inclui suporte do Google Cloud para solução de problemas da sua rede de sobreposição.

• As redes VPC são compatíveis com endereços unicast IPv4 e IPv6. As redes VPC não são compatíveis com endereços broadcast ou multicast dentro da rede.

  Para mais informações sobre intervalos de sub-rede IPv6, consulte Sub-redes.

Exemplo de rede VPC

O exemplo a seguir ilustra uma rede VPC de modo personalizado com três sub-redes em duas regiões:

Exemplo de rede VPC (clique para ampliar).

• Subnet1 é definida como 10.240.0.0/24 na região us-west1.
  • Há duas instâncias de VM na zona us-west1-a nesta sub-rede. Os endereços IP vêm do intervalo disponível de endereços na subnet1.
• Subnet2 é definida como 192.168.1.0/24 na região us-east1.
  • Há duas instâncias de VM na zona us-east1-b nesta sub-rede. Os endereços IP vêm do intervalo disponível de endereços na subnet2.
• Subnet3 é definida como 10.2.0.0/16, também na região us-east1.
  • Uma instância de VM na zona us-east1-b e uma segunda instância na zona us-east1-c estão em subnet3, cada uma recebendo um endereço IP do intervalo disponível. Como as sub-redes são recursos regionais, as instâncias podem ter interfaces de rede associadas a qualquer sub-rede na mesma região que contém as zonas.

Restrições da política da organização

• Todo projeto novo começa com uma rede VPC padrão. É possível desativar a criação de redes padrão criando uma política da organização com a restrição compute.skipDefaultNetworkCreation. Projetos que herdam essa política não terão uma rede padrão.

• É possível controlar as seguintes configurações do IPv6 usando as políticas da organização:

  • Desative o uso do IPv6 externo da VPC: se definido como verdadeiro, a restrição constraints/compute.disableVpcExternalIpv6 impedirá que você configure sub-redes de pilha dupla com intervalos IPv6 externos.

  • Desative o uso do IPv6 interno da VPC: se definido como verdadeiro, a restrição constraints/compute.disableVpcInternalIpv6 impedirá que você configure sub-redes de pilha dupla com intervalos IPv6 internos.

  • Desative todo o uso do IPv6: se definido como verdadeiro, a restrição constraints/compute.disableAllIpv6 desativará a criação ou a atualização de qualquer recurso envolvido no uso do IPv6.

Para saber mais sobre as restrições, consulte Restrições da política da organização.

Modo de criação da sub-rede

O Google Cloud oferece dois tipos de redes VPC, determinadas pelo modo de criação de sub-rede:

• Quando uma rede VPC de modo automático é criada, dentro dela cria-se automaticamente uma sub-rede de cada região. Essas sub-redes criadas automaticamente usam um conjunto de intervalos de IPv4 predefinidos que se encaixam no bloco CIDR 10.128.0.0/9. À medida que novas regiões do Google Cloud forem disponibilizadas, novas sub-redes nessas regiões serão adicionadas automaticamente às redes VPC de modo automático usando um intervalo de IP desse bloco. Além das sub-redes criadas de maneira automática, é possível adicionar mais sub-redes manualmente às redes VPC de modo automático nas regiões escolhidas usando intervalos de IP fora de 10.128.0.0/9.

• Quando uma rede VPC de modo personalizado é criada, nenhuma sub-rede é criada automaticamente. Esse tipo de rede oferece controle total das sub-redes e dos intervalos de IP. Você decide quais sub-redes criar nas regiões escolhidas usando os intervalos de IP especificados.

É possível mudar uma rede VPC do modo automático para o modo personalizado. Essa é uma conversão de mão única; redes VPC de modo personalizado não podem ser alteradas para redes VPC de modo automático. Para ajudar você a decidir que tipo de rede atende a suas necessidades, consulte as considerações para redes VPC de modo automático.

Rede padrão

Cada novo projeto começa com uma rede padrão, a menos que você desative essa opção. A rede padrão é uma rede VPC de modo automático com regras de firewall já preenchidas. A rede padrão não tem regras de firewall IPv6 pré-preenchidas.

Considerações sobre redes VPC de modo automático

As redes VPC de modo automático são fáceis de configurar e usar, além de serem adequadas para casos de uso com estes atributos:

• É útil ter sub-redes criadas automaticamente em cada região.

• Os intervalos de IP predefinidos das sub-redes não se sobrepõem àqueles que você usaria para propósitos diferentes (por exemplo, conexões do Cloud VPN a recursos locais).

No entanto, as redes VPC de modo personalizado são mais flexíveis e mais adequadas para a produção. Os seguintes atributos destacam casos de uso em que redes VPC de modo personalizado são recomendadas ou obrigatórias:

• Não é necessário ter uma sub-rede criada automaticamente em cada região.

• Ter novas sub-redes criadas automaticamente à medida que as novas regiões se tornam disponíveis pode sobrepor os endereços IP usados por sub-redes criadas manualmente ou rotas estáticas, ou podem interferir no planejamento geral da rede.

• Você precisa de controle total sobre as sub-redes criadas na rede VPC, incluindo regiões e intervalos de endereços IP usados.

• Você planeja conectar sua rede VPC a outra rede:

  • Como as sub-redes de cada rede VPC de modo automático usam o mesmo intervalo predefinido de endereços IP, não é possível conectar essas redes usando o peering de rede VPC ou o Cloud VPN.

  • Como o intervalo CIDR 10.128.0.0/9 do modo automático faz parte do espaço de endereço RFC 1918 usado com frequência, as redes fora do Google Cloud podem usar um intervalo CIDR sobreposto.

• Você quer criar sub-redes com intervalos IPv6. As redes VPC de modo automático não são compatíveis com sub-redes de pilha dupla.

Importante: as redes de produção precisam ser planejadas com antecedência. Recomendamos que você use redes VPC de modo personalizado na produção.

Intervalos de sub-rede IPv4

Cada sub-rede tem um intervalo de endereços IPv4 principal. Os endereços internos primários dos seguintes recursos vêm do intervalo principal da sub-rede: instâncias de VM, balanceadores de carga internos e encaminhamento de protocolo interno. Se quiser, é possível adicionar intervalos de endereços IP secundários a uma sub-rede, que são usados apenas por intervalos de IP de alias. No entanto, é possível configurar intervalos de IP de alias para instâncias do intervalo primário ou secundário de uma sub-rede.

Cada intervalo de IPv4 primário ou secundário de todas as sub-redes de uma rede VPC precisa ser um bloco CIDR válido exclusivo. Consulte os limites por rede para o número de intervalos de IP secundários que podem ser definidos.

Suas sub-redes IPv4 não precisam formar um bloco CIDR contíguo predefinido, mas é possível fazer isso se quiser. Por exemplo, as redes VPC de modo automático criam sub-redes que se encaixam em um intervalo de IP de modo automático predefinido.

Ao criar uma sub-rede em uma rede VPC de modo personalizado, escolha o intervalo IPv4 a ser usado. Para mais informações, consulte a documentação intervalos de sub-rede, sub-rede proibida intervalos e Limitações da sub-rede IPv4 de destino.

Há quatro endereços IP inutilizáveis em cada intervalo de sub-rede IPv4 principal. Para mais informações, consulte Endereços inutilizáveis em intervalos de sub-rede IPv4.

As redes VPC de modo automático são criadas com uma sub-rede por região e recebem automaticamente novas sub-redes em novas regiões. As sub-redes têm apenas intervalos IPv4, e todos os intervalos de sub-redes cabem no bloco CIDR 10.128.0.0/9. Partes não utilizadas de 10.128.0.0/9 são reservadas para uso futuro no Google Cloud. Para informações sobre qual intervalo IPv4 é usado em cada região, consulte Intervalos de sub-rede IPv4 de modo automático.

Intervalos de sub-rede IPv6

Ao criar uma sub-rede de pilha dupla em uma rede VPC de modo personalizado, você escolhe se a sub-rede será configurada com um intervalo de sub-rede IPv6 interno ou um intervalo de sub-rede IPv6 externo.

• Os intervalos de sub-rede IPv6 internos usam endereços locais exclusivos (ULAs).

  • Os ULAs são usados para comunicação de VM para VM em redes VPC. Os ULAs para IPv6 são análogos aos endereços RFC 1918 para IPv4. Os ULAs não podem ser acessados pela Internet e não são roteáveis publicamente.

• Os intervalos de sub-redes IPv6 externos usam endereços unicast globais (GUAs).

  • Os GUAs podem ser usados para comunicação entre VMs em redes VPC e também são roteáveis na Internet.

Para mais informações sobre intervalos de sub-rede IPv6, consulte Sub-redes.

Redes compatíveis com sub-redes de pilha dupla

É possível criar sub-redes de pilha dupla em uma rede VPC de modo personalizado.

Sub-redes de pilha dupla não são compatíveis com redes VPC de modo automático, incluindo a rede padrão. Sub-redes de pilha dupla não são compatíveis com redes legadas.

Se você tiver uma rede VPC de modo automático a que gostaria de adicionar sub-redes de pilha dupla, faça o seguinte:

1. Converta a rede de modo automático para o modo personalizado.

2. Crie novas sub-redes de pilha dupla ou converta sub-redes atuais em pilha dupla.

Rotas e regras de firewall

Rotas

Rotas definem caminhos para os pacotes que saem das instâncias (tráfego de saída). Para detalhes sobre os tipos de rota do Google Cloud, consulte Rotas.

Modo de roteamento dinâmico

Cada rede VPC tem um modo de roteamento dinâmico associado que controla o comportamento de todos os Cloud Routers. Os Cloud Routers gerenciam sessões do BGP para produtos de conectividade do Google Cloud.

Para ver uma descrição das opções do modo de roteamento dinâmico, consulte Efeitos do modo de roteamento dinâmico na documentação do Cloud Router.

Divulgações de rota e endereços IP internos

Os endereços IP a seguir são divulgados dentro de uma rede VPC:

• Endereços IPv4 internos regionais

  Usado para intervalos de endereços de sub-rede IPv4 primários e secundários

• Endereços IPv6 internos e externos regionais

  Usado para intervalos de endereços de sub-rede IPv6 internos e externos

• Endereços IPv4 internos globais

  Usado para endpoints do Private Service Connect para APIs do Google

Se você conectar redes VPC usando peering de rede VPC, os intervalos de sub-rede que usam endereços IPv4 particulares serão sempre trocados. É possível controlar se os intervalos de sub-rede que usam endereços IPv4 públicos de uso privado são trocados. Endereços IPv4 internos globais nunca são trocados usando o peering. Para mais detalhes, consulte a documentação do peering da rede VPC.

Quando você conecta uma rede VPC a outra rede, como uma rede local, usando um produto de conectividade do Google Cloud, como o Cloud VPN, o Cloud Interconnect ou o dispositivo do Router:

• É possível divulgar os endereços IP internos da rede VPC para outra rede (como uma rede local).
• A conectividade entre uma rede VPC e outra rede (como uma rede local) pode usar o roteamento particular fornecido por um produto de conectividade do Google Cloud, mas os endereços IP da outra rede também podem ser roteáveis publicamente. Lembre-se disso se uma rede local usar endereços IP roteáveis publicamente.
• As instâncias de VM em uma rede VPC que contém intervalos de sub-rede com endereços IP públicos utilizados de modo privado não podem se conectar a recursos externos que usam esses mesmos endereços IP públicos.
• Tenha muito cuidado ao divulgar endereços IP públicos de uso particular para outra rede (como uma rede local), especialmente quando a outra rede puder anunciar esses endereços IP públicos na Internet.

Regras de firewall

Tanto as políticas hierárquicas de firewall quanto as regras de firewall da VPC se aplicam a pacotes enviados e recebidos de instâncias de VM (e recursos que dependem de VMs, como Google Kubernetes Engine. Os dois tipos de firewall controlam o tráfego mesmo que ele esteja entre VMs na mesma rede VPC.

Para monitorar qual regra de firewall permitiu ou negou uma conexão específica, consulte Geração de registros de regras de firewall.

Comunicações e acesso

Comunicação dentro da rede

As rotas de sub-rede geradas pelo sistema definem os caminhos para enviar tráfego entre instâncias dentro da rede usando endereços IP internos. Para que uma instância possa se comunicar com outra, as regras de firewall apropriadas também precisam ser configuradas, porque cada rede tem uma regra de firewall de negação implícita para o tráfego de entrada.

Exceto para a rede padrão, é necessário criar explicitamente regras de firewall de entrada com prioridade mais alta para permitir que as instâncias se comuniquem umas com as outras. A rede padrão inclui várias regras de firewall, além das regras implícitas, incluindo a regra default-allow-internal, que permite a comunicação de instância a instância na rede. A rede padrão também vem com regras de entrada que permitem protocolos como RDP e SSH.

As regras que vêm com a rede padrão também são apresentadas como opções para você aplicar a novas redes VPC de modo automático criadas com o console do Google Cloud.

Requisitos de acesso à Internet

Os seguintes critérios precisam ser atendidos para que uma instância tenha acesso de saída à Internet:

• A rede precisa ter uma rota de gateway de Internet padrão válida ou uma rota personalizada com o intervalo de IP de destino mais comum (0.0.0.0/0). Essa rota define o caminho para a Internet. Para saber mais, consulte Rotas.

• As regras de firewall precisam permitir o tráfego de saída da instância. A menos que seja modificada por uma regra de prioridade mais alta, a regra de permissão implícita para o tráfego de saída permite o tráfego de saída de todas as instâncias.

• Um dos seguintes itens precisa ser verdadeiro:

  • A instância precisa ter um endereço IP externo. É possível atribuir um endereço IP externo a uma instância durante ou depois da criação dela.

  • A instância precisa poder usar o Cloud NAT ou um proxy baseado em instância que seja o destino de uma rota 0.0.0.0/0 estática.

Comunicações e acesso para o App Engine

As regras de firewall da VPC aplicam-se a recursos executados na rede VPC, como VMs do Compute Engine. Para instâncias do App Engine, as regras de firewall funcionam da seguinte maneira:

• Ambiente padrão do App Engine: somente regras de firewall do Google App Engine se aplicam ao tráfego de entrada. Como as instâncias do ambiente padrão do App Engine não são executadas na rede VPC, as regras de firewall da VPC não se aplicam a elas.

• Ambiente flexível do App Engine: as regras de firewall do Google App Engine e da VPC se aplicam ao tráfego de entrada. O tráfego de entrada precisa da permissão dos dois tipos de regras de firewall. Para o tráfego de saída, aplicam-se as regras de firewall da VPC.

Para mais informações sobre como controlar o acesso a instâncias do App Engine, consulte Segurança do aplicativo.

Traceroute para endereços IP externos

Por motivos internos, o Google Cloud aumenta o contador do TTL de pacotes transferidos para os próximos saltos na rede do Google. Ferramentas como traceroute e mtr podem fornecer resultados incompletos, porque o TTL não expira em alguns saltos. Os saltos que estão dentro da rede do Google podem estar ocultos quando você envia pacotes de instâncias do Compute Engine para destinos na Internet.

O número de saltos ocultos varia de acordo com os níveis de serviço da rede, a região e outros fatores da instância. Se houver apenas alguns saltos, é possível que todos eles fiquem ocultos. Os saltos ausentes de um resultado de traceroute ou mtr não significam que o tráfego de saída seja descartado.

Não há solução alternativa para esse comportamento. É preciso levar isso em consideração ao configurar o monitoramento terceirizado que se conecta a um endereço IP externo associado a uma VM.

Importante: estatísticas de perda de sondagem são um componente dos testes de traceroute, mas é preciso tomar cuidado ao analisar os resultados. traceroute e mtr por padrão usam sondagem baseada em ICMP. A geração de respostas de sondagem ICMP normalmente é limitada por taxa (ou desativada) nos roteadores que residem no caminho de rede da sua sondagem e podem resultar na ausência de respostas de sondagem. Quando esse comportamento ocorre, é possível ver a perda de sondagem em saltos de roteamento intermediários, mas isso não deve refletir o desempenho de ponta a ponta. Se estiver procurando por perda de pacote, o único salto que geralmente é importante é o de destino.

Limites da capacidade de saída

As informações de capacidade da rede estão disponíveis na página Largura de banda da rede na documentação do Compute Engine.

Tamanho do pacote

Saiba mais sobre o tamanho do pacote em Unidade de transmissão máxima.

Unidade máxima de transmissão

Para mais informações sobre a configuração da unidade de transmissão máxima (MTU, na sigla em inglês) de uma rede VPC e as VMs conectadas, consulte a unidade de transmissão máxima.

Para saber mais sobre como alterar a MTU de uma rede VPC ou migrar VMs entre redes VPC com diferentes configurações de MTU, consulte Alterar a configuração de MTU de uma rede VPC.

Protocolos compatíveis

O Google Cloud é compatível apenas com os seguintes protocolos e cabeçalhos de extensão:

• Pacotes de dados IPv4 entre VMs: todos os protocolos IPv4.
• Pacotes de dados IPv4 entre VMs e a Internet: os protocolos ICMP, IPIP, TCP, UDP, GRE, ESP, AH e SCTP.
• Pacotes de dados IPv6 entre VMs e entre VMs e a Internet: os protocolos AH, ESP, GRE, ICMP, ICMPv6, IPIP, SCTP, TCP e UDP e os cabeçalhos de extensão "Opções de destino" e "Fragmentos". No entanto, não é possível colocar o cabeçalho Opções de destino após o cabeçalho Fragment em um pacote de dados IPv6.
• Encaminhamento de protocolo: os protocolos AH, ESP, GRE, ICMP, ICMPv6, SCTP, TCP e UDP

Para permitir pacotes de dados dos protocolos compatíveis, é necessário configurar regras de firewall ou regras de encaminhamento de protocolo com base nos seus requisitos.

Desempenho da rede

Latência

A latência medida entre regiões para redes do Google Cloud pode ser encontrada no nosso painel em tempo real. O painel mostra as métricas medianas de desempenho sobre capacidade de processamento e latência entre regiões e a metodologia do Google Cloud para reproduzir esses resultados usando o PerfKit Benchmarker.

O Google Cloud normalmente mede latências de ida e volta com menos de 55 μs no 50º percentil e latências de cauda com menos de 80 μs no 99º percentil entre instâncias de VM c2-standard-4 na mesma zona.

O Google Cloud normalmente mede latências de ida e volta com menos de 45 μs no 50º percentil e latências com menos de 60 μs no 99º percentil entre instâncias de VM c2-standard-4 na mesma rede de baixa latência (política de veiculação "compacta"). Uma política de posicionamento compacto diminui a latência da rede, garantindo que as VMs estejam localizadas fisicamente na mesma rede de baixa latência.

Metodologia: a latência dentro da zona é monitorada por meio de uma sondagem de caixa preta que executa constantemente o comparativo TCP_RR netperf entre um par de VMs do tipo c2 em cada zona em que as instâncias c2 estão disponíveis. Ele coleta resultados P50 e P99 para configuração com e sem a política de posicionamento compacto. O comparativo TCP_RR avalia o desempenho da solicitação/resposta medindo a taxa de transação. Se os aplicativos exigirem a melhor latência possível, as instâncias c2 serão recomendadas.

Perda de pacotes

O Google Cloud rastreia a perda de pacotes entre regiões medindo regularmente a perda de ida e volta em todas as regiões. Nossa meta é que a média global dessas medições seja inferior a 0,01%.

Metodologia: uma sondagem de caixa preta de VM para VM monitora a perda de pacotes para cada par de zonas usando pings e agrega os resultados em uma métrica de perda global. Essa métrica é acompanhada com uma janela de um dia.

A seguir

• Crie, modifique ou exclua redes e sub-redes VPC.

Faça um teste

Se você começou a usar o Google Cloud agora, crie uma conta para avaliar o desempenho da VPC em situações reais. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.

Teste a VPC gratuitamente