Este documento é destinado a administradores de rede, arquitetos de soluções e profissionais de operações que executam appliances de rede centralizados no Google Cloud. É necessário ter conhecimento de Compute Engine e redes de nuvem privada virtual (VPC) no Google Cloud.
Os ambientes corporativos geralmente precisam rotear o tráfego para a Internet, para uma rede local, para outras nuvens ou até para outras partes do mesmo ambiente de nuvem por meio de appliances virtualizados com base em VM que monitoram, transformam ou bloqueiam o tráfego.
Este documento analisa várias opções de design que segmentam redes VPC e as interconectam com um appliance de rede centralizado e virtualizado. Toda a comunicação entre redes VPC, redes locais e a Internet é roteada por meio do dispositivo centralizado. É possível implantar um grupo de appliances redundantes para ter uma configuração de alta disponibilidade. Se você não precisar de alta disponibilidade, poderá implantar um único appliance de rede.
O roteamento do tráfego por meio de appliances virtualizados pode ser um desafio. No Google Cloud, por exemplo, é possível substituir a rota que aponta para a Internet e redirecionar o tráfego para um conjunto de appliances virtualizados, mas não é possível alterar o comportamento de roteamento entre sub-redes em uma rede VPC. O roteamento entre sub-redes é automático e não é possível excluir ou substituir essas rotas.
Além disso, devido ao papel fundamental dos appliances virtualizados, eles precisam ser implantados em configurações altamente disponíveis. Isso é um desafio porque você precisa garantir que todo o tráfego seja roteado por um dos appliances virtuais e que o failover entre esses appliances seja automático.
Arquitetura
O diagrama a seguir mostra um caso de uso típico de várias opções de design que apresentam um appliance de rede centralizado e virtualizado.
O diagrama anterior mostra os caminhos de comunicação entre redes VPC segmentadas, redes locais e a Internet e como elas são roteadas por meio do appliance de rede virtualizado e centralizado.
Principais casos de uso para essa arquitetura
É possível usar essa arquitetura para vários casos de uso que envolvem appliances de rede virtualizados que o tráfego recebe. Lembre-se das seguintes considerações:
- Muitos appliances de diferentes fornecedores podem ser encontrados no Google Cloud Marketplace.
- Alguns fornecedores de appliances também oferecem imagens personalizadas do Compute Engine para o Google Cloud no site ou nas páginas de suporte.
- Crie seus próprios appliances virtualizados usando um software de rede de código aberto. Também é possível criar suas próprias imagens.
Os fornecedores normalmente geram suas próprias arquiteturas de referência ou guias de implantação para executar os appliances virtualizados em uma configuração de alta disponibilidade. Para mais informações, consulte o site do fornecedor.
As arquiteturas de referência do fornecedor podem não abranger todas as opções apresentadas neste documento.
É importante entender as vantagens e desvantagens de cada abordagem. Os casos de uso típicos dos appliances virtuais em que o tráfego é encaminhado incluem:
- Firewalls de última geração (NGFWs, na sigla em inglês) Um conjunto centralizado de firewalls é executado como máquinas virtuais que fornecem recursos que não estão disponíveis se você usa regras de firewall VPC. Esse é o caso de uso mais comum. Os recursos típicos dos produtos NGFW incluem inspeção profunda de pacotes (DPI, na sigla em inglês) e firewall na camada do aplicativo. Alguns firewalls NGFW também fornecem inspeção de tráfego TLS/SSL, além de outras funções de rede descritas nos casos de uso nos itens a seguir.
- Sistema de detecção de intrusões/sistema de prevenção de intrusões (IDS/IPS, nas siglas em inglês). Um IDS baseado em rede requer a visibilidade de todo o tráfego potencialmente malicioso. Para evitar intrusões, o tráfego geralmente é bloqueado diretamente por um IPS no caminho de tráfego.
- Proxy transparente. Um proxy transparente geralmente é usado para monitorar o tráfego HTTP(S) e aplicar restrições ao acesso à Web.
- Gateway de conversão de endereços de rede (NAT, na sigla em inglês). Um gateway NAT traduz endereços IP e portas. Isso ajuda, por exemplo, a evitar a sobreposição de endereços IP. O Google Cloud oferece o Cloud NAT como um serviço gerenciado, mas esse serviço está disponível apenas para o tráfego que vai para a Internet, não para o tráfego local ou para outras redes VPC no Google Cloud.
- Web Application Firewall (WAF). Um WAF bloqueia o tráfego HTTP malicioso que vai para um aplicativo da Web. O Google Cloud oferece a funcionalidade WAF por meio das políticas de segurança do Google Cloud Armor. A funcionalidade exata difere dos fornecedores de WAF, por isso, é importante determinar exatamente o que você precisa.
Requisitos típicos
Os requisitos para rotear o tráfego por meio de appliances virtuais centralizados diferem com base no caso de uso específico. No entanto, os seguintes requisitos geralmente se aplicam:
- Todo o tráfego entre diferentes segmentos de rede. Por exemplo, ambientes administrados por equipes diferentes, com requisitos de segurança separados ou entre módulos diferentes de um aplicativo, precisam passar por um appliance virtual centralizado.
- Todo o tráfego de ou para a Internet para ambientes seguros precisa passar por um appliance virtual centralizado.
- Todo o tráfego de ou para sistemas locais conectados ao Google Cloud por meio do Cloud VPN, da Interconexão dedicada ou da Interconexão por parceiro precisa passar por um appliance virtual centralizado.
- Vários appliances virtuais centralizados são configurados em uma configuração de alta disponibilidade em uma configuração ativa/ativa ou ativa/passiva. O failover ocorre automaticamente se houver problemas de software ou hardware em um dos appliances virtualizados.
- Todo o tráfego é encaminhado com estado, para que um fluxo de tráfego entre duas máquinas virtuais esteja sempre passando pelo mesmo appliance virtual.
- A capacidade do sistema de appliances virtuais centralizados é escalonável por uma das duas opções a seguir:
- Como escalonar os appliances virtuais verticalmente: aumentar o número de núcleos ou a quantidade de memória em cada máquina virtual.
- Escalonamento horizontal dos appliances virtuais: o aumento do número de appliances virtuais usados para distribuir o tráfego
Opções de arquitetura
Há várias opções para alcançar alta disponibilidade entre appliances virtuais. Há também várias opções para anexar segmentos de rede aos appliances virtuais.
É possível combinar qualquer opção para alta disponibilidade com qualquer opção para anexar segmentos de rede. Uma opção comum descrita posteriormente neste documento é uma arquitetura que usa o peering de rede VPC e o balanceador de carga de rede de passagem interno como o próximo salto.
Como escolher uma opção de alta disponibilidade
É possível criar uma arquitetura para alcançar alta disponibilidade para o appliance central usando várias instâncias das seguintes maneiras:
Usar um balanceador de carga de rede de passagem interna como o próximo salto. Nessa abordagem, você coloca vários appliances virtuais em um grupo de instâncias gerenciadas por trás de um balanceador de carga de rede de passagem interno. Esse balanceador de carga é usado como o próximo salto para uma rota padrão que substitui a rota padrão nas redes VPC conectadas aos appliances. Utilize appliances em uma configuração ativa/ativa, que é a configuração padrão, ou em uma configuração ativa/passiva, empregando failover para balanceamento de carga de rede de passagem interno. As verificações de integridade direcionam o tráfego para instâncias íntegras. Se você quiser recriar appliances automaticamente em caso de falha, use a recuperação automática. Se o dispositivo usar várias interfaces de rede, um balanceador de carga de rede de passagem interno como próximo salto poderá ter back-ends em qualquer interface de rede.
O diagrama a seguir mostra a topologia de uso de um balanceador de carga de rede de passagem interna como o próximo salto.
O diagrama anterior mostra um grupo de instâncias gerenciadas em uma rede VPC, incluindo vários appliances virtuais por trás de um balanceador de carga de rede de passagem interno, que atua como o próximo salto.
Use o roteamento. Nessa abordagem, as rotas do Google Cloud direcionam o tráfego para os appliances virtuais das redes VPC conectadas. É possível usar appliances em uma configuração ativa/passiva usando rotas de prioridade diferentes ou em uma configuração ativa/ativa quando as rotas são definidas com a mesma prioridade. Nesse caso, você usa roteamento de caminhos múltiplos de custo igual (ECMP, na sigla em inglês) para distribuir o tráfego. É possível usar a recuperação automática para ajudar a garantir que os appliances sejam reiniciados quando não estiverem íntegros.
O diagrama a seguir mostra a topologia do uso do roteamento.
O diagrama anterior mostra um grupo de instâncias gerenciadas em uma rede VPC com rotas do Google Cloud que direcionam o tráfego para os appliances virtuais da rede VPC conectada.
O uso de um balanceador de carga de rede de passagem interno como próximo salto tem as seguintes vantagens em relação ao roteamento do Google Cloud para alta disponibilidade:
- As verificações de integridade decidem para onde o tráfego é encaminhado, ajudando a garantir que o tráfego seja encaminhado apenas para instâncias íntegras. É possível expor verificações de integridade para que a instância local ou um caminho completo sejam verificados.
- É possível ajustar os timers de verificação de integridade para um failover mais rápido. Essa abordagem apresenta os tempos de failover mais rápidos no caso de instâncias não íntegras.
- Com o hash simétrico, é possível garantir que o tráfego de retorno seja roteado para a mesma máquina virtual que o tráfego de saída.
O uso do roteamento do Google Cloud tem as seguintes vantagens:
- O hash simétrico consistente garante que os pacotes de uma determinada conexão sejam processados pela mesma VM de back-end, para solicitações e respostas, dependendo do protocolo e da seleção de afinidade da sessão. A seleção de afinidade do protocolo e da sessão determina se o rastreamento de conexão é usado ou não. Observe que alguns casos de uso podem se beneficiar de uma configuração NAT de origem (SNAT) nas instâncias de back-end; por exemplo, se uma conexão de resposta de uma rede para outra precisa corresponder a uma conexão de solicitação separada na mesma direção entre as mesmas duas redes.
O uso do roteamento do Google Cloud tem as seguintes desvantagens:
- As verificações de integridade excluem e recriam instâncias não íntegras do pool de instâncias. No entanto, o fluxo de tráfego não é alterado imediatamente em resposta a verificações de integridade com falha, porque leva algum tempo para excluir instâncias não íntegras e criar instâncias novas e íntegras. Isso leva a tempos de failover mais lentos.
- Se você definir timers de verificação de integridade para evitar a exclusão e a recriação desnecessárias de instâncias, isso causará tempos de failover mais lentos.
Se você usar um balanceador de carga de rede de passagem interna como o próximo salto ou o roteamento do Google Cloud, todo o tráfego de protocolo será compatível. Para informações detalhadas sobre essa compatibilidade, consulte Processamento de TCP, UDP e outros tráfegos de protocolo.
Da mesma forma, as duas soluções são compatíveis com a limitação de rotas a determinadas tags de rede. Por exemplo, as instâncias de VM podem ser segmentadas por região para usar diferentes conjuntos de appliances.
Como escolher uma opção para anexar segmentos de rede
Como o roteamento entre sub-redes não pode ser substituído, os segmentos de rede são implementados usando redes VPC separadas. O tráfego entre essas redes VPC, para um ambiente local e para a Internet, precisa ser roteado por meio dos appliances centralizados. Todos esses segmentos de rede podem ser redes VPC independentes ou redes VPC compartilhadas.
Há várias opções para anexar segmentos de rede, da seguinte maneira:
Várias interfaces de rede. A maneira mais simples de conectar várias redes VPC por meio de um appliance virtual é usando várias interfaces de rede, com cada interface conectando-se a uma das redes VPC. A conectividade com a Internet e no local é fornecida em uma ou duas interfaces de rede separadas. Com muitos produtos NGFW, a conectividade com a Internet é feita por meio de uma interface marcada como não confiável no software NGFW.
O diagrama a seguir mostra essa topologia.
O diagrama anterior mostra várias redes VPC conectadas por meio de um appliance virtual usando várias interfaces de rede. Cada interface se conecta a uma das redes VPC. O diagrama também mostra conexões de Internet e locais em interfaces de rede separadas, inclusive uma conexão com a Internet por meio de uma interface não confiável.
Peering de rede VPC. Essa topologia usa o conceito "hub and spoke" em conjunto com o peering de rede VPC. Os segmentos de rede são implementados como um conjunto de redes VPC spoke que usam o peering de rede VPC com uma rede VPC hub, em que o tráfego é roteado por meio do pool centralizado de appliances virtualizados. A rota padrão ou as rotas que apontam para o balanceador de carga de rede de passagem interno como próximo salto ou para os appliances virtuais são exportadas como rotas personalizadas pelo peering de rede VPC. A conectividade com a Internet e no local é fornecida em uma ou duas interfaces de rede separadas.
O diagrama a seguir mostra essa topologia.
O diagrama anterior mostra um pool centralizado de appliances virtualizados com várias interfaces de rede anexadas a várias redes VPC hub. Cada rede VPC hub é anexada a várias redes VPC por meio do peering de rede VPC. O tráfego entre duas redes VPC é roteado por meio do pool centralizado de appliances virtualizados.
Combinação de várias interfaces de rede e peering de rede VPC. Essa abordagem combina as duas opções anteriores para escalonabilidade adicional. Várias interfaces de rede são anexadas a várias redes VPC hub, cada uma conectada a várias redes VPC spoke por meio do peering de rede VPC. Para cada rede VPC "hub-and-spoke", use a mesma abordagem descrita no caso de peering de rede VPC.
O diagrama a seguir mostra essa topologia.
O diagrama anterior mostra uma rede VPC hub anexada a várias redes VPC por meio do peering de rede VPC. O tráfego é roteado por meio do pool centralizado de appliances virtualizados com uma interface de rede na rede hub.
A árvore de decisão a seguir pode ajudar a escolher a melhor abordagem para anexar segmentos de rede.
O uso de várias interfaces de rede, a primeira abordagem apresentada nos casos anteriores, é a mais fácil de implementar.
No entanto, o uso de várias interfaces de rede tem as seguintes desvantagens:
- O uso está limitado a oito interfaces de rede por instância de máquina virtual. Se você usa uma interface de rede para conectividade com a Internet e outra para conectividade local, é possível conectar apenas seis segmentos de rede no Google Cloud. Alguns appliances exigem uma interface de gerenciamento adicional, limitando você a cinco segmentos de rede.
- Não é possível adicionar ou remover interfaces de rede depois que uma instância é criada.
O uso do peering de rede VPC tem as seguintes vantagens:
- É possível escalonar até o limite de conexões de peering de rede VPC de uma única rede VPC. Entre em contato com a equipe de vendas do Google Cloud se tiver dúvidas sobre como aumentar esse limite.
- É fácil adicionar ou remover redes VPC dessa arquitetura configurando o peering de rede VPC.
No entanto, o uso do peering de rede VPC tem as seguintes desvantagens:
- Essa abordagem é um pouco mais complexa do que a que usa várias interfaces de rede.
- O número de VPCs que podem ser conectadas ainda é limitado em comparação com a abordagem combinada.
O uso da abordagem combinada (várias interfaces de rede e peering de rede VPC) tem a seguinte vantagem:
- É a abordagem mais escalonável porque o limite é um produto do limite de interfaces de rede e do limite de conexões de peering de VPC. Por exemplo, é possível conectar seis redes VPC hub a interfaces de rede separadas, e cada interface tem 25 redes VPC spoke. Isso dá a você um limite de 150 redes VPC que trocam tráfego por meio de um conjunto de appliances virtuais.
No entanto, essa abordagem tem a seguinte desvantagem:
- Essa é a abordagem mais complexa de implementação.
Exemplos de arquiteturas
Veja a seguir duas arquiteturas de exemplo. O primeiro exemplo de arquitetura demonstra como usar o balanceador de carga de rede de passagem interno para alta disponibilidade, combinado com o peering de rede VPC para anexar segmentos de rede. O segundo exemplo de arquitetura, um caso de uso especial, mostra como rotear o tráfego de uma única rede VPC compartilhada no Google Cloud para um ambiente local e para a Internet.
Exemplo de arquitetura que usa o peering de rede VPC e o balanceador de carga de rede de passagem interna como próximo salto
Essa arquitetura é um caso de uso típico de ambientes empresariais, usando o balanceador de carga de rede de passagem interno para alta disponibilidade, combinado ao peering de rede VPC para anexar segmentos de rede.
O diagrama a seguir mostra a topologia dessa arquitetura,
O diagrama anterior mostra uma rede VPC hub e várias redes VPC spoke que têm peering com a rede VPC hub usando peering de rede VPC. A rede VPC hub tem duas instâncias de um appliance virtual em um grupo de instâncias gerenciadas atrás de um balanceador de carga de rede de passagem interno. Uma rota padrão estática aponta para o balanceador de carga de rede de passagem interna como o próximo salto. Essa rota padrão estática é exportada pelo peering de rede VPC usando rotas personalizadas. A rota padrão para o gateway da Internet nas redes VPC spoke é excluída.
É possível atender aos requisitos das seguintes maneiras:
- A conectividade entre spokes é encaminhada automaticamente pelo firewall porque o peering de rede VPC não é transitivo e, portanto, as redes VPC spoke não podem trocar dados entre si. É possível configurar os appliances virtuais para definir as condições e políticas em que os spokes podem trocar tráfego.
- A conectividade com a Internet só é possível por meio de appliances virtuais, porque a rota padrão para o gateway da Internet foi removida das redes VPC spoke. Os appliances virtuais têm uma rota padrão por meio de uma interface de rede separada, que pode ser marcada como não confiável no caso de um NGFW.
- A conectividade com redes locais é alcançada por meio de uma rede VPC conectada ao appliance virtual em uma interface de rede separada. Uma conexão do Cloud VPN ou do Cloud Interconnect termina nessa rede VPC de conectividade.
- A alta disponibilidade é alcançada por meio de verificações de integridade personalizadas no balanceador de carga interno. É possível configurar os dispositivos como ativos/passivos usando o failover de balanceadores de carga de rede de passagem interna. Isso ajuda a garantir que o tráfego sempre flua por meio de um único appliance virtual.
Use esta arquitetura de exemplo se a comunicação entre as diferentes redes VPC for TCP/UDP ou outro tráfego de protocolo. É escalonável até o limite de conexões de peering de rede VPC por rede VPC.
Consulte um exemplo de implementação dessa arquitetura com um gateway NAT como o dispositivo virtual em Implantar uma rede hub-and-spoke usando um balanceador de carga como próximo salto. É possível usar o mesmo padrão para implantar outros appliances virtuais, conforme descrito na seção casos de uso anterior.
Caso de uso especial com uma rede VPC compartilhada no Google Cloud
Em um uso especial, nenhum tráfego entre diferentes redes VPC precisa passar pelos appliances virtuais. Em vez disso, apenas o tráfego de uma única rede VPC compartilhada é roteado para um ambiente local e para a Internet. É possível implementar esse caso de uso usando qualquer uma das opções de alta disponibilidade descritas anteriormente neste documento, combinadas com uma interface de rede cada, para conectividade com a rede VPC compartilhada, no local e no Google Cloud. Se você quiser visibilidade do tráfego entre sub-redes sem executá-lo por meio de appliances centralizados, o espelhamento de pacotes pode ajudar.
O diagrama a seguir mostra essa topologia.
O diagrama anterior mostra o tráfego de uma única rede VPC compartilhada roteada para uma rede local e para a Internet por meio de um pool de appliances virtuais.
Implementação de uma arquitetura com appliances virtuais
Consulte informações sobre como usar o peering de rede VPC entre segmentos e um balanceador de carga de rede de passagem interno como uma opção de alta disponibilidade em Implantar uma rede hub-and-spoke usando um balanceador de carga como próximo salto.
Se você quiser implantar um appliance de um parceiro do Google Cloud, por exemplo, do Cloud Marketplace, entre em contato com o fornecedor do appliance ou pesquise as diretrizes do site sobre como implantar os appliances no Google Cloud.
A seguir
- Práticas recomendadas e arquiteturas de referência para o design da VPC.
- Topologias de rede híbrida e de várias nuvens.
- Práticas recomendadas para o design de redes no framework de arquitetura do Google Cloud.
- Documentação da VPC.
- Documentação do balanceador de carga de rede de passagem interna.
- Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.