Vários projetos Google Cloud, uma VPN híbrida? Decida primeiro
A VPC partilhada, o peering e um hub de conetividade respondem a perguntas de propriedade diferentes. Escolha a fronteira da rede antes de implementar uma VPN por projeto.
Quando vários projetos Google Cloud precisam de acesso híbrido, o instinto é uma VPN por projeto, e é quase sempre a forma errada. A propriedade do projeto e o encaminhamento de pacotes são questões relacionadas mas distintas, e a arquitetura útil mantém as fronteiras administrativas de que precisa ao mesmo tempo que dá aos prefixos previstos um único caminho deliberado para o escritório ou o centro de dados. Estas verificações decidem que modelo de rede realmente quer, na ordem que evita retrabalho. Cada uma pode terminar a discussão cedo, e é esse o objetivo.
Uma fronteira de projeto não exige automaticamente o seu próprio túnel.
Verifique se o objeto partilhado é a rede
Comece por uma pergunta sobre propriedade, não sobre conetividade: a propriedade central da rede pode suportar estas cargas de trabalho? Se a resposta for sim e a organização tiver uma configuração elegível, um projeto anfitrião possui a VPC, as sub-redes e a conetividade, enquanto os projetos de serviço possuem os seus próprios recursos de aplicação. Uma ligação Cloud VPN nessa rede partilhada pode então servir os prefixos de carga de trabalho previstos, sujeita às políticas de encaminhamento e segurança .
Seja preciso quanto ao que a associação faz. Anexar um projeto de serviço não funde a sua VPC independente existente na rede anfitriã, nem move automaticamente cada recurso. A anexação de cargas de trabalho, as permissões, o espaço de endereços e o DNS fazem parte da arquitetura, não são consequências da definição. Leia a associação primeiro como uma alteração de permissões e depois como uma alteração de encaminhamento, porque as equipas descobrem normalmente a diferença durante a migração.
Se a propriedade central não for aceitável para as equipas envolvidas, pare aqui e trate o resto como um desenho de peering ou de hub. Forçar Shared VPC sobre um grupo que precisa de ciclos de vida de rede independentes produz um problema político com um nome técnico.
Verifique se VPC independentes podem continuar independentes
O peering preserva VPC separadas, e é exatamente por isso que atrai equipas que querem os seus próprios planos de endereços e o seu próprio controlo de alterações. A armadilha é que o peering não é transitivo: o peering A-com-B e B-com-C não cria por si só encaminhamento A-com-C através de B. Se três projetos têm de alcançar um destino híbrido, precisa de um plano de troca deliberado e não de uma cadeia de peerings.
Partilhar a alcançabilidade híbrida também depende da troca documentada de rotas personalizadas e dos anúncios Cloud Router previstos. Um estado de peering ativo prova que o peering existe, não que os prefixos que importam a cada lado tenham alguma vez sido exportados. Verifique os intervalos exportados em ambos os lados do par, na configuração que efetua a exportação, e compare-os com os endereços que as suas cargas de trabalho realmente utilizam. Uma discrepância aí é a razão mais comum para que um peering pareça saudável enquanto um prefixo continua inalcançável.
Escreva o plano de endereços antes de tudo o resto. Os intervalos que não se sobrepõem, as rotas para cada destino previsto e os anúncios de retorno são os três artefactos de que este modelo vive ou morre.
Verifique se um modelo de hub se adequa à topologia
Para um desenho maior ou segmentado de forma diferente, a descrição geral da Google Network Connectivity Center descreve os modelos de hub e de raio. Leia-a pelo que a versão atual suporta e não pelo que o diagrama implica: que combinações de VPC e híbridas, que famílias de rotas e que políticas cada tipo de raio permite.
Verifique a família de endereços de forma explícita. Os exemplos de planeamento na maioria dos guias, incluindo este, dizem respeito a IPv4, e uma funcionalidade que existe para um tipo de raio não se aplica automaticamente sem alterações a outro. Se o seu ambiente for de pilha dupla, essa pergunta pertence à escolha do modelo, não a uma migração posterior.
A tabela abaixo é o resumo dos três modelos e a pergunta que decide cada um.
| Model | Network relationship | Planning question |
|---|---|---|
| Shared VPC | Service projects use subnets of a host project's VPC | Can central network ownership support these workloads? |
| VPC Network Peering | Independent VPCs exchange supported routes through explicit peers | Are direct peer and hybrid route exchanges sufficient? |
| Network Connectivity Center | Supported VPC and hybrid spokes join a managed hub | Does the required topology fit current routing and policy? |
Verifique o que o encaminhamento não concede
A troca de rotas não é uma concessão global de confiança. A resolução de DNS, a permissão da firewall e a autorização de aplicações continuam a ser responsabilidades próprias, e cada uma é configurada por um proprietário diferente na maioria das organizações. Um desenho que assume que a alcançabilidade implica autorização passará o seu teste de conetividade e falhará a sua revisão de segurança.
Confirme também a história de DNS para cada modelo, porque as disposições de zona e de reencaminhamento diferem entre uma rede partilhada e redes com peering. Os nomes privados que se resolvem num projeto não seguem uma rota para outro.
Registe a decisão e o seu proprietário
Centralize onde a organização quer um proprietário de rede partilhada; mantenha VPC separadas onde o ciclo de vida ou a política o exigirem. Depois escolha uma relação de conetividade suportada e registe qual escolheu, quem possui a rede partilhada e o que cada projeto pode anunciar.
Contar projetos e comprar uma VPN para cada um não substitui essa decisão de propriedade. É a mesma decisão, tomada mais tarde, por quem herda a fatura e a tabela de encaminhamento.