Visão geral do espelhamento de pacotes

beta

O espelhamento de pacotes clona o tráfego de instâncias especificadas na rede da nuvem privada virtual (VPC) e o encaminha para análise. O espelhamento de pacotes captura todo o tráfego de entrada e saída e todos os dados de pacote, como payloads e cabeçalhos. O espelhamento ocorre nas instâncias de máquina virtual (VM), não na rede. Consequentemente, o espelhamento de pacotes consome mais largura de banda nos hosts.

O espelhamento de pacotes é útil para monitorar e analisar seu status de segurança. Ele exporta todo o tráfego, não apenas o tráfego entre os períodos de amostragem. Por exemplo, é possível usar um software de segurança que analise o tráfego espelhado para detectar todas as ameaças ou anomalias. Além disso, é possível inspecionar o fluxo de tráfego completo para detectar problemas de desempenho do aplicativo. Para mais informações, consulte os exemplos de casos de uso.

Como funciona

O espelhamento de pacotes copia o tráfego de origens espelhadas e o envia para um destino de coletor. Para configurar o espelhamento de pacotes, crie uma política de espelhamento de pacotes que especifique a origem e o destino.

  • Origens espelhadas são instâncias do Compute Engine que podem ser selecionadas com a especificação de sub-redes, tags de rede ou nomes de instâncias. Se você especificar uma sub-rede, todas as instâncias existentes e futuras dessa sub-rede serão espelhadas. É possível especificar um ou mais tipos de origem. Se uma instância corresponder a ao menos uma delas, ela será espelhada.

    O espelhamento de pacotes coleta o tráfego da interface de rede de uma instância na rede a que se aplica a política de espelhamento de pacotes. Quando uma instância tiver várias interfaces de rede, as outras interfaces não serão espelhadas, a menos que outra política tenha sido configurada para fazer isso.

  • Um destino de coletor é um grupo de instâncias que está por trás de um balanceador de carga interno. As instâncias no grupo são chamadas de instâncias de coletor.

    Ao especificar o destino do coletor, você insere o nome de uma regra de encaminhamento associada ao balanceador de carga interno. Em seguida, o Google Cloud encaminha o tráfego espelhado para as instâncias do coletor. Um balanceador de carga interno para o espelhamento de pacotes é semelhante a outros balanceadores de carga internos, exceto pela necessidade de configuração da regra de encaminhamento para espelhamento de pacote. Qualquer tráfego não espelhado enviado ao balanceador de carga é descartado.

Como usar filtros

Por padrão, o espelhamento de pacotes coleta todo o tráfego de entrada e saída de instâncias espelhadas. Em vez de coletar todo o tráfego, é possível usar filtros para restringir o tráfego espelhado. Usar filtros ajuda a limitar o uso da largura de banda em instâncias espelhadas.

É possível configurar filtros para coletar tráfego com base em protocolo, intervalos de endereços IP ou ambos. É possível usar filtros para especificar apenas o tráfego espelhado a ser coletado, não o tráfego a ser excluído.

Ordem das políticas

Várias políticas de espelhamento de pacotes podem ser aplicadas a uma instância. Dependendo do filtro e da prioridade de cada política, o Google Cloud escolhe um para cada fluxo. Se você tiver políticas distintas, o Google Cloud usará a política correspondente que se adequar ao tráfego espelhado. Por exemplo, você tem uma política com o filtro 1.1.1.1/24:TCP e outra com 2.2.2.2/24:UDP. Como as políticas são distintas, não há ambiguidade sobre qual delas o Google Cloud usará.

No entanto, se você tiver políticas sobrepostas, o Google Cloud avaliará os filtros e as prioridades para escolher uma. Por exemplo, você tem duas políticas, uma com um filtro para 10.0.0.0/24:TCP e outra para 10.0.0.0/16:TCP. Essas políticas se sobrepõem porque os intervalos de CIDR se sobrepõem.

Para escolher uma, o Google Cloud compara o tamanho do intervalo de CIDR do filtro e prioriza as políticas. Se as políticas sobrepostas tiverem exatamente o mesmo filtro, o Google Cloud comparará os valores de prioridade. A lista a seguir detalha a avaliação feita pelo Google Cloud quando há sobreposição de várias políticas.

  • Se as políticas tiverem exatamente os mesmos filtros (intervalo e protocolo de CIDR), o Google Cloud usará a política com o menor valor de prioridade. Por exemplo, se você tiver várias políticas que usam o filtro padrão, ou seja, que correspondem em 0.0.0.0/0 para todos os protocolos, o Google Cloud usará a política com o menor valor de prioridade. Esse é o único caso em que o Google Cloud usará o valor de prioridade.

    Se as políticas tiverem a mesma prioridade, o Google Cloud escolherá uma usando um método não determinista. Cada vez que o tráfego correspondente for reavaliado em relação a essas políticas, o Google Cloud poderá escolher a mesma política ou uma diferente.

  • Nos casos a seguir, o Google Cloud escolhe uma política com base no filtro. Os valores de prioridade de cada política são ignorados.

    • Se as políticas tiverem intervalos de CIDR diferentes, mas sobrepostos, e exatamente os mesmos protocolos, o Google Cloud selecionará a política que usa o intervalo de endereços IP mais específico. Suponha que o destino de um pacote de TCP que sai de uma instância espelhada seja 10.240.1.4 e que haja duas políticas com os seguintes filtros: 10.240.1.0/24:ALL e 10.240.0.0/16:TCP. Como a correspondência mais específica para 10.240.1.4 é 10.240.1.0/24:ALL, o Google Cloud usará a política que tem o filtro 10.240.1.0/24:ALL.

    • As políticas não se sobrepõem quando têm exatamente o mesmo intervalo de CIDR, mas protocolos distintos. O Google Cloud usará a política que corresponder ao protocolo do tráfego espelhado. Por exemplo, você tem uma política para 10.240.1.0/24:TCP e outra para 10.240.1.0/24:UDP. Dependendo do protocolo de tráfego espelhado, o Google Cloud usa a política de TCP ou de UDP.

    • Se as políticas especificarem exatamente o mesmo intervalo de CIDR com protocolos sobrepostos, o Google Cloud escolherá uma política usando um método não determinista. Por exemplo, os filtros a seguir têm o mesmo intervalo, mas protocolos sobrepostos: 10.240.1.0/24:TCP e 10.240.1.0/24:ALL.

Quando a política selecionada não é determinista, é possível que o Google Cloud capture tráfego espelhado em vários balanceadores de carga. Para enviar tráfego espelhado de modo previsível e consistente a um único balanceador de carga, crie políticas que tenham filtros com intervalos de endereços não sobrepostos. Se os intervalos se sobrepuserem, configure protocolos de filtro exclusivos. Se as políticas tiverem filtros correspondentes ou usarem o filtro padrão, configure números de prioridade exclusivos para essas políticas.

Coleta de pacotes

Para coletar o tráfego espelhado, o espelhamento de pacotes exige que você use um balanceador de carga interno como parte do destino do coletor. Se você tiver várias instâncias de coletor por trás do balanceador de carga, o Google Cloud poderá enviar fluxos de entrada e saída para diferentes instâncias de coletor. No entanto, para que as ferramentas de segurança analisem dados e detectem padrões com eficácia, são necessários todos os pacotes de um único fluxo de comunicação (fluxos de entrada e saída).

Para coletar um fluxo em uma única instância de coletor, use um grupo de instâncias gerenciadas ou não gerenciadas que sempre tenha uma única instância de coletor.

Registros de fluxo de VPC

Se as instâncias espelhadas estiverem em uma sub-rede que também tem registros de fluxo de VPC ativados, os registros de fluxo de VPC não informarão os pacotes clonados. Os registros de fluxo de VPC registram apenas o tráfego não espelhado.

No entanto, se as instâncias do coletor estiverem em uma sub-rede com registros de fluxo de VPC ativados, os registros de fluxo de VPC capturarão o fluxo entre as instâncias espelhada e do coletor. Os registros mostram os endereços IP de origem e destino como as instâncias espelhada e do coletor. Para interromper a coleta de registros de tráfego espelhado, desative os registros de fluxo de VPC na sub-rede de instâncias do coletor.

Para ver mais informações, consulte como usar registros de fluxo de VPC.

Propriedades principais

A lista a seguir descreve restrições ou comportamentos do espelhamento de pacotes que são importantes de entender antes de usar o recurso:

  • É possível espelhar apenas o tráfego de TCP, UDP e ICMP.

  • É necessário que as origens espelhadas e o destino do coletor estejam na mesma região. Eles poderão estar em redes VPC diferentes se estiverem conectados por peering de rede VPC.

  • Não é possível espelhar e coletar tráfego na mesma interface de rede de uma instância de VM, porque isso causaria um loop de espelhamento.

  • Espelhar o tráfego consome largura de banda na instância espelhada. Por exemplo, se uma instância espelhada tiver 1 Gbps de tráfego de entrada e 1 Gbps de tráfego de saída, o tráfego total nessas instâncias será de 1 Gbps de entrada e 3 Gbps de saída (1 Gbps de tráfego de saída normal e 2 Gbps de tráfego de saída espelhado). Para limitar o tráfego coletado, use os filtros.

  • O custo do espelhamento de pacotes varia de acordo com a quantidade de tráfego de saída de uma instância espelhada para um grupo de instâncias, também considerando se o tráfego viaja entre as zonas.

  • O espelhamento de pacotes é aplicado na entrada e na saída. Se duas instâncias de VM que estão sendo espelhadas enviarem tráfego uma para a outra, o Google Cloud coletará duas versões do mesmo pacote.

  • Há um número máximo de políticas de espelhamento de pacotes que podem ser criadas para um projeto. Para mais informações, consulte as cotas por projeto na página de cotas.

  • Para cada política de espelhamento de pacotes, o número máximo de origens espelhadas que podem ser especificadas depende do tipo de origem:

    • 5 sub-redes
    • 5 tags
    • 50 instâncias
  • O número máximo de filtros de espelhamento de pacotes é 30, que é o número de intervalos de endereços IP multiplicado pelo número de protocolos. Por exemplo, é possível especificar 30 intervalos e 1 protocolo, o que daria 30 filtros. No entanto, não é possível especificar 30 intervalos e 2 protocolos, o que daria 60 filtros (mais do que o máximo).

  • Para a versão Beta, não há cobrança pelo uso do espelhamento de pacotes. As cobranças começam quando o espelhamento de pacotes estiver em Disponibilidade geral. Você receberá cobranças por cada regra de encaminhamento de espelhamento de pacotes e pela quantidade de dados processados, semelhante às regras de encaminhamento e aos balanceadores de carga atuais. Para detalhes, consulte os preços de balanceamento de carga e regras de encaminhamento.

Casos de uso

Nas seções a seguir, descrevemos cenários reais que mostram por que usar o espelhamento de pacotes.

Segurança corporativa

As equipes de engenharia de segurança e de rede precisam garantir que estão capturando todas as anomalias e ameaças que podem indicar violações de segurança e intrusões. Elas espelham todo o tráfego para que possam inspecionar fluxos suspeitos de modo abrangente. Como os ataques podem englobar vários pacotes, as equipes de segurança precisam conseguir todos os pacotes de cada fluxo.

Por exemplo, as seguintes ferramentas de segurança exigem a captura de vários pacotes:

  • As ferramentas do sistema de detecção de intrusões (IDS) exigem vários pacotes de um único fluxo para corresponder a uma assinatura para que as ferramentas possam detectar ameaças persistentes.

  • Os mecanismos de inspeção profunda de pacotes inspecionam payloads de pacotes para detectar anomalias de protocolo.

  • Análise forense de redes para conformidade com a PCI e outros casos de uso regulatório. O espelhamento de pacotes fornece uma solução para a captura de diferentes vetores de ataque, como comunicação pouco frequente e ou tentativa frustrada na comunicação.

Monitoramento do desempenho de aplicativos

Os engenheiros de rede podem usar o tráfego espelhado para solucionar problemas de desempenho relatados por equipes de aplicativos e bancos de dados. Para verificar se há problemas de rede, os engenheiros de rede conseguem visualizar o que está acontecendo na rede em vez de confiar nos registros do aplicativo.

Por exemplo, os engenheiros de rede podem usar dados do espelhamento de pacotes para concluir as tarefas a seguir:

  • Analisar protocolos e comportamentos para encontrar e corrigir problemas, como perda de pacotes ou redefinições de TCP.

  • Analisar padrões de tráfego (em tempo real) de computadores remotos, VoIP e outros aplicativos interativos. Os engenheiros de rede podem pesquisar problemas que afetam a experiência do usuário do aplicativo, como vários reenvios de pacotes ou mais reconexões do que o esperado.

Exemplos de topologias de destino do coletor

É possível usar o espelhamento de pacotes em várias configurações. Os exemplos a seguir mostram o local dos destinos de coletor e as políticas correspondentes para diferentes configurações de espelhamento de pacotes, como peering de rede VPC e VPC compartilhada.

Destino do coletor na mesma rede

O exemplo a seguir mostra uma configuração de espelhamento de pacotes em que a origem espelhada e o destino do coletor estão na mesma rede VPC.

No diagrama anterior, a política de espelhamento de pacotes está configurada para espelhar subnet-a e enviar tráfego espelhado para o balanceador de carga interno. O Google Cloud espelha o tráfego em instâncias atuais e futuras na sub-rede. Todo o tráfego de e para a Internet, hosts locais ou serviços do Google é espelhado.

Destino do coletor em uma rede em peering

É possível criar um modelo de coletor centralizado, em que instâncias em diferentes redes VPC enviam tráfego espelhado a uma rede VPC central. Dessa forma, não é necessário criar um coletor de destino em cada rede. A rede VPC central hospeda um ou mais destinos de coletor para onde todo o tráfego espelhado é enviado.

O peering de rede VPC permite estabelecer esse cenário. É necessário que todas as redes VPC que incluem origens espelhadas estejam em peering com a rede central.

As redes VPC podem estar no mesmo projeto ou em projetos diferentes. Para cada rede VPC em peering, é necessário criar uma política de espelhamento de pacotes. Nesse caso, a política está no projeto que contém a rede central. A política também pode estar em um projeto que tenha uma rede que esteja em peering com a rede central.

No diagrama anterior, o destino do coletor coleta o tráfego espelhado das sub-redes em duas redes diferentes. É necessário que todos os recursos (a origem e o destino) estejam na mesma região. A configuração em network-a é semelhante ao exemplo em que a origem espelhada e o destino do coletor estão na mesma rede VPC. policy-1 está configurado para coletar o tráfego de subnet-a e enviá-lo para collector-ilb.

policy-2 está configurado em project-a, mas especifica subnet-b como uma origem espelhada. Como network-a e network-b estão em peering, o coletor de destino pode coletar tráfego de subnet-b.

As redes estão em projetos diferentes e podem ter proprietários diferentes. Qualquer proprietário tem a possibilidade de criar a política de espelhamento de pacotes se tiver as permissões corretas:

  • Se os proprietários de project-a criarem a política de espelhamento de pacotes, é necessário que eles tenham o papel compute.packetMirroringAdmin na rede, na sub-rede ou nas instâncias a serem espelhadas em project-b.

  • Se os proprietários de project-b criarem a política de espelhamento de pacotes, é necessário que eles tenham o papel compute.packetMirroringUser em project-a.

Para mais informações sobre como ativar a conectividade particular em duas redes VPC, consulte a Visão geral do peering de rede VPC.

VPC compartilhada

Nos cenários de VPC compartilhada a seguir, as instâncias espelhadas para o destino do coletor estão todas na mesma rede VPC compartilhada. Mesmo que os recursos estejam na mesma rede, eles podem estar em projetos diferentes, como o projeto de host ou vários projetos de serviço diferentes. Os exemplos a seguir mostram onde é necessário criar políticas de espelhamento de pacote e quem pode criá-las.

Se as origens espelhadas e o destino do coletor estiverem no mesmo projeto, seja de host ou de serviço, a configuração será semelhante a ter tudo na mesma rede VPC. O proprietário do projeto pode criar todos os recursos e definir as permissões necessárias nesse projeto.

Para ver mais informações, consulte Visão geral da VPC compartilhada.

Destino do coletor no projeto de serviço

No exemplo a seguir, o destino do coletor está em um projeto de serviço que usa uma sub-rede no projeto de host. Nesse caso, a política também está no projeto de serviço. A política também pode estar no projeto de host.

No diagrama anterior, o projeto de serviço contém as instâncias do coletor que usam a sub-rede do coletor na rede VPC compartilhada. A política de espelhamento de pacotes foi criada no projeto de serviço e está configurada para espelhar instâncias com uma interface de rede subnet-mirrored.

Os usuários do projeto de host ou de serviço podem criar a política de espelhamento de pacotes. Para fazer isso, é necessário que tenham o papel compute.packetMirroringUser no projeto de serviço em que está o destino do coletor. Também é necessário que os usuários tenham o papel compute.packetMirroringAdmin nas origens espelhadas.

Destino do coletor no projeto de host

No exemplo a seguir, o destino do coletor está no projeto de host e as instâncias espelhadas estão nos projetos de serviço.

Este exemplo pode ser aplicado a cenários em que os desenvolvedores implantam aplicativos em projetos de serviço e usam a rede VPC compartilhada. Eles não precisam gerenciar a infraestrutura de rede ou o espelhamento de pacotes. Em vez disso, uma equipe centralizada de rede ou de segurança, que tem controle sobre o projeto de host e a rede VPC compartilhada, é responsável pelo provisionamento de políticas de espelhamento de pacotes.

No diagrama anterior, a política de espelhamento de pacotes é criada no projeto de host, onde está o destino do coletor. A política está configurada para espelhar instâncias na sub-rede espelhada. As instâncias de VM em projetos de serviço podem usar a sub-rede espelhada, e o tráfego delas é espelhado.

Os usuários do projeto de host ou de serviço podem criar a política de espelhamento de pacotes. Para fazer isso, é necessário que os usuários no projeto de serviço tenham o papel compute.packetMirroringUser no projeto de host. Os usuários no projeto de host precisam ter o papel compute.packetMirroringAdmin para origens espelhadas nos projetos de serviço.

Instâncias de VM de várias interfaces

É possível incluir instâncias de VM que tenham várias interfaces de rede em uma política de espelhamento de pacotes. Como uma política pode espelhar recursos de uma única rede, não é possível criar uma política para espelhar o tráfego de todas as interfaces de rede de uma instância. Se você quiser espelhar outras interfaces de rede, será necessário criar uma política para cada interface, porque cada uma delas está em uma rede diferente.

A seguir