A rede é necessária para que os recursos se comuniquem na sua organização do Google Cloud e entre o ambiente de nuvem e o ambiente local. Nesta seção, descrevemos a estrutura no blueprint para redes VPC, espaço de endereço IP, DNS, políticas de firewall e conectividade com o ambiente local.
Topologia de rede
O repositório de blueprints oferece as seguintes opções para a topologia de rede:
- Use redes VPC compartilhadas separadas para cada ambiente, sem tráfego de rede diretamente permitido entre os ambientes.
- Use um modelo hub-and-spoke que adicione uma rede hub para conectar cada ambiente no Google Cloud, com o tráfego de rede entre ambientes controlados por um dispositivo virtual de rede (NVA, na sigla em inglês).
Escolha a topologia de rede VPC compartilhada quando não quiser conectividade de rede direta entre os ambientes. Escolha a topologia de rede hub e spoke quando quiser permitir a conectividade de rede entre ambientes filtrados por um NVA, como quando você depende de ferramentas atuais que exigem uma rede direta para cada servidor no seu ambiente.
As duas topologias usam a VPC compartilhada como uma construção de rede principal porque ela permite uma separação clara de responsabilidades. Os administradores de rede gerenciam recursos de rede em um projeto host centralizado, e as equipes de carga de trabalho implantam os próprios recursos de aplicativos e consomem os recursos de rede em projetos de serviço anexados ao projeto host.
As duas topologias incluem uma versão básica e restrita de cada rede VPC. A rede VPC base é usada para recursos que contêm dados não confidenciais, e a rede VPC restrita é usada para recursos com dados confidenciais que exigem VPC Service Controls. Para mais informações sobre como implementar o VPC Service Controls, consulte Proteger recursos com o VPC Service Controls.
Topologia de rede VPC compartilhada dupla
Se você precisar de isolamento de rede entre suas redes de desenvolvimento, de não produção e de produção no Google Cloud, recomendamos a topologia de rede VPC compartilhada dupla. Essa topologia usa redes VPC compartilhadas separadas para cada ambiente, com cada ambiente também dividido entre uma rede VPC compartilhada de base e uma rede VPC compartilhada restrita.
O diagrama a seguir mostra a topologia de rede VPC compartilhada dupla.
O diagrama descreve esses conceitos principais da topologia dupla de VPC compartilhada:
- Cada ambiente (produção, não produção e desenvolvimento) tem uma rede VPC compartilhada para a rede de base e uma rede VPC compartilhada para a rede restrita. Este diagrama mostra apenas o ambiente de produção, mas o mesmo padrão é repetido para cada ambiente.
- Cada rede VPC compartilhada tem duas sub-redes, e cada sub-rede está em uma região diferente.
- A conectividade com recursos locais é ativada por quatro anexos da VLAN para a instância da Interconexão dedicada em cada rede VPC compartilhada usando quatro serviços do Cloud Router (dois em cada região para redundância). Para mais informações, consulte Conectividade híbrida entre o ambiente local e o Google Cloud.
Por projeto, essa topologia não permite que o tráfego de rede flua diretamente entre ambientes. Se você precisar que o tráfego de rede flua diretamente entre ambientes, será necessário realizar outras etapas para permitir esse caminho de rede. Por exemplo, é possível configurar endpoints do Private Service Connect para expor um serviço de uma rede VPC para outra. Como alternativa, é possível configurar sua rede local para deixar o tráfego fluir de um ambiente do Google Cloud para o ambiente local e, em seguida, para outro ambiente do Google Cloud.
Topologia de rede hub e spoke
Se você implantar recursos no Google Cloud que exigem um caminho de rede direto para recursos em vários ambientes, recomendamos a topologia de rede hub and spoke.
A topologia hub e spoke usa vários dos conceitos que fazem parte da topologia de VPC compartilhada dupla, mas modifica a topologia para adicionar uma rede hub. O diagrama a seguir mostra a topologia hub e spoke.
O diagrama descreve estes conceitos-chave da topologia de rede hub e spoke:
- Esse modelo adiciona uma rede hub e cada uma das redes de desenvolvimento, de não produção e de produção (spoke) é conectada à rede do hub por peering de rede VPC. Como alternativa, se você antecipar que o limite da cota seja excedido, use um gateway de VPN de alta disponibilidade.
- A conectividade com redes locais é permitida apenas pela rede do hub. Todas as redes spoke podem se comunicar com recursos compartilhados na rede do hub e usar esse caminho para se conectar a redes locais.
- As redes de hub incluem um NVA para cada região, implantado de forma redundante atrás de instâncias do balanceador de carga de rede interno. Esse NVA funciona como o gateway para permitir ou negar a comunicação entre redes spoke.
- A rede do hub também hospeda ferramentas que exigem conectividade com todas as outras redes. Por exemplo, é possível implantar ferramentas em instâncias de VM para gerenciar configurações no ambiente comum.
- O modelo hub e spoke é duplicado para uma versão base e uma versão restrita de cada rede.
Para ativar o tráfego spoke para spoke, o blueprint implanta NVAs na rede VPC compartilhada hub que atuam como gateways entre redes. Essas rotas são trocadas do hub para as redes VPC spoke por meio da troca de rotas personalizadas. Nesse cenário, a conectividade entre spokes precisa ser roteada por meio do NVA porque o peering de rede VPC não é transitivo e, portanto, as redes VPC spoke não podem trocar dados entre si diretamente. É preciso configurar os dispositivos virtuais para permitir seletivamente o tráfego entre spokes.
Padrões de implantação do projeto
Ao criar novos projetos para cargas de trabalho, é preciso decidir como os recursos desse projeto se conectam à rede atual. A tabela a seguir descreve os padrões de implantação de projetos que são usados no blueprint.
| Padrão | Descrição | Exemplo de uso |
|---|---|---|
| Projetos base compartilhados | Esses projetos são configurados como projetos de serviço para um projeto host de VPC compartilhada de base. Use esse padrão quando os recursos do projeto tiverem os seguintes critérios:
|
example_base_shared_vpc_project.tf |
| Projetos restritos compartilhados | Esses projetos são configurados como projetos de serviço para um projeto host de VPC compartilhada restrito. Use esse padrão quando os recursos do projeto tiverem os seguintes critérios:
|
example_restricted_shared_vpc_project.tf |
| Projetos flutuantes | Projetos flutuantes não estão conectados a outras redes VPC em sua topologia. Use esse padrão quando os recursos do projeto tiverem os seguintes critérios:
Talvez você queira manter a rede VPC de um projeto flutuante separada da topologia da rede VPC principal, mas também queira expor um número limitado de endpoints entre as redes. Nesse caso, publique serviços usando o Private Service Connect para compartilhar o acesso a um endpoint individual em redes VPC sem expor toda a rede. |
example_floating_project.tf |
| Projetos de peering | Projetos de peering criam as próprias redes VPC e fazem peering com outras redes VPC na sua topologia. Use esse padrão quando os recursos do projeto tiverem os seguintes critérios:
Se você criar projetos de peering, é sua responsabilidade alocar intervalos de endereços IP não conflitantes e planejar a cota do grupo de peering. |
example_peering_project.tf |
Alocação de endereço IP
Nesta seção, você verá como a arquitetura de blueprint aloca intervalos de endereços IP. Talvez seja necessário alterar os intervalos de endereços IP específicos usados com base na disponibilidade do endereço IP no ambiente híbrido atual.
A tabela a seguir fornece um detalhamento do espaço de endereços IP alocado para o blueprint. O ambiente hub só se aplica à topologia hub e spoke.
| Finalidade | Tipo de VPC | Região | Ambiente hub | Ambiente de desenvolvimento | Ambiente que não seja de produção | Ambiente de produção |
|---|---|---|---|---|---|---|
| Intervalos de sub-rede principal | Base | Região 1 | 10.0.0.0/18 | 10.0.64.0/18 | 10.0.128.0/18 | 10.0.192.0/18 |
| Região 2 | 10.1.0.0/18 | 10.1.64.0/18 | 10.1.128.0/18 | 10.1.192.0/18 | ||
| Não alocado | 10.{2-7}.0.0/18 | 10.{2-7}.64.0/18 | 10.{2-7}.128.0/18 | 10.{2-7}.192.0/18 | ||
| Restrito | Região 1 | 10.8.0.0/18 | 10.8.64.0/18 | 10.8.128.0/18 | 10.8.192.0/18 | |
| Região 2 | 10.9.0.0/18 | 10.9.64.0/18 | 10.9.128.0/18 | 10.9.192.0/18 | ||
| Não alocado | 10.{10-15}.0.0/18 | 10.{10-15}.64.0/18 | 10.{10-15}.128.0/18 | 10.{10-15}.192.0/18 | ||
| Acesso a serviços particulares | Base | Global | 10.16.0.0/21 | 10.16.8.0/21 | 10.16.16.0/21 | 10.16.24.0/21 |
| Restrito | Global | 10.16.32.0/21 | 10.16.40.0/21 | 10.16.48.0/21 | 10.16.56.0/21 | |
| Endpoints do Private Service Connect | Base | Global | 10.17.0.1/32 | 10.17.0.2/32 | 10.17.0.3/32 | 10.17.0.4/32 |
| Restrito | Global | 10.17.0.5/32 | 10.17.0.6/32 | 10.17.0.7/32 | 10.17.0.8/32 | |
| Sub-redes somente proxy | Base | Região 1 | 10.18.0.0/23 | 10.18.2.0/23 | 10.18.4.0/23 | 10.18.6.0/23 |
| Região 2 | 10.19.0.0/23 | 10.19.2.0/23 | 10.19.4.0/23 | 10.19.6.0/23 | ||
| Não alocado | 10.{20-25}.0.0/23 | 10.{20-25}.2.0/23 | 10.{20-25}.4.0/23 | 10.{20-25}.6.0/23 | ||
| Restrito | Região 1 | 10.26.0.0/23 | 10.26.2.0/23 | 10.26.4.0/23 | 10.26.6.0/23 | |
| Região 2 | 10.27.0.0/23 | 10.27.2.0/23 | 10.27.4.0/23 | 10.27.6.0/23 | ||
| Não alocado | 10.{28-33}.0.0/23 | 10.{28-33}.2.0/23 | 10.{28-33}.4.0/23 | 10.{28-33}.6.0/23 | ||
| Intervalos de sub-rede secundários | Base | Região 1 | 100.64.0.0/18 | 100.64.64.0/18 | 100.64.128.0/18 | 100.64.192.0/18 |
| Região 2 | 100.65.0.0/18 | 100.65.64.0/18 | 100.65.128.0/18 | 100.65.192.0/18 | ||
| Não alocado | 100.{66-71}.0.0/18 | 100.{66-71}.64.0/18 | 100.{66-71}.128.0/18 | 100.{66-71}.192.0/18 | ||
| Restrito | Região 1 | 100.72.0.0/18 | 100.72.64.0/18 | 100.72.128.0/18 | 100.72.192.0/18 | |
| Região 2 | 100.73.0.0/18 | 100.73.64.0/18 | 100.73.128.0/18 | 100.73.192.0/18 | ||
| Não alocado | 100.{74-79}.0.0/18 | 100.{74-79}.64.0/18 | 100.{74-79}.128.0/18 | 100.{74-79}.192.0/18 |
A tabela anterior demonstra esses conceitos para alocar intervalos de endereços IP:
- A alocação de endereços IP é subdividida em intervalos para cada combinação de VPC compartilhada de base, VPC compartilhada restrita, região e ambiente.
- Alguns recursos são globais e não exigem subdivisões para cada região.
- Por padrão, para recursos regionais, o blueprint é implantado em duas regiões. Além disso, há intervalos de endereços IP não utilizados. Assim, você pode expandir para mais seis regiões.
- A rede hub é usada apenas na topologia de rede hub e spoke, enquanto os ambientes de desenvolvimento, não produção e produção são usados nas duas topologias de rede.
A tabela a seguir mostra como cada tipo de intervalo de endereços IP é usado.
| Finalidade | Descrição |
|---|---|
| Intervalos de sub-rede principal | Os recursos implantados na rede VPC, como instâncias de máquina virtual, usam endereços IP internos desses intervalos. |
| Acesso privado a serviços | Alguns serviços do Google Cloud, como o Cloud SQL, exigem que você pré-aloque um intervalo de sub-rede para o acesso a serviços particulares. O blueprint reserva um intervalo /21 globalmente para cada uma das redes VPC compartilhadas com o objetivo de alocar endereços IP para serviços que exigem acesso a serviços particulares. Ao criar um serviço que depende do acesso a serviços particulares, você aloca uma sub-rede /24 regional do intervalo /21 reservado. |
| Private Service Connect | O blueprint provisiona cada rede VPC com um endpoint do Private Service Connect para se comunicar com as APIs do Google Cloud. Esse endpoint permite que os recursos na rede VPC alcancem as APIs do Google Cloud sem depender de tráfego de saída para a Internet ou de intervalos de Internet anunciados publicamente. |
| Balanceadores de carga baseados em proxy | Alguns tipos de balanceadores de carga de aplicativo exigem que você pré-aloque sub-redes somente proxy. Embora o blueprint não implante balanceadores de carga de aplicativo que exigem esse intervalo, alocar intervalos com antecedência ajuda a reduzir o atrito das cargas de trabalho quando elas precisam solicitar um novo intervalo de sub-rede para ativar determinado balanceador de carga do Google Cloud. |
| Intervalos de sub-rede secundários | Alguns casos de uso, como cargas de trabalho baseadas em contêiner, exigem intervalos secundários. O blueprint aloca intervalos do espaço de endereços IP RFC 6598 para intervalos secundários. |
Configuração de DNS centralizada
Para resolução de DNS entre o Google Cloud e ambientes locais, recomendamos que você use uma abordagem híbrida com dois sistemas DNS autoritativos. Nessa abordagem, o Cloud DNS lida com a resolução de DNS autoritativa para o ambiente do Google Cloud, e os servidores DNS locais atuais processam a resolução de DNS autoritativo para recursos locais. O ambiente local e o do Google Cloud realizam buscas DNS entre ambientes por meio de solicitações de encaminhamento.
No diagrama a seguir, demonstramos a topologia de DNS nas várias redes VPC usadas no blueprint.
O diagrama descreve os seguintes componentes do design de DNS implantado pelo blueprint:
- O projeto do hub de DNS na pasta comum é o ponto central da troca de DNS entre o ambiente local e o do Google Cloud. O encaminhamento de DNS usa as mesmas
instâncias de Interconexão dedicada e Cloud Routers
que já estão configurados na topologia de rede.
- Na topologia de VPC compartilhada dupla, o hub DNS usa a rede VPC compartilhada de produção base.
- Na topologia hub-and-spoke, o hub DNS usa a rede VPC compartilhada do hub de base.
- Os servidores em cada rede VPC compartilhada podem resolver registros DNS de outras redes VPC compartilhadas por meio do encaminhamento de DNS, que é configurado entre o Cloud DNS em cada projeto host da VPC compartilhada. e o hub DNS.
- Os servidores locais podem resolver registros DNS em ambientes do Google Cloud usando políticas de servidor DNS que permitem consultas de servidores locais. O blueprint configura uma política de servidor de entrada no hub DNS para alocar endereços IP, e os servidores DNS locais encaminham as solicitações para esses endereços. Todas as solicitações de DNS para o Google Cloud chegam ao hub de DNS primeiro, que resolve os registros dos pares de DNS.
- Os servidores no Google Cloud podem resolver registros DNS no ambiente local usando zonas de encaminhamento que consultam servidores locais. Todas as solicitações de DNS para o ambiente local são originadas do hub de DNS. A origem da solicitação DNS é 35.199.192.0/19.
Políticas de firewall
O Google Cloud tem vários tipos de políticas de firewall. As políticas hierárquicas de firewall são aplicadas no nível da organização ou da pasta para herdar as regras da política de firewall de forma consistente em todos os recursos na hierarquia. Além disso, é possível configurar políticas de firewall de rede para cada rede VPC. O blueprint combina essas políticas de firewall para aplicar configurações comuns em todos os ambientes usando políticas hierárquicas de firewall e aplicar configurações mais específicas em cada rede VPC individual usando políticas de firewall de rede.
O blueprint não usa regras de firewall da VPC legada. Recomendamos usar apenas políticas de firewall e evite misturar o uso com regras de firewall da VPC legada.
Políticas de firewall hierárquicas
O blueprint define uma única política hierárquica de firewall e anexa essa política a cada uma das pastas comuns, de produção, de não produção, de desenvolvimento e de inicialização. Essa política hierárquica de firewall contém as regras que precisam ser aplicadas amplamente em todos os ambientes e delega a avaliação de regras mais granulares à política de firewall de rede para cada ambiente individual.
Na tabela a seguir, descrevemos as regras da política hierárquica de firewall implantadas pelo blueprint.
| Descrição da regra | Direção do tráfego | Filtro (intervalo IPv4) | Protocolos e portas | Ação |
|---|---|---|---|---|
| Delegar a avaliação do tráfego de entrada da RFC 1918 aos níveis inferiores da hierarquia. | Ingress |
192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 |
all |
Go to next |
| Delegar a avaliação do tráfego de saída à RFC 1918 para níveis inferiores na hierarquia. | Egress |
192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 |
all |
Go to next |
| IAP para encaminhamento de TCP | Ingress |
35.235.240.0/20 |
tcp:22,3390 |
Allow |
| Ativação do Windows Server | Egress |
35.190.247.13/32 |
tcp:1688 |
Allow |
| Verificações de integridade do Cloud Load Balancing. | Ingress |
130.211.0.0/22, 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22 |
tcp:80,443 |
Allow |
Políticas de firewall de rede
O blueprint configura uma política de firewall de rede para cada rede. Cada política de firewall de rede começa com um conjunto mínimo de regras que permitem o acesso aos serviços do Google Cloud e negam a saída para todos os outros endereços IP.
No modelo hub e spoke, as políticas de firewall de rede contêm outras regras para permitir a comunicação entre spokes. A política de firewall de rede permite o tráfego de saída de um para o hub ou outro spoke e permite o tráfego de entrada do NVA na rede hub.
Na tabela a seguir, descrevemos as regras da política de firewall de rede global implantadas para cada rede VPC no blueprint.
| Descrição da regra | Direção do tráfego | Filtro | Protocolos e portas |
|---|---|---|---|
| Permitir tráfego de saída para as APIs do Google Cloud. | Egress |
O endpoint do Private Service Connect que é configurado para cada rede individual. Consulte Acesso particular às APIs do Google. | tcp:443 |
| Negar tráfego de saída que não corresponda a outras regras. | Egress |
todos | all |
Permitir tráfego de saída de um spoke para outro spoke (somente para o modelo hub e spoke). |
Egress |
A agregação de todos os endereços IP usados na topologia "hub and spoke". O tráfego que sai de uma VPC spoke é encaminhado para o NVA na rede do hub primeiro. | all |
Permitir o tráfego de entrada de um spoke do NVA na rede hub (somente para o modelo hub e spoke). |
Ingress |
Tráfego originado dos NVAs na rede do hub. | all |
Quando você implanta o blueprint pela primeira vez, uma instância de VM em uma rede VPC pode se comunicar com os serviços do Google Cloud, mas não com outros recursos de infraestrutura na mesma rede VPC. Para permitir que as instâncias de VM se comuniquem, adicione outras regras à política de firewall de rede e às tags que permitam explicitamente a comunicação entre as instâncias de VM. As tags são adicionadas às instâncias de VM, e o tráfego é avaliado em relação a elas. As tags também têm controles do IAM para que você possa defini-las centralmente e delegar o uso a outras equipes.
O diagrama a seguir mostra um exemplo de como adicionar tags personalizadas e regras de política de firewall de rede para permitir que as cargas de trabalho se comuniquem dentro de uma rede VPC.
O diagrama demonstra os seguintes conceitos deste exemplo:
- A política de firewall de rede contém a Regra 1 que nega o tráfego de saída de todas as origens com prioridade 65530.
- A política de firewall de rede contém a regra 2, que permite o tráfego de entrada de instâncias com a tag
service=frontendpara instâncias com a tagservice=backendcom prioridade 999. - A VM "instance-2" pode receber tráfego da "instance-1" porque o tráfego corresponde às tags permitidas pela regra 2. A regra 2 é correspondida antes da avaliação da Regra 1 com base no valor de prioridade.
- A VM instance-3 não recebe tráfego. A única regra da política de firewall que corresponde a esse tráfego é a regra 1. Portanto, o tráfego de saída da instância-1 é negado.
Acesso particular às APIs do Google Cloud
Para permitir que os recursos nas redes VPC ou no ambiente local acessem os serviços do Google Cloud, recomendamos a conectividade particular em vez do tráfego de saída da Internet para endpoints de APIs públicos. O blueprint configura o Acesso privado do Google em cada sub-rede e cria endpoints internos com o Private Service Connect para se comunicar com os serviços do Google Cloud. Usados juntos, esses controles permitem um caminho particular para os serviços do Google Cloud, sem depender do tráfego de saída da Internet ou de intervalos de Internet anunciados publicamente.
O blueprint configura endpoints do Private Service Connect com
pacotes de API
para diferenciar quais serviços podem ser acessados em qual rede. A rede
base usa o pacote all-apis e pode acessar qualquer serviço do Google, e a
rede restrita usa o pacote vpcsc, que permite acesso a um conjunto
limitado de serviços que
oferecer suporte ao VPC Service Controls.
Para acesso de hosts localizados em um ambiente local, recomendamos usar uma convenção de FQDN personalizado para cada endpoint, conforme descrito na tabela a seguir. O blueprint usa um endpoint exclusivo do Private Service Connect para cada rede VPC, configurado para acessar um conjunto diferente de pacotes de APIs. Portanto, pense em como rotear o tráfego do serviço do ambiente local para a rede VPC com o endpoint de API correto e, se você estiver usando o VPC Service Controls, verifique se o tráfego para o Os serviços do Cloud alcançam o endpoint dentro do perímetro pretendido. Configure os controles locais para DNS, firewalls e roteadores para permitir acesso a esses endpoints e configure hosts locais para usar o endpoint apropriado. Para mais informações, consulte Acessar APIs do Google por meio de endpoints.
Veja na tabela a seguir os endpoints do Private Service Connect criados para cada rede.
| VPC | Ambiente | Pacote de API | Endereço IP do endpoint do Private Service Connect | FQDN personalizado | ||||
|---|---|---|---|---|---|---|---|---|
| Base | Comum | all-apis |
10.17.0.1/32 | c.private.googleapis.com |
||||
| Desenvolvimento | all-apis |
10.17.0.2/32 | d.private.googleapis.com |
|||||
| Não produção | all-apis |
10.17.0.3/32 | n.private.googleapis.com |
|||||
| Produção | all-apis |
10.17.0.4/32 | p.private.googleapis.com |
|||||
| Restrito | Comum | vpcsc |
10.17.0.5/32 | c.restricted.googleapis.com |
||||
| Desenvolvimento | vpcsc |
10.17.0.6/32 | d.restricted.googleapis.com |
|||||
| Não produção | vpcsc |
10.17.0.7/32 | n.restricted.googleapis.com |
|||||
| Produção | vpcsc |
10.17.0.8/32 | p.restricted.googleapis.com |
|||||
Para garantir que o tráfego dos serviços do Google Cloud tenha uma busca DNS para o endpoint correto, o blueprint configura zonas de DNS particulares para cada rede VPC. A tabela a seguir descreve essas zonas DNS particulares.
| Nome da zona particular | Nome do DNS | Tipo de registro | Dados |
|---|---|---|---|
googleapis.com. |
*.googleapis.com. |
CNAME |
private.googleapis.com. (para redes
base) ou restricted.googleapis.com. (para
redes restritas) |
private.googleapis.com (para redes
base) ou restricted.googleapis.com (para
redes restritas) |
A |
O endereço IP do endpoint do Private Service Connect para essa rede VPC. | |
gcr.io. |
*.gcr.io |
CNAME |
gcr.io. |
gcr.io |
A |
O endereço IP do endpoint do Private Service Connect para essa rede VPC. | |
pkg.dev. |
*.pkg.dev. |
CNAME |
pkg.dev. |
pkg.dev. |
A |
O endereço IP do endpoint do Private Service Connect para essa rede VPC. |
O blueprint tem outras configurações para garantir que esses endpoints do Private Service Connect sejam usados de maneira consistente. Cada rede VPC compartilhada também aplica o seguinte:
- Uma regra de política de firewall de rede que permita o tráfego de saída de todas as origens para o endereço IP do endpoint do Private Service Connect na TCP:443.
- Uma regra da política de firewall de rede que nega o tráfego de saída para 0.0.0.0/0, que inclui os domínios padrão usados para acesso aos serviços do Google Cloud.
Conectividade à Internet
O blueprint não permite tráfego de entrada ou saída entre as redes VPC e a Internet. Para cargas de trabalho que exigem conectividade com a Internet, você precisa seguir outras etapas para criar os caminhos de acesso necessários.
Para cargas de trabalho que exigem tráfego de saída para a Internet, recomendamos gerenciar o tráfego de saída por meio do Cloud NAT para permitir o tráfego de saída sem conexões de entrada não solicitadas, ou por meio de Use o Secure Web Proxy para ter um controle mais granular e permitir o tráfego de saída apenas para serviços da Web confiáveis.
Para cargas de trabalho que exigem tráfego de entrada da Internet, recomendamos que você projete sua carga de trabalho com o Cloud Load Balancing e o Google Cloud Armor para se beneficiar das proteções contra DDoS e WAF.
Não recomendamos que você projete cargas de trabalho que permitam conectividade direta entre a Internet e uma VM usando um endereço IP externo na VM.
Conectividade híbrida entre um ambiente no local e o Google Cloud
Para estabelecer a conectividade entre o ambiente local e o Google Cloud, recomendamos que você use a Interconexão dedicada para maximizar a segurança e a confiabilidade. Uma Interconexão dedicada é um link direto entre a rede local e o Google Cloud.
No diagrama a seguir, apresentamos a conectividade híbrida entre o ambiente local e uma rede de nuvem privada virtual do Google.
O diagrama descreve os seguintes componentes do padrão de disponibilidade de 99,99% na Interconexão dedicada:
- Quatro conexões de Interconexão dedicada, com duas conexões em uma área metropolitana (metro) e duas conexões em outra. Em cada área metropolitana, há duas zonas distintas na instalação de colocation
- As conexões são divididas em dois pares, e cada um deles conectado a um data center local separado.
- Os anexos da VLAN são usados para conectar cada instância de Interconexão dedicada aos Cloud Routers anexados à topologia da VPC compartilhada.
- Cada rede VPC compartilhada tem quatro Cloud Routers, dois em
cada região, com o modo de roteamento dinâmico definido como
global. Assim, cada Cloud Router pode anunciar todas as sub-redes, independentemente da região.
Com o roteamento dinâmico global, o Cloud Router anuncia rotas para todas as sub-redes na rede VPC. O Cloud Router divulga rotas para sub-redes remotas (sub-redes fora da região do Cloud Router) com prioridade mais baixa em comparação com as sub-redes locais (sub-redes que estão na região do Cloud Router). Também é possível alterar os prefixos e as prioridades anunciados ao configurar a sessão do BGP para um Cloud Router.
O tráfego do Google Cloud para um ambiente local usa o Cloud Router mais próximo dos recursos da nuvem. Em uma única região, várias rotas para redes locais têm o mesmo valor de discriminador de várias saídas (MED, na sigla em inglês), e o Google Cloud usa vários caminhos de custo igual (ECMP, na sigla em inglês) para distribuir o tráfego de saída entre todas as rotas possíveis.
Mudanças na configuração no local
Para configurar a conectividade entre o ambiente local e o Google Cloud, configure outras alterações no seu ambiente local. O código do Terraform no blueprint configura automaticamente os recursos do Google Cloud, mas não modifica nenhum dos recursos de rede no local.
Alguns dos componentes de conectividade híbrida do seu ambiente local para o Google Cloud são ativados automaticamente pelo blueprint, incluindo o seguinte:
- O Cloud DNS é configurado com encaminhamento de DNS entre todas as redes VPC compartilhadas para um único hub, conforme descrito em Configuração do DNS. Uma política de servidor do Cloud DNS é configurada com endereços IP de encaminhador de entrada.
- O Cloud Router está configurado para exportar rotas para todas as sub-redes e rotas personalizadas para os endereços IP usados pelos endpoints do Private Service Connect.
Para ativar a conectividade híbrida, você precisa seguir estas etapas:
- Solicitar uma conexão de interconexão dedicada
- Configure roteadores e firewalls locais para permitir o tráfego de saída para o espaço de endereços IP internos definido em Alocação do espaço de endereços IP.
- Configure os servidores DNS locais para encaminhar buscas DNS vinculadas ao Google Cloud para os endereços IP do encaminhador de entrada que já estão configurados pelo blueprint.
- Configure os servidores DNS, os firewalls e os roteadores locais para aceitar consultas DNS da zona de encaminhamento do Cloud DNS (35.199.192.0/19).
- Configure servidores DNS locais para responder a consultas de hosts locais para serviços do Google Cloud com os endereços IP definidos no acesso particular às APIs do Cloud.
- Para criptografia em trânsito pela conexão de Interconexão dedicada, configure MACsec para Cloud Interconnect ou configurar VPN de alta disponibilidade pelo Cloud Interconnect para criptografia IPsec.
Se você quiser mais informações, consulte Como configurar o Acesso privado do Google para hosts locais.
A seguir
- Leia sobre controles de detecção (próximo documento desta série).