A rede é necessária para que os recursos comuniquem na sua organização Google Cloud e entre o seu ambiente na nuvem e o ambiente nas instalações. Esta secção descreve a estrutura no esquema para redes VPC, espaço de endereços IP, DNS, políticas de firewall e conetividade com o ambiente no local.
Topologia de rede
O repositório de planos detalhados oferece as seguintes opções para a topologia da sua rede:
- Use redes VPC partilhadas separadas para cada ambiente, sem tráfego de rede permitido diretamente entre ambientes.
- Use um modelo de hub e raios que adicione uma rede de hub para ligar cada ambiente no Google Cloud, com o tráfego de rede entre ambientes controlado por um dispositivo virtual de rede (NVA).
Escolha a rede de VPC partilhada para cada topologia de ambiente quando não quiser conetividade de rede direta entre ambientes. Escolha a topologia de rede hub-and-spoke quando quiser permitir a conetividade de rede entre ambientes que é filtrada por uma NVA, como quando confia em ferramentas existentes que requerem um caminho de rede direto para todos os servidores no seu ambiente.
Ambas as topologias usam a VPC partilhada como uma construção de rede principal, porque a VPC partilhada permite uma separação clara de responsabilidades. Os administradores de rede gerem os recursos de rede num projeto anfitrião centralizado e as equipas de carga de trabalho implementam os seus próprios recursos de aplicação e consomem os recursos de rede em projetos de serviço associados ao projeto anfitrião.
Rede VPC partilhada para cada topologia de ambiente
Se precisar de isolamento da rede entre as suas redes de desenvolvimento, não de produção e de produção no Google Cloud, recomendamos a rede VPC partilhada para cada topologia de ambiente. Esta topologia não permite tráfego de rede entre ambientes.
O diagrama seguinte mostra a rede da VPC partilhada para cada topologia de ambiente.
O diagrama descreve os seguintes conceitos-chave da VPC partilhada para cada topologia de ambiente:
- Cada ambiente (produção, não produção e desenvolvimento) tem uma rede de VPC partilhada. Este diagrama mostra apenas o ambiente de produção, mas o mesmo padrão repete-se para cada ambiente.
- Cada rede VPC partilhada tem duas sub-redes, com cada sub-rede numa região diferente.
- A conetividade com recursos no local é ativada através de quatro associações de VLAN à instância do Dedicated Interconnect para cada rede VPC partilhada, usando quatro serviços Cloud Router (dois em cada região para redundância). Para mais informações, consulte o artigo Conetividade híbrida entre o ambiente no local e o Google Cloud.
Por predefinição, esta topologia não permite que o tráfego de rede flua diretamente entre ambientes. Se precisar que o tráfego de rede flua diretamente entre os ambientes, tem de tomar medidas adicionais para permitir este caminho de rede. Por exemplo, pode configurar pontos finais do Private Service Connect para expor um serviço de uma rede VPC a outra rede VPC. Em alternativa, pode configurar a sua rede no local para permitir o fluxo de tráfego de umGoogle Cloud ambiente para o ambiente no local e, em seguida, para outro Google Cloud ambiente.
Topologia de rede hub-and-spoke
Se implementar recursos que Google Cloud requerem um caminho de rede direto para recursos em vários ambientes, recomendamos a topologia de rede hub-and-spoke.
A topologia de hub e raios usa vários dos conceitos que fazem parte da rede VPC partilhada para cada topologia de ambiente, mas modifica a topologia para adicionar uma rede de hub. O diagrama seguinte mostra a topologia de hub e raios.
O diagrama descreve estes conceitos-chave da topologia de rede hub-and-spoke:
- Este modelo adiciona uma rede de hub e cada uma das redes de desenvolvimento, não de produção e de produção (raios) está ligada à rede de hub através do intercâmbio das redes da VPC. Em alternativa, se antecipar que vai exceder o limite de quota, pode usar um gateway de VPN de HA em alternativa.
- A conetividade às redes no local só é permitida através da rede do hub. Todas as redes spoke podem comunicar com recursos partilhados na rede hub e usar este caminho para estabelecer ligação a redes no local.
- As redes do hub incluem uma NVA para cada região, implementada de forma redundante atrás de instâncias do Network Load Balancer interno. Esta NVA serve como gateway para permitir ou negar a comunicação de tráfego entre redes spoke.
- A rede do hub também aloja ferramentas que requerem conetividade a todas as outras redes. Por exemplo, pode implementar ferramentas em instâncias de VM para a gestão da configuração no ambiente comum.
Para ativar o tráfego spoke-to-spoke, o projeto implementa NVAs na rede da VPC partilhada do hub que atuam como gateways entre redes. Os caminhos são trocados das redes VPC de hub para spoke através da troca de caminhos personalizados. Neste cenário, a conetividade entre os raios tem de ser encaminhada através da NVA porque o intercâmbio das redes da VPC não é transitivo e, por isso, as redes da VPC dos raios não podem trocar dados entre si diretamente. Tem de configurar os dispositivos virtuais para permitir seletivamente o tráfego entre os raios.
Padrões de implementação de projetos
Quando criar novos projetos para cargas de trabalho, tem de decidir como os recursos neste projeto se ligam à sua rede existente. A tabela seguinte descreve os padrões de implementação de projetos usados no projeto detalhado.
| Padrão | Descrição | Exemplo de utilização |
|---|---|---|
| Projetos de serviço da VPC partilhada | Estes projetos são configurados como projetos de serviço para um projeto anfitrião de VPC partilhada. Use este padrão quando os recursos no seu projeto tiverem os seguintes critérios:
|
example_shared_vpc_project.tf |
| Projetos flutuantes | Os projetos flutuantes não estão ligados a outras redes VPC na sua topologia. Use este padrão quando os recursos no seu projeto tiverem os seguintes critérios:
Pode ter um cenário em que quer manter a rede VPC de um projeto flutuante separada da topologia da rede VPC principal, mas também quer expor um número limitado de pontos finais entre redes. Neste caso, publique serviços através do Private Service Connect para partilhar o acesso à rede com um ponto final individual nas redes VPC sem expor a rede inteira. |
example_floating_project.tf |
| Projetos de intercâmbio | Os projetos com intercâmbio criam as suas próprias redes VPC e estabelecem intercâmbio com outras redes VPC na sua topologia. Use este padrão quando os recursos no seu projeto tiverem os seguintes critérios:
Se criar projetos de peering, é da sua responsabilidade atribuir intervalos de endereços IP sem conflitos e planear a quota do grupo de peering. |
example_peering_project.tf |
Atribuição de endereços IP
Esta secção apresenta a forma como a arquitetura do esquema atribui intervalos de endereços IP. Pode ter de alterar os intervalos de endereços IP específicos usados com base na disponibilidade de endereços IP no seu ambiente híbrido existente.
A tabela seguinte apresenta uma discriminação do espaço de endereços IP que é atribuído para o projeto. O ambiente de hub aplica-se apenas na topologia de hub e raio.
| Finalidade | Região | Ambiente do centro | Ambiente de programação | Ambiente de não produção | Ambiente de produção |
|---|---|---|---|---|---|
| Intervalos de sub-redes principais | 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 atribuído | 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 privados | Global | 10.16.32.0/21 | 10.16.40.0/21 | 10.16.48.0/21 | 10.16.56.0/21 |
| Pontos finais do Private Service Connect | Global | 10.17.0.5/32 | 10.17.0.6/32 | 10.17.0.7/32 | 10.17.0.8/32 |
| Sub-redes só de proxy | 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 atribuído | 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-redes secundários | 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 atribuído | 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 estes conceitos para a atribuição de intervalos de endereços IP:
- A atribuição de endereços IP é subdividida em intervalos para cada combinação de finalidade, região e ambiente.
- Alguns recursos são globais e não requerem subdivisões para cada região.
- Por predefinição, para recursos regionais, o projeto é implementado em duas regiões. Além disso, existem intervalos de endereços IP não usados para que possa expandir-se para seis regiões adicionais.
- A rede do hub só é usada na topologia de rede hub-and-spoke, enquanto os ambientes de desenvolvimento, não produção e produção são usados em ambas as topologias de rede.
A tabela seguinte apresenta a forma como cada tipo de intervalo de endereços IP é usado.
| Finalidade | Descrição |
|---|---|
| Intervalos de sub-redes principais | Os recursos que implementa na sua rede VPC, como instâncias de máquinas virtuais, usam endereços IP internos destes intervalos. |
| Acesso a serviços privados | Alguns Google Cloud serviços, como o Cloud SQL, exigem que pré-atribua um intervalo de sub-redes para o acesso privado a serviços. O esquema reserva um intervalo /21 globalmente para cada uma das redes de VPC partilhada para atribuir endereços IP a serviços que requerem acesso a serviços privados. Quando cria um serviço que depende do acesso privado a serviços, atribui uma sub-rede /24 regional do intervalo /21 reservado. |
| Private Service Connect | O projeto de base aprovisiona cada rede VPC com um ponto final do Private Service Connect para comunicar com as APIs Google Cloud. Este ponto final permite que os seus recursos na rede VPC alcancem as APIs Google Cloud sem depender do 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 aplicações requerem que pré-atribua sub-redes só de proxy. Embora o esquema não implemente equilibradores de carga de aplicações que exijam este intervalo, a atribuição de intervalos antecipadamente ajuda a reduzir a fricção para as cargas de trabalho quando precisam de pedir um novo intervalo de sub-rede para ativar determinados recursos do equilibrador de carga. |
| Intervalos de sub-redes secundários | Alguns exemplos de utilização, como cargas de trabalho baseadas em contentores, requerem intervalos secundários. Embora o projeto não implemente serviços que exijam intervalos secundários, atribui intervalos do espaço de endereços IP RFC 6598 para intervalos secundários. Em alternativa, se tiver dificuldades em atribuir blocos CIDR suficientemente grandes para estes serviços, pode considerar implementar esses serviços no padrão de projeto flutuante apresentado na secção Padrões de implementação de projetos. |
Configuração de DNS centralizada
Para a resolução de DNS entre ambientes Google Cloud e no local, recomendamos que use uma abordagem híbrida com dois sistemas de DNS autoritários. Nesta abordagem, o Cloud DNS processa a resolução de DNS autoritativa para o seu ambiente e os seus servidores DNS no local existentes processam a resolução de DNS autoritativa para recursos no local.Google Cloud O seu ambiente no local e o ambiente Google Cloud efetuam pesquisas de DNS entre ambientes através de pedidos de encaminhamento.
O diagrama seguinte demonstra a topologia de DNS nas várias redes de VPC usadas no projeto.
O diagrama descreve os seguintes componentes da conceção de DNS implementada pelo projeto:
- O hub de DNS é o ponto central da troca de DNS entre o ambiente no local e o ambiente Google Cloud. O encaminhamento de DNS usa as mesmas instâncias do Dedicated Interconnect e routers da nuvem que já estão configurados na sua topologia de rede.
- Na rede VPC partilhada para cada topologia de ambiente, o projeto de DNS é o mesmo que o projeto anfitrião da VPC partilhada de produção.
- Na topologia de hub e raios, o projeto de hub de DNS é o mesmo que o projeto anfitrião de VPC partilhada do hub.
- Os servidores em cada rede da VPC partilhada podem resolver registos DNS de outras redes da VPC partilhada através do encaminhamento de DNS, que é configurado entre o Cloud DNS em cada projeto anfitrião da VPC partilhada e o hub de DNS.
- Os servidores no local podem resolver registos DNS em Google Cloud ambientes através de políticas do servidor DNS que permitem consultas de servidores no local. O esquema configura uma política de servidor de entrada no hub de DNS para atribuir endereços IP, e os servidores DNS no local encaminham pedidos para estes endereços. Todos os pedidos de DNS chegam primeiro ao hub de DNS, que resolve registos de pares de DNS. Google Cloud
- Os servidores no Google Cloud podem resolver registos de DNS no ambiente no local através de zonas de encaminhamento que consultam servidores no local. Todos os pedidos DNS para o ambiente no local têm origem no hub DNS. A origem do pedido DNS é 35.199.192.0/19.
Políticas de firewall
Google Cloud tem vários tipos de políticas de firewall. As políticas de firewall hierárquicas são aplicadas ao 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, pode configurar políticas de firewall de rede para cada rede de VPC. O esquema combina estas políticas de firewall para aplicar configurações comuns em todos os ambientes através de políticas de firewall hierárquicas e para aplicar configurações mais específicas em cada rede VPC individual através de políticas de firewall de rede.
O projeto não usa regras de firewall da VPC antigas. Recomendamos que use apenas políticas de firewall e evite a utilização combinada com regras de firewall da VPC antigas.
Políticas de firewall hierárquicas
O projeto define uma única política de firewall hierárquica e anexa a política a cada uma das pastas de produção, não produção, desenvolvimento, arranque e comuns. Esta política de firewall hierárquica contém as regras que devem ser aplicadas de forma abrangente em todos os ambientes e delega a avaliação de regras mais detalhadas na política de firewall de rede para cada ambiente individual.
A tabela seguinte descreve as regras da política de firewall hierárquica implementadas pelo projeto.
| Descrição da regra | Direção do trânsito | Filtro (intervalo de IPv4) | Protocolos e portas | Ação |
|---|---|---|---|---|
| Delegue a avaliação do tráfego de entrada da RFC 1918 em níveis inferiores na hierarquia. | Ingress |
192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 |
all |
Go to next |
| Delegue a avaliação do tráfego de saída na 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 |
| CNA para encaminhamento TCP | Ingress |
35.235.240.0/20 |
tcp:22,3389 |
Allow |
| Ativação do Windows Server | Egress |
35.190.247.13/32 |
tcp:1688 |
Allow |
| Verificações de funcionamento para o 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
A planta 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 a serviços e negam a saída para todos os outros endereços IP. Google Cloud
No modelo de hub e raios, as políticas de firewall de rede contêm regras adicionais para permitir a comunicação entre raios. A política de firewall de rede permite o tráfego de saída de um spoke para o hub ou outro spoke, e permite o tráfego de entrada da NVA na rede do hub.
A tabela seguinte descreve as regras na política de firewall de rede global implementada para cada rede VPC no projeto.
| Descrição da regra | Direção do trânsito | Filtro | Protocolos e portas |
|---|---|---|---|
| Permita o tráfego de saída para as APIs Google Cloud. | Egress |
O ponto final do Private Service Connect que está configurado para cada rede individual. Consulte o artigo Acesso privado às APIs 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 (apenas para o modelo de hub-and-spoke). | Egress | O agregado de todos os endereços IP usados na topologia de hub e raio. O tráfego que sai de uma VPC spoke é encaminhado primeiro para a NVA na rede hub. | all |
Permitir tráfego de entrada para um spoke a partir da NVA na rede do hub (apenas para o modelo hub-and-spoke). |
Ingress |
Tráfego proveniente das NVAs na rede do hub. | all |
Quando implementa o projeto, uma instância de VM numa rede VPC pode comunicar com os serviços, mas não com outros recursos de infraestrutura na mesma rede VPC. Google Cloud Para permitir que as instâncias de VM comuniquem, tem de adicionar regras adicionais à política de firewall de rede e etiquetas que permitam explicitamente que as instâncias de VM comuniquem. As etiquetas são adicionadas a instâncias de VMs e o tráfego é avaliado em função dessas etiquetas. Além disso, as etiquetas têm controlos de IAM para que possa defini-las centralmente e delegar a respetiva utilização a outras equipas.
O diagrama seguinte mostra um exemplo de como pode adicionar etiquetas personalizadas e regras da política de firewall de rede para permitir que as cargas de trabalho comuniquem no interior 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 a 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 etiqueta
service=frontendpara instâncias com a etiquetaservice=backendna prioridade 999. - A VM instance-2 pode receber tráfego da instance-1 porque o tráfego corresponde às etiquetas permitidas pela Regra 2. A Regra 2 é correspondida antes de a Regra 1 ser avaliada, 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 este tráfego é a Regra 1, pelo que o tráfego de saída da instância 1 é recusado.
Acesso privado às Google Cloud APIs
Para permitir que os recursos nas suas redes VPC ou no ambiente no local alcancem os Google Cloud serviços, recomendamos a conectividade privada em vez do tráfego de Internet de saída para pontos finais de API públicos. A planta configura o acesso privado à Google em todas as sub-redes, cria pontos finais internos com o Private Service Connect para comunicar com os Google Cloud serviços e configura as políticas de firewall e os registos DNS para permitir o tráfego para esses pontos finais. Usados em conjunto, estes controlos permitem um caminho privado para os serviços, sem depender do tráfego de saída da Internet nem de intervalos de Internet anunciados publicamente. Google Cloud
A planta configura pontos finais do Private Service Connect com o
pacote de APIs
denominado vpc-sc, que permite o acesso aos Google Cloud serviços
suportados pelo
VIP restrito. Este controlo ajuda a mitigar o risco de exfiltração, impedindo o acesso a outras APIs Google não relacionadas com o Google Cloud. Este controlo também é um passo pré-requisito para ativar os
VPC Service Controls. Para mais informações sobre os passos opcionais para ativar o VPC Service Controls, consulte o artigo Proteja os seus recursos com o VPC Service Controls.
A tabela seguinte descreve os pontos finais do Private Service Connect criados para cada rede.
| Ambiente | Pacote de APIs | Endereço IP do ponto final do Private Service Connect | ||
|---|---|---|---|---|
| Comum | vpc-sc |
10.17.0.5/32 | ||
| Programação | vpc-sc |
10.17.0.6/32 | ||
| Não produção | vpc-sc |
10.17.0.7/32 | ||
| Produção | vpc-sc |
10.17.0.8/32 | ||
Para garantir que o tráfego para os Google Cloud serviços tem uma pesquisa de DNS para o ponto final correto, a configuração do esquema configura zonas de DNS privadas para cada rede VPC. A tabela seguinte descreve estas zonas de DNS privadas.
| Nome da zona privada | Nome de DNS | Tipo de registo | Dados |
|---|---|---|---|
googleapis.com. |
*.googleapis.com. |
CNAME |
restricted.googleapis.com. |
restricted.googleapis.com |
A |
O endereço IP do ponto final do Private Service Connect para essa rede VPC. | |
gcr.io. |
*.gcr.io |
CNAME |
gcr.io. |
gcr.io |
A |
O endereço IP do ponto final do Private Service Connect para essa rede VPC. | |
pkg.dev. |
*.pkg.dev. |
CNAME |
pkg.dev. |
pkg.dev. |
A |
O endereço IP do ponto final do Private Service Connect para essa rede VPC. |
O projeto base tem configurações adicionais para garantir que estes pontos finais do Private Service Connect são usados de forma consistente. Cada rede de VPC partilhada também aplica o seguinte:
- Uma regra de política de firewall de rede que permite o tráfego de saída de todas as origens para o endereço IP do ponto final do Private Service Connect em TCP:443.
- Uma regra de 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 predefinidos que são usados para acesso aos serviços Google Cloud .
Ligação à Internet
O projeto não permite tráfego de entrada nem de saída entre as respetivas redes da VPC e a Internet. Para cargas de trabalho que requerem ligação à Internet, tem de tomar medidas adicionais para conceber os caminhos de acesso necessários.
Para cargas de trabalho que requerem tráfego de saída para a Internet, recomendamos que faça a gestão do tráfego de saída através do Cloud NAT para permitir o tráfego de saída sem ligações de entrada não solicitadas ou através do proxy Web seguro para um controlo mais detalhado que permita o tráfego de saída apenas para serviços Web fidedignos.
Para cargas de trabalho que requerem tráfego de entrada da Internet, recomendamos que conceba a sua carga de trabalho com Cloud Load Balancing e Google Cloud Armor para beneficiar das proteções contra DDoS e WAF.
Não recomendamos que crie cargas de trabalho que permitam a conetividade direta entre a Internet e uma VM através de um endereço IP externo na VM.
Conetividade híbrida entre um ambiente no local e Google Cloud
Para estabelecer a conetividade entre o ambiente no local e o Google Cloud, recomendamos que use o Dedicated Interconnect para maximizar a segurança e a fiabilidade.Google CloudUma ligação Dedicated Interconnect é um link direto entre a sua rede no local e a Google Cloud.
O diagrama seguinte apresenta a conetividade híbrida entre o ambiente nas instalações e uma rede da nuvem virtual privada da Google.
O diagrama descreve os seguintes componentes do padrão para a disponibilidade de 99,99% para o Dedicated Interconnect:
- Quatro ligações Dedicated Interconnect, com duas ligações numa área metropolitana (metro) e duas ligações noutra área metropolitana. Em cada área metropolitana, existem duas zonas distintas no edifício de alojamento conjunto.
- As ligações estão divididas em dois pares, com cada par ligado a um centro de dados no local separado.
- Os anexos de VLAN são usados para associar cada instância do Dedicated Interconnect aos Cloud Routers que estão anexados à topologia da VPC partilhada.
- Cada rede da VPC partilhada tem quatro Cloud Routers, dois em cada região, com o modo de encaminhamento dinâmico definido como
globalpara que cada Cloud Router possa anunciar todas as sub-redes, independentemente da região.
Com o encaminhamento dinâmico global, o Cloud Router anuncia trajetos a todas as sub-redes na rede VPC. O Cloud Router anuncia encaminhamentos para sub-redes remotas (sub-redes fora da região do Cloud Router) com uma prioridade inferior em comparação com as sub-redes locais (sub-redes que se encontram na região do Cloud Router). Opcionalmente, pode alterar os prefixos anunciados e as prioridades quando configura a sessão BGP para um Cloud Router.
O tráfego de Google Cloud para um ambiente no local usa o Cloud Router mais próximo dos recursos da nuvem. Numa única região, existem várias rotas para redes no local com o mesmo valor do discriminador de várias saídas (MED) e Google Cloud usam o encaminhamento de vários caminhos de custo igual (ECMP) para distribuir o tráfego de saída entre todas as rotas possíveis.
Alterações de configuração no local
Para configurar a conetividade entre o ambiente no local e o Google Cloud, tem de configurar alterações adicionais no seu ambiente no local. O código do Terraform no projeto configura automaticamente os Google Cloud recursos, mas não modifica nenhum dos seus recursos de rede no local.
Alguns dos componentes da conetividade híbrida do seu ambiente no local para Google Cloud são ativados automaticamente pela planta, incluindo o seguinte:
- O Cloud DNS está configurado com o encaminhamento de DNS entre todas as redes da VPC partilhada para um único hub, conforme descrito na configuração de DNS. Uma política de servidor DNS da Cloud está 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 pontos finais do Private Service Connect.
Para ativar a conetividade híbrida, tem de executar os seguintes passos adicionais:
- Encomende uma ligação de interligação dedicada.
- Configure os routers e as firewalls no local para permitir o tráfego de saída para o espaço de endereços IP interno definido na atribuição de espaço de endereços IP.
- Configure os seus servidores DNS no local para encaminhar as pesquisas de DNS destinadas a Google Cloud para os endereços IP do encaminhador de entrada que já estão configurados pela planta.
- Configure os seus servidores DNS, firewalls e routers no local para aceitarem consultas DNS da zona de encaminhamento (35.199.192.0/19) do Cloud DNS.
- Configure servidores DNS no local para responder a consultas de anfitriões no local para serviços com os endereços IP definidos no acesso privado às APIs Google Cloud. Google Cloud
- Para a encriptação em trânsito através da ligação Dedicated Interconnect, configure o MACsec para o Cloud Interconnect ou configure a VPN de alta disponibilidade através do Cloud Interconnect para a encriptação IPsec.
Para mais informações, consulte o artigo Acesso privado Google para anfitriões no local.
O que se segue?
- Leia acerca dos controlos detetives (documento seguinte nesta série).