Appliances de rede centralizados no Google Cloud

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.

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.

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:

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 TCP/UDP 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:

  • Use o balanceador de carga TCP/UDP interno 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 TCP/UDP 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 TCP/UDP 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 TCP/UDP interno como próximo salto poderá ter back-ends em qualquer interface de rede.

    O diagrama a seguir mostra a topologia do uso de um balanceador de carga TCP/UDP interno como o próximo salto.

    A topologia do uso de um balanceador de carga TCP/UDP interno 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 TCP/UDP 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.

    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.

Nas duas abordagens, em uma configuração ativa/ativa, o tráfego de retorno pode ser roteado para uma máquina virtual diferente do tráfego de saída, a menos que você use NAT de origem para todo o tráfego. O suporte à sincronização de sessão depende do suporte oferecido pelo appliance virtual.

O uso de um balanceador de carga TCP/UDP 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.

No entanto, o uso de um balanceador de carga TCP/UDP interno como próximo salto tem as seguintes desvantagens:

  • Somente o tráfego TCP e UDP pode passar por um balanceador de carga TCP/UDP interno. Outros protocolos, incluindo o Internet Control Message Protocol (ICMP), não são compatíveis.
  • O balanceador de carga TCP/UDP interno, como o próximo salto, não é compatível com tags de rede.

O uso do roteamento do Google Cloud tem as vantagens a seguir:

  • Todos os protocolos, exceto o tráfego sempre bloqueado, são compatíveis. O uso não está limitado a protocolos específicos.
  • As rotas do Google Cloud podem ser limitadas a determinadas tags de rede. Por exemplo, as instâncias de VM podem ser segmentadas por região para usar diferentes conjuntos de appliances.

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.

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.

    Topologia de várias redes VPC conectadas por meio de um appliance virtual usando várias interfaces de rede.

    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 TCP/UDP 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.

    Topologia de combinação de várias interfaces de rede com peering de rede VPC.

    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.

    Topologia da abordagem

    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.

Árvore de decisão para 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 TCP/UDP 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 usando peering de rede VPC e balanceador de carga TCP/UDP interno como próximo salto

Essa arquitetura é um caso de uso típico de ambientes empresariais, usando o balanceador de carga TCP/UDP interno para alta disponibilidade, combinado ao peering de rede VPC para anexar segmentos de rede.

O diagrama a seguir mostra a topologia dessa arquitetura,

Topologia de uso do peering de rede VPC e do balanceador de carga TCP/UDP interno como próximo salto.

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 TCP/UDP interno. Uma rota padrão estática aponta para o balanceador de carga TCP/UDP interno 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 appliances como ativos/passivos usando o failover para balanceamento de carga TCP/UDP interno. Isso ajuda a garantir que o tráfego sempre flua por meio de um único appliance virtual.

Use este exemplo de arquitetura se a comunicação entre as diferentes redes VPC for somente TCP/UDP. É escalonável até o limite de conexões de peering de rede VPC por rede VPC.

Para uma implementação de amostra dessa arquitetura com um gateway NAT como appliance virtual, consulte Como implantar appliances baseados em VM centralizados usando o balanceador de carga TCP/UDP interno 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.

Topologia de caso de uso especial com uma rede VPC compartilhada no Google Cloud.

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

Para implementar uma arquitetura que usa appliances virtuais, escolha uma opção para alta disponibilidade e combine-a com uma opção para anexar segmentos de rede.

Para as seguintes combinações de opções, há guias de implementação disponíveis:

Os tutoriais anteriores usam gateways NAT como um caso de uso para o appliance, mas é possível adaptar o gateway usando qualquer um dos outros casos de uso.

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