Redes da VPC

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

Uma rede de VPC faz o seguinte:

  • Fornece conetividade para as suas instâncias de máquinas virtuais (VMs) do Compute Engine.
  • Oferece balanceadores de carga de rede de passagem interna nativos e sistemas de proxy para balanceadores de carga de aplicações internos.
  • Estabelece ligação a redes no local através de túneis de Cloud VPN e anexos de VLAN para o Cloud Interconnect.
  • Distribui o tráfego de balanceadores de carga externos para back-ends. Google Cloud

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

Redes e sub-redes

Os termos sub-rede e sub-rede são sinónimos. São usados de forma intercambiável na Google Cloud consola, nos comandosgcloud e na documentação da API.

Uma sub-rede não é o mesmo que uma rede (VPC). As redes e as sub-redes são tipos de recursos diferentes no Google Cloud.

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

Instâncias de máquinas virtuais

Uma instância de máquina virtual (VM) do Compute Engine é uma máquina virtual alojada na infraestrutura da Google. Os termos instância do Compute Engine, instância de VM e VM são sinónimos. São usados de forma intercambiável na Google Cloud consola, na referência da CLI Google Cloud e na documentação da API.

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

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

Especificações

As redes de VPC têm as seguintes propriedades:

  • As redes VPC, incluindo os respetivos trajetos associados e as regras de firewall, são recursos globais. Não estão associadas a nenhuma região ou zona específica.

  • As sub-redes são recursos regionais.

  • Cada sub-rede define os seguintes intervalos de endereços IP:

    • As sub-redes apenas IPv4 e de pilha dupla definem um intervalo de endereços IPv4, enquanto as sub-redes de pilha dupla também definem um intervalo de endereços IPv6.
    • As sub-redes apenas IPv6 definem um intervalo de endereços IPv6.

    Para mais informações, consulte o artigo Tipos de sub-redes.

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

  • Os recursos numa rede VPC podem comunicar entre si através 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 a comunicação na rede.

  • As instâncias com endereços IPv4 ou IPv6 internos podem comunicar com as APIs e os serviços Google. Para mais informações, consulte o artigo Opções de acesso privado para serviços.

  • A administração da rede pode ser protegida através de funções da gestão de identidade e de acesso (IAM).

  • Uma organização pode usar a VPC partilhada para manter uma rede VPC num projeto anfitrião comum. Os principais do IAM autorizados de outros projetos na mesma organização podem criar recursos que usam sub-redes da rede VPC partilhada.

  • As redes VPC podem ser ligadas a outras redes VPC em diferentes projetos ou organizações através do intercâmbio de redes VPC.

  • As redes VPC podem ser ligadas em segurança em ambientes híbridos quando usa o Cloud VPN ou o Cloud Interconnect.

  • As redes VPC suportam tráfego GRE, incluindo tráfego no Cloud VPN e Cloud Interconnect. As redes VPC não suportam GRE para o Cloud NAT nem para regras de encaminhamento para o equilíbrio de carga e o encaminhamento de protocolos. O suporte para GRE permite-lhe terminar o tráfego GRE numa VM a partir da Internet (endereço IP externo) e do Cloud VPN ou Cloud Interconnect (endereço IP interno). Em seguida, o tráfego desencapsulado pode ser encaminhado para um destino acessível. O GRE permite-lhe usar serviços como o Secure Access Service Edge (SASE) e a SD-WAN.

  • As redes VPC suportam endereços unicast IPv4 e IPv6. As redes VPC não suportam endereços de transmissão ou multicast na rede.

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

Exemplo de rede da VPC

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

Exemplo de rede da VPC.
Exemplo de rede VPC (clique para aumentar).
  • Subnet1 é definido como 10.240.0.0/24 na região us-west1.
    • Duas instâncias de VM na zona us-west1-a estão nesta sub-rede. Os respetivos endereços IP são provenientes do intervalo de endereços disponível na subnet1.
  • Subnet2 é definido como 192.168.1.0/24 na região us-east1.
    • Duas instâncias de VM na zona us-east1-b estão nesta sub-rede. Os respetivos endereços IP são provenientes do intervalo de endereços disponível 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 na subnet3, cada uma a receber um endereço IP do respetivo intervalo disponível. Uma vez que as sub-redes são recursos regionais, as instâncias podem ter as respetivas interfaces de rede associadas a qualquer sub-rede na mesma região que contém as respetivas zonas.

Restrições de políticas da organização

  • Cada novo projeto começa com uma rede de VPC predefinida. Pode desativar a criação de redes predefinidas criando uma política da organização com a restrição compute.skipDefaultNetworkCreation. Os projetos que herdam esta política não têm uma rede predefinida.

  • Pode controlar as seguintes configurações de IPv6 através de políticas da organização:

    • Desative a utilização de IPv6 externo da VPC: se estiver definido como verdadeiro, a restrição constraints/compute.disableVpcExternalIpv6 impede a configuração de sub-redes com intervalos de IPv6 externos.

    • Desative a utilização de IPv6 interno da VPC: se estiver definido como verdadeiro, a restrição constraints/compute.disableVpcInternalIpv6 impede a configuração de sub-redes com intervalos de IPv6 internos.

    • Desativar toda a utilização de IPv6: se estiver definido como verdadeiro, a restrição constraints/compute.disableAllIpv6 desativa a criação ou a atualização de quaisquer sub-redes ou outros recursos de rede envolvidos na utilização de IPv6.

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

Modo de criação de sub-redes

Google Cloud oferece dois tipos de redes VPC, determinados pelo respetivo modo de criação de sub-redes:

Pode mudar uma rede VPC do modo automático para o modo personalizado. Esta é uma conversão unidirecional. Não é possível alterar as redes VPC no modo personalizado para redes VPC no modo automático. Para ajudar a decidir que tipo de rede satisfaz as suas necessidades, consulte as considerações para redes VPC no modo automático.

Rede predefinida

A menos que opte por desativá-la, cada novo projeto começa com uma rede predefinida. A rede predefinida é uma rede VPC no modo automático com regras de firewall IPv4 pré-preenchidas. A rede predefinida não tem regras de firewall IPv6 pré-preenchidas.

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

As redes VPC no modo automático são fáceis de configurar e usar, e são adequadas para exemplos de utilização com os seguintes atributos:

  • A criação automática de sub-redes em cada região é útil.

  • Os intervalos de IP predefinidos das sub-redes não se sobrepõem aos intervalos de IP que usaria para diferentes fins (por exemplo, ligações da VPN da Google Cloud a recursos no local).

No entanto, as redes VPC no modo personalizado são mais flexíveis e adequam-se melhor à produção. Os seguintes atributos realçam exemplos de utilização em que as redes VPC no modo personalizado são recomendadas ou obrigatórias:

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

  • A criação automática de novas sub-redes à medida que novas regiões ficam disponíveis pode sobrepor-se aos endereços IP usados por sub-redes ou rotas estáticas criadas manualmente, ou pode interferir no planeamento geral da sua rede.

  • Tem controlo total sobre as sub-redes criadas na sua rede VPC, incluindo as regiões e os intervalos de endereços IP usados.

  • Planeia ligar a sua rede VPC a outra rede:

    • Uma vez que as sub-redes de todas as redes VPC de modo automático usam o mesmo intervalo predefinido de endereços IP, não pode ligar redes VPC de modo automático entre si através da interligação de redes VPC ou da Cloud VPN.

    • Uma vez que o intervalo CIDR do modo automático faz parte do espaço de endereço RFC 1918 usado frequentemente, as redes fora de Google Cloud podem usar um intervalo CIDR sobreposto.10.128.0.0/9

  • Quer criar sub-redes com intervalos IPv6. As redes VPC de modo automático não suportam sub-redes com intervalos IPv6.

Intervalos de sub-redes IPv4

Cada sub-rede tem um intervalo de endereços IPv4 principal. Os endereços internos principais para os seguintes recursos provêm do intervalo principal da sub-rede: instâncias de VM, balanceadores de carga internos e encaminhamento de protocolos interno. Opcionalmente, pode adicionar intervalos de endereços IP secundários a uma sub-rede, que só são usados por intervalos de IPs de alias. No entanto, pode configurar intervalos de IPs de alias para instâncias do intervalo principal ou secundário de uma sub-rede.

Cada intervalo IPv4 principal ou secundário para todas as sub-redes numa rede VPC tem de ser um bloco CIDR válido único. Consulte os limites por rede para saber o número de intervalos de IP secundários que pode definir.

As suas sub-redes IPv4 não têm de formar um bloco CIDR contíguo predefinido, mas pode fazê-lo se quiser. Por exemplo, as redes VPC de modo automático criam sub-redes que se enquadram num intervalo de IP de modo automático predefinido.

Quando cria uma sub-rede numa rede VPC de modo personalizado, escolhe o intervalo IPv4 a usar. Para mais informações, consulte os intervalos válidos, os intervalos de sub-rede proibidos e as limitações para intervalos de sub-rede IPv4.

Existem quatro endereços IP inutilizáveis em cada intervalo de sub-rede IPv4 principal. Para mais informações, consulte o artigo Endereços não utilizáveis em intervalos de sub-redes IPv4.

As redes VPC de modo automático são criadas com uma sub-rede por região no momento da criaçã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 10.128.0.0/9CIDR. As partes não utilizadas de 10.128.0.0/9 estão reservadas para utilização Google Cloud futura. Para obter informações sobre o intervalo IPv4 usado em que região, consulte o artigo Intervalos de sub-redes IPv4 do modo automático.

Intervalos de sub-rede IPv6

Quando cria uma sub-rede com um intervalo IPv6 numa rede VPC no modo personalizado, escolhe se a sub-rede está configurada com um intervalo de sub-rede IPv6 interno ou um intervalo de sub-rede IPv6 externo.

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

    • Os ULAs são usados para a comunicação de VM para VM em redes VPC. As ULAs para IPv6 são análogas aos endereços RFC 1918 para IPv4. Não é possível aceder aos ULAs a partir da Internet e não são encaminháveis publicamente.

  • Os intervalos de sub-redes IPv6 externos usam endereços de transmissão única global (GUAs).

    • Os GUAs podem ser usados para a comunicação de VM para VM em redes VPC e também são encaminháveis na Internet.

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

Redes que suportam sub-redes com intervalos de endereços IPv6

Pode criar sub-redes com intervalos de endereços IPv6 numa rede VPC no modo personalizado. Para mais informações, consulte o artigo Trabalhe com sub-redes.

As sub-redes com intervalos de endereços IPv6 não são suportadas no seguinte:

  • Redes VPC de modo automático, incluindo a rede predefinida
  • Redes antigas

Se tiver uma rede VPC no modo automático à qual quer adicionar sub-redes com intervalos de endereços IPv6, pode fazer o seguinte:

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

  2. Crie novas sub-redes de duplo protocolo ou apenas IPv6. Também pode converter sub-redes apenas IPv4 existentes em pilha dupla.

Rotas e regras de firewall

Trajetos

As rotas definem caminhos para pacotes que saem de instâncias (tráfego de saída). Para obter detalhes acerca dos Google Cloud tipos de trajeto, consulte Trajetos.

Modo de planeamento de trajeto dinâmico

Cada rede VPC tem um modo de encaminhamento dinâmico associado que controla o comportamento de todos os respetivos Cloud Routers. Os Cloud Routers gerem sessões BGP para Google Cloud produtos que usam o Cloud Router.

Para uma descrição das opções do modo de encaminhamento dinâmico, consulte o artigo Modo de encaminhamento dinâmico na documentação do Cloud Router.

Anúncios de trajeto e endereços IP internos

Os seguintes endereços IP são anunciados numa rede VPC:

Se ligar redes VPC através da interligação de redes VPC, os intervalos de sub-redes que usam endereços IPv4 privados são sempre trocados. Pode controlar se os intervalos de sub-redes que usam endereços IPv4 públicos usados de forma privada são trocados e se os intervalos de sub-redes IPv6 internos e externos são trocados. Os endereços IPv4 internos globais nunca são trocados através da interligação. Para ver detalhes adicionais, consulte a documentação sobre o peering de redes VPC.

Quando liga uma rede VPC a outra rede, como uma rede nas instalações, através de um produto de conectividade, como o Cloud VPN, o Cloud Interconnect ou o dispositivo Router: Google Cloud

  • Pode anunciar os endereços IP internos da rede VPC a outra rede (como uma rede no local).
  • Embora a conetividade entre uma rede VPC e outra rede (como uma rede no local) possa usar o encaminhamento privado fornecido por um produto de conetividadeGoogle Cloud , os endereços IP da outra rede também podem ser encaminháveis publicamente. Tenha isto em atenção se uma rede no local usar endereços IP encaminháveis publicamente.
  • As instâncias de VM numa rede VPC que contenha intervalos de sub-redes com endereços IP públicos usados de forma privada não conseguem estabelecer ligação a recursos externos que usam esses mesmos endereços IP públicos.
  • Tenha especial cuidado ao anunciar endereços IP públicos usados de forma privada a outra rede (como uma rede no local), especialmente quando a outra rede pode anunciar esses endereços IP públicos à Internet.

Regras de firewall

As políticas de firewall hierárquicas e as regras de firewall da VPC aplicam-se a pacotes enviados de e para instâncias de VM (e recursos que dependem de VMs, como nós do Google Kubernetes Engine). Ambos os tipos de firewalls controlam o tráfego, mesmo que seja entre VMs na mesma rede VPC.

Para monitorizar que regra de firewall permitiu ou recusou uma ligação específica, consulte o artigo Registo de regras de firewall.

Comunicações e acesso

Comunicação na rede

As rotas de sub-rede geradas pelo sistema definem os caminhos para o envio de tráfego entre instâncias na rede através de endereços IP internos. Para que uma instância possa comunicar com outra, também têm de ser configuradas regras de firewall adequadas, uma vez que todas as redes têm uma regra de firewall de negação implícita para o tráfego de entrada.

Exceto para a rede predefinida, tem de criar explicitamente regras de firewall de entrada de prioridade mais elevada para permitir que as instâncias comuniquem entre si. A rede predefinida inclui várias regras de firewall, além das implícitas, incluindo a regra default-allow-internal, que permite a comunicação entre instâncias na rede. A rede predefinida também inclui regras de entrada que permitem protocolos como RDP e SSH.

As regras fornecidas com a rede predefinida também são apresentadas como opções para aplicar a novas redes VPC no modo automático que criar através da Google Cloud consola.

Requisitos de acesso à Internet

Os seguintes critérios têm de ser cumpridos para que uma instância tenha acesso à Internet de saída:

  • A rede tem de ter uma rota de gateway de Internet predefinida válida ou uma rota personalizada cujo intervalo de IPs de destino seja o mais geral (0.0.0.0/0 para IPv4, ::/0 para IPv6). Esta rota define o caminho para a Internet. Para mais informações, consulte o artigo Tipos de trajetos.

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

  • Uma das seguintes afirmações tem de ser verdadeira:

    • A instância tem de ter um endereço IP externo. Pode atribuir um endereço IP externo a uma instância quando esta é criada ou depois de ter sido criada.

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

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 as instâncias do App Engine, as regras de firewall funcionam da seguinte forma:

  • Ambiente padrão do App Engine: Apenas as regras de firewall do App Engine se aplicam ao tráfego de entrada. Uma vez que as instâncias do ambiente padrão do App Engine não são executadas na sua 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 App Engine e da VPC aplicam-se ao tráfego de entrada. O tráfego de entrada só é permitido se for permitido por ambos os 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 às instâncias do App Engine, consulte o artigo Segurança da app.

Traceroute para endereços IP externos

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

O número de saltos ocultos varia consoante os níveis de serviço de rede da instância, a região e outros fatores. Se existirem apenas alguns saltos, é possível que todos eles estejam ocultos. A ausência de saltos num resultado traceroute ou mtr não significa que o tráfego de saída seja ignorado.

Não existe nenhuma solução alternativa para este comportamento. Tem de o ter em conta se configurar a monitorização de terceiros que se liga a um endereço IP externo associado a uma VM.

Limites de débito de saída

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

Tamanho do pacote

Pode encontrar informações sobre o tamanho dos pacotes em Unidade de transmissão máxima.

Unidade de transmissão máxima

Para mais informações acerca da definição da unidade de transmissão máxima (MTU) para uma rede VPC e as respetivas VMs ligadas, consulte o artigo Unidade de transmissão máxima.

Para obter informações sobre como alterar a MTU de uma rede da VPC ou migrar VMs entre redes da VPC com diferentes definições de MTU, consulte o artigo Altere a definição de MTU de uma rede da VPC.

Protocolos suportados

OGoogle Cloud só suporta 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, bem como os cabeçalhos de extensão Destination Options e Fragments. No entanto, a colocação do cabeçalho Destination Options após o cabeçalho Fragment num pacote de dados IPv6 não é suportada.
  • Encaminhamento de protocolos: os protocolos AH, ESP, GRE, ICMP, ICMPv6, SCTP, TCP e UDP

Para permitir pacotes de dados dos protocolos suportados, tem de configurar regras de firewall ou regras de encaminhamento de protocolos com base nos seus requisitos.

Perfis de rede para exemplos de utilização específicos

Google Cloud usa o recurso de perfil de rede para pré-configurar determinadas propriedades numa rede VPC para um exemplo de utilização específico. Opcionalmente, pode especificar um perfil de rede fornecido por Google Cloud quando criar a sua rede.

O exemplo de utilização suportado pelos perfis de rede é a execução de cargas de trabalho de IA em máquinas com interfaces de rede (NICs) que suportam o acesso direto à memória remoto (RDMA). OGoogle Cloud fornece perfis de rede RDMA que lhe permitem criar redes de nuvem virtual privada (VPC) que suportam a conetividade RDMA.

Para mais informações, consulte a vista geral dos perfis de rede.

Para mais informações sobre a execução de cargas de trabalho de IA no Google Cloud, consulte a documentação do hipercomputador de IA.

Desempenho da rede

Latência

Pode encontrar a latência entre regiões medida para as Google Cloud redes no nosso painel de controlo em direto. O painel de controlo mostra a latência inter-regiões mediana e as métricas de desempenho de débito, bem como a metodologia para reproduzir estes resultados através do PerfKit Benchmarker. Google Cloud

Normalmente, oGoogle Cloud mede latências de ida e volta inferiores a 55 μs no 50.º percentil e latências de cauda inferiores a 80 μs no 99.º percentil entre instâncias de VM c2-standard-4 na mesma zona.

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

Metodologia: a latência intrazona é monitorizada através de um verificador de caixa preta que executa constantemente o teste de desempenho netperf TCP_RR entre um par de VMs do tipo c2 em todas as zonas onde as instâncias c2 estão disponíveis. Recolhe resultados P50 e P99 para a configuração com e sem a política de posicionamento compacta. O teste de referência TCP_RR mede o desempenho de pedido/resposta através da medição da taxa de transação. Se as suas aplicações exigirem a melhor latência possível, recomendamos as instâncias c2.

Perda de pacotes

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

Metodologia: um verificador de caixa negra de VM para VM monitoriza a perda de pacotes para cada par de zonas através de pings e agrega os resultados numa métrica de perda global. Esta métrica é monitorizada com um período de um dia.

O que se segue?

Experimente

Se está a usar o Google Cloud pela primeira vez, crie uma conta para avaliar o desempenho da VPC em cenários reais. Os novos clientes também recebem 300 USD em créditos gratuitos para executar, testar e implementar cargas de trabalho.

Experimente a VPC gratuitamente