Espelhamento de pacotes

Nesta página, você encontra uma 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 e dados de pacote, incluindo payloads e cabeçalhos. A captura pode ser configurada para o tráfego de entrada e saída, apenas o tráfego de entrada ou somente o tráfego de saída.

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 nas VMs.

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.

  • As origens espelhadas são instâncias de VM do Compute Engine que você pode selecionar especificando 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. Especifique um ou mais tipos de origem. Se uma instância corresponder a um dos tipos, ele será espelhado.

    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.

    Ao especificar o destino do coletor, você insere o nome de uma regra de encaminhamento associada ao balanceador de carga de rede de passagem interna. 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.

Filtragem

Por padrão, o Espelhamento de pacotes coleta todo o tráfego IPv4 de instâncias espelhadas. Em vez de coletar todo o tráfego IPv4, é possível usar filtros para expandir o tráfego coletado a fim de incluir todo o tráfego IPv6 ou parte dele. Também é possível usar filtros para restringir o tráfego espelhado, o que pode ajudar a limitar a largura de banda usada por instâncias espelhadas.

É possível configurar filtros para coletar tráfego com base em protocolo, intervalos CIDR (IPv4, IPv6 ou ambos), direção do tráfego (somente entrada, somente saída ou ambos) ou uma combinação.

Ordem das políticas

Várias políticas de espelhamento de pacotes podem ser aplicadas a uma instância. A prioridade de uma política de espelhamento de pacotes é sempre 1000 e não pode ser alterada. Políticas idênticas não são compatíveis. O Google Cloud pode enviar tráfego para qualquer um dos balanceadores de carga que foram configurados com políticas de espelhamento de pacotes idênticas. 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.

Dependendo do filtro de cada política, o Google Cloud escolhe uma 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 2001:db8::/64:TCP:UDP. Como as políticas são distintas, não há ambiguidade sobre qual delas será usada pelo Google Cloud.

No entanto, se você tiver políticas sobrepostas, o Google Cloud avaliará os filtros para escolher qual política usar. 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 CIDR 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 2001:db8::/64:TCP e outra para 2001:db8::/64: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, elas serão idênticas. Nesse caso, o Google Cloud pode escolher a mesma política ou uma diferente sempre que o tráfego correspondente for reavaliado em relação a essas políticas. Recomendamos evitar a criação de políticas idênticas de espelhamento de pacotes.

Registros de fluxo de VPC

Os registros de fluxo de VPC não registram pacotes espelhados. Se uma instância do coletor estiver em uma sub-rede com registros de fluxo de VPC ativados, o tráfego enviado diretamente para a instância do coletor será registrado, incluindo o tráfego de instâncias espelhadas. Ou seja, se o endereço IPv4 ou IPv6 de destino original corresponder ao endereço IPv4 ou IPv6 da instância do coletor, o fluxo será registrado.

Saiba mais em Usar os 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:

  • Cada política de espelhamento de pacotes define origens espelhadas e um destino de coletor. Você precisa aderir às seguintes regras:

    • Todas as origens espelhadas precisam estar no mesmo projeto, rede VPC e região do Google Cloud.
    • Um destino de coletor precisa estar na mesma região que as origens espelhadas. Um destino de coletor pode estar localizado na mesma rede VPC que as origens espelhadas ou uma rede VPC conectada à rede das origens espelhadas usando peering de rede VPC.
    • Cada política de espelhamento só pode referenciar um único destino de coletor. No entanto, um único destino de coletor pode ser referenciado por várias políticas de espelhamento.

  • Todos os protocolos da camada 4 são compatíveis com o Espelhamento de pacotes.

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

  • Para espelhar o tráfego IPv6, use filtros para especificar os intervalos CIDR IPv6 do tráfego IPv6 que você quer espelhar. É possível espelhar todo o tráfego IPv6 usando um filtro de intervalo CIDR de ::/0. É possível espelhar todo o tráfego IPv4 e IPv6 usando o seguinte filtro de intervalo CIDR separado por vírgulas: 0.0.0.0/0,::/0.

  • 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. É possível alterar esse comportamento especificando que apenas os pacotes de entrada ou de saída sejam espelhados.

  • 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 IPv4 e IPv6 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 espelhamento de pacotes. 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. Veja mais detalhes na página de preços.

  • O tráfego espelhado será criptografado somente se a VM criptografar esse tráfego na camada do aplicativo. Enquanto as conexões de VM para VM nas redes VPC e nas redes VPC com peering são criptografadas, a criptografia e a descriptografia ocorrem nos hipervisores. Da perspectiva da VM, esse tráfego não é criptografado.

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.

Uma política de espelhamento de pacotes com uma camada origem e um coletor de destino na mesma VPC em uma rede VPC.
Política de espelhamento de pacotes que tem todos os recursos na mesma rede VPC (clique para ampliar)

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 de rede de passagem interna. 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 um destino de coletor em uma rede VPC central. Dessa forma, é possível usar um único coletor de destino.

No exemplo a seguir, o balanceador de carga de rede de passagem interna collector-load-balancer está na região us-central1 na rede VPC network-a em project-a. Este coletor de destino pode ser usado por duas políticas de espelhamento de pacotes:

  • policy-1 coleta pacotes de origens espelhadas na região us-central1 na rede VPC network-a em project-a e os envia para o destino collector-load-balancer.

  • policy-2 coleta pacotes de origens espelhadas na região us-central1 na rede VPC network-b em project-b e os envia para o mesmo destino collector-load-balancer.

Duas políticas de espelhamento são necessárias porque as origens espelhadas existem em redes VPC diferentes.

Uma política de espelhamento de pacotes em uma rede central onde fica o destino do coletor. A rede é posta em peering com outras redes onde as origens espelhadas ficam.
Políticas de espelhamento de pacotes em uma rede central em peering com outras redes que têm origens espelhadas (clique para ampliar)

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.

A relação entre o host e o serviço projetos para Espelhamento de pacotes.
Destino do coletor no projeto de serviço (clique para ampliar)

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.

A relação entre o host e o serviço projetos para Espelhamento de pacotes.
Destino do coletor no projeto de host (clique para ampliar)

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ê precisar espelhar mais de uma interface de rede de uma instância de interface de rede múltipla, crie uma política de espelhamento de pacotes para cada interface, porque cada interface se conecta a uma rede VPC exclusiva.

A seguir