Visão geral do espelhamento de pacotes

O espelhamento de pacotes clona o tráfego de instâncias especificadas na rede da nuvem privada virtual (VPC) e o encaminha para exame. 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 analisa 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 ver 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 à qual se aplica a política de espelhamento de pacotes. Nos casos em que uma instância tiver várias interfaces de rede, as outras interfaces não sã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 de instâncias são chamadas de instâncias de coletor. Para o grupo de instâncias, recomendamos o uso de grupos de instâncias gerenciados por fornecerem recursos de escalonamento e recuperação automáticos.

    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 que a regra de encaminhamento seja configurada para espelhamento de pacote. Qualquer tráfego não espelhado enviado ao balanceador de carga é descartado.

Como filtrar

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 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 198.51.100.3/24:TCP e outra com 203.0.113.2/24:UDP. Como as políticas são distintas, não há ambiguidade sobre qual delas será usada pelo Google Cloud.

No entanto, no caso de políticas sobrepostas, o Google Cloud avaliará os filtros 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.

O Google Cloud escolhe uma política com base em um filtro:

  • 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.

  • Se as políticas especificarem exatamente o mesmo intervalo de CIDR com protocolos sobrepostos, o Google Cloud escolherá uma política com o protocolo mais específico. 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. Para o tráfego de TCP correspondente, o Google Cloud usa a política 10.240.1.0/24:TCP. A política 10.240.1.0/24:ALL se aplica ao tráfego correspondente a todos os outros protocolos.

  • As políticas não se sobrepõem se tiverem 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 sobrepostas tiverem exatamente o mesmo filtro, o Google Cloud escolherá uma com base em um método não determinístico. 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 em que a política selecionada não for 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.

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 com o 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 podem 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.

  • Para espelhar o tráfego transmitido entre pods no mesmo nó do Google Kubernetes Engine (GKE), ative a visibilidade intranós no cluster.

  • 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 viajando de uma instância espelhada para um grupo de instâncias e se o tráfego viaja entre as zonas.

  • O espelhamento de pacotes é aplicado nas direções de entrada e de 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 ver mais informações, consulte as cotas por projeto na página decotas.

  • 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 resultaria em 60 filtros (mais do que o máximo).

  • Você é cobrado com base na quantidade de dados processados pelo Packet Mirroring. Para mais detalhes, consulte os preços do Espelhamento de pacotes.

    Também haverá uma cobrança por todos os componentes de pré-requisito e tráfego de saída relacionados ao espelhamento de pacotes. Por exemplo, as instâncias que coletam tráfego são cobradas à taxa normal. Além disso, se o tráfego do espelhamento de pacotes circular entre as zonas, será realizada uma cobrança pelo tráfego de saída. Para detalhes de preços, consulte a página de preços.

Casos de uso

As seções a seguir descrevem 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 concluir uma inspeção abrangente de fluxos suspeitos. Como os ataques podem abranger vários pacotes, as equipes de segurança precisam conseguir todos os pacotes para 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ão (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órios exigem que a maioria dos pacotes seja examinada. O espelhamento de pacotes fornece uma solução para a captura de diferentes vetores de ataque, como comunicação ocasional 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 seguintes tarefas:

  • 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 reconexões em maior quantidade 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 do 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 mirrored-subnet e enviar tráfego espelhado para o balanceador de carga interno. O Google Cloud espelha o tráfego em instâncias existentes 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.

É possível conseguir esse cenário com o peering de rede VPC. É 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 ver mais informações sobre como ativar a conectividade privada em duas redes VPC, consulte a Visão geral do peering de rede VPC.

VPC compartilhada

Nos seguintes cenários de VPC compartilhada, as instâncias espelhadas para o destino do coletor estão todas na mesma rede VPC compartilhada. Mesmo que os recursos estejam todos na mesma rede, 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 as 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 em um projeto de host ou projeto 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 em 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 o destino do coletor está localizado. 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. Não há a necessidade de 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 o destino do coletor está localizado. 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 a função compute.packetMirroringUser no projeto de host. Os usuários no projeto de host necessitam do 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